Skip to main content
This is the upgrade procedure for an existing on-premises Syteca deployment moving to a newer Application Server version. Three sequential phases: prepare, update, and post-update. Follow them in order — skipping pre-update preparation (especially Isolation Mode and database backup) leaves the deployment vulnerable if something goes wrong.
NOT AVAILABLE IN SAAS. Syteca SaaS deployments are updated by your vendor — customers don’t perform these steps. This procedure applies to on-premises deployments only.
Unsupported components. The following are no longer supported for any current Syteca version — confirm your existing infrastructure isn’t running them before upgrading:
  • Windows Server 2008
  • MS SQL 2008
  • The Firebird database
  • Old load balancers
If you’re still on any of these, contact Syteca Support before attempting an update.

​
Prerequisites for the new version

Before you can install the new Syteca, the host computers must have the right .NET version installed.

​
1. Before updating the system

​
1.1 Plan the update for a quiet time

Good practice is to update when Client-to-Application-Server load is at a minimum. Also check whether the update includes data migrations (database structure changes) — these affect performance for some time after the update and may temporarily increase storage usage.
Every data migration is listed in the Syteca Release Notes as an improvement called “[Database:] The database structure has been optimized.” Review the release notes for every version between your current and target versions to see what migrations will run.

​
1.2 Disable “Update Client automatically” (if currently enabled)

To prevent Clients from automatically updating during the immediate post-update data migration window (when the Application Server is under load) and to avoid the bandwidth spike of many Clients updating simultaneously, temporarily disable auto-update before the system update. Plan to update Clients manually afterwards via the Update Selected Clients Bulk Action on the Clients page. See Update Windows Clients manually, Update macOS Clients manually, and Update Linux Clients manually for the manual procedures.
If Update Client automatically stays enabled, those Clients will only update when the Application Server itself updates to a new version — but they’ll all do so at once.

​
1.3 Enable Isolation Mode

Isolation Mode temporarily disconnects all Clients from the Application Server, blocking them from sending monitoring data. This avoids loading the Application Server with Client requests while data migration is in progress immediately after the update.

​
1.4 Back up the database

Use your database’s native tools (or a trusted third-party backup tool) to back up the Syteca database before updating. If anything goes wrong, this backup is your recovery point.

​
1.5 Snapshot the Application Server machine(s)

Use VM snapshots or filesystem-level snapshots on each Application Server host before the update. Combined with the database backup, this gives you a complete rollback path.

​
2. Update the system

​
2.1 Download the latest version

The latest released Syteca version is always available at:
The installation package includes Release Notes documenting every change since the previous version.

​
2.2 Update the Application Server

Run Syteca_Server.exe to open the Setup wizard. When prompted, select the Update option. For full details, see Update the Application Server.

​
2.3 Update the Management Tool

Run Syteca_ManagementTool.exe to open the Setup wizard. When prompted, select the Update option. For full details, see Update the Management Tool.
All Syteca components must be at the same released version to function correctly. Don’t run a v.7.23 Application Server against a v.7.22 Management Tool, or vice versa.
High Availability and load-balanced deployments: all Application Server and Management Tool instances must be updated one by one. During each instance’s update, Clients connected to it are automatically reconnected to other instances. Before each update, check the version of the Application Server on each node in the task list on the Cluster Settings tab of the Configuration page.

​
3. After updating the system

Orange Data Migration Progress Bar shown across the top of the Management Tool indicating an in-progress post-update data migration

The Data Migration Progress Bar — orange banner at the top of every Management Tool page until migration completes after a system update.

Wait for data migration to complete before updating Clients and before disabling Isolation Mode. After the Application Server starts up, data migration begins automatically. An orange Data Migration Progress Bar displays at the top of all Management Tool pages while migration runs.
Data migration runs in the background and may take some time. Client sessions are migrated newest first, oldest last — older sessions won’t open in the Session Viewer until migration completes. Plan a quiet window where ongoing investigations aren’t blocked.

​
3.1 Update the Clients (if auto-update is disabled)

Update any Clients that don’t have Update Client automatically enabled via Update Selected Clients Bulk Action on the Clients page. Once Clients reconnect, they resume sending monitoring data — including any data they cached locally while offline during the update. No data is lost. See Update Clients for the per-OS manual update procedures.

​
3.2 Disable Isolation Mode (if enabled in Phase 1)

Once data migration is complete and Clients are updated, disable Isolation Mode. All Clients resume sending monitoring data, including any locally-cached data from the isolation window.

Release notes

Every version’s changes — review releases between your current and target versions before updating.

Update Clients

Per-OS manual update procedures for Windows, macOS, and Linux Clients.

Getting started checklist

The full task list for a fresh deployment — useful as a sanity check post-update.

System health

Real-time platform health monitoring to confirm everything is operating normally after the update.