Knowledge Base

Legacy Server Upgrades:
Staging Server Strategy

Very old RightFax versions often cannot upgrade directly to modern releases. How to use intermediate staging servers to step through schema migrations safely.

← Back to Knowledge Base
Upgrades KB-003

Legacy Server Upgrades: Staging Server Strategy

Organizations running very old RightFax versions often cannot upgrade directly to modern releases. RightFax's database schema has evolved significantly across major versions, and the installer's upgrade path validation enforces supported source versions. Attempting a direct jump beyond the supported range will fail or produce a broken installation. The staging server strategy solves this through sequential schema migrations on isolated infrastructure before touching production.

When This Applies
  • Running a RightFax version from the Captaris era or early OpenText releases (v9.x and earlier)
  • Installer reports the source version is not a supported upgrade path for the target release
  • Database schema validation fails during upgrade pre-checks
  • Migrating to a modern version (v20, v22, or later) from a server that has not been upgraded in many years
Approach
01
Determine the Required Upgrade Path
Consult the OpenText RightFax release notes and upgrade documentation for your target version. Each release specifies which source versions are supported for direct in-place upgrade. If your current version is not on the supported list, identify the nearest intermediate version that is. This becomes your first staging step. The upgrade matrix may require more than one intermediate hop depending on how old the source environment is.
02
Build a Staging Server Matching the Intermediate Version
Stand up a separate staging server. This should not be production. Install the intermediate RightFax version on this server. The staging server does not need to be fully production-configured; its purpose is to perform the database schema migration. Ensure the SQL Server version on the staging host is compatible with both the intermediate and subsequent RightFax versions you will step through.
03
Restore a Backup of the Production Database to Staging
Take a full backup of the production RightFax SQL database. Restore this backup to the staging server's SQL instance. This is your test data set. Do not perform schema migrations against the production database until all staging steps have been validated. Verify the restore is clean and that the intermediate RightFax installation can connect to the restored database before proceeding.
04
Run the Schema Migration and Validate
Allow the intermediate version installer or upgrade process to migrate the database schema. After migration completes, validate that the staging RightFax instance starts correctly, that fax data and configuration are intact, and that no SQL errors appear in the RightFax logs. This validation step is critical. Schema migration failures in staging inform what remediation is needed before the process is repeated in production.
05
Repeat for Each Remaining Upgrade Step
If the path requires additional intermediate versions before reaching your target release, repeat the process: upgrade the staging server to the next version, validate, then continue. Each step produces a validated schema state. Once staging has reached the target version and been fully validated, the same sequential process is executed in production during the planned maintenance window.
06
Maintain Production Backups at Each Stage
When executing in production, take a full database backup before each upgrade step. This provides a rollback point at every schema version. In the event of a failure mid-path, restoration to the last known good schema state is possible without losing all migration progress.
Field Note
The staging server is not optional overhead. It is the risk control. Schema migration failures are difficult to recover from in place, and the time required to rebuild a RightFax environment from scratch far exceeds the time invested in proper staging. Budget for at least one complete staging run before scheduling the production window, and treat any staging anomaly as a blocker until it is fully understood.
Upgrade Legacy Migration Database Schema SQL Server Staging Change Management
Dealing with a live issue?
We support RightFax incident triage and resolution for enterprise and regulated environments. Engagements scoped based on severity and operational impact.
Start Engagement → View Case Studies