Server Upgrade Process

About This Document

This document should be referenced and used for performing product updates. This document covers key steps to be understood and prepared based on our internal technical procedure. It also contains information about roll-back procedures.

Concurrent "Non-Stop" Upgrade with Backwards Compliant Schema Changes

This type of change can be made to the server and both the existing and the new version of workstation should function normally. It may break some non-critical parts of the existing workstation.

 Phase TimingDowntime Work Description
 Prep1 ore more days priorless than a minuteUpload the product installation material to the servers and prepare workstation installer download area (Imorgon).

Designate a test workstation, and ready it to install new version (Customer and Imorgon).

Fail-over the server and make sure all the workstations can access the server without a problem. If there is a problem correct the workstation configuration.

Fail-back to normal production.

DB Update1 day prior to product updateless than a minuteStop all services. Note the exact date and time for roll back purposes.
Backup Database, Apply Schema Changes, Test Existing Workstation Functionality.
Update SecondaryDay of updateless than a minuteBackup current installation, install new version on the Mirror, manually start services from the new version then start them as services.

Fail-over the server to the Secondary server.

Upgrade the test workstation, point it to the secondary server. Check with the customer for functionality.
Go/NoGo  === GO/NO-GO DECISION ===
If everything is fine then we can move on to next step, otherwise rollback.
Update Primary less than a minuteUpdate the software version of the primary
Fail-Back the Principal to the Primary

Rollback Process

This process may incur up to 30 minutes to an hour of downtime while we back-out the schema changes.
  • If the database schema is acceptable but the server software is causing the issue, we can also do software-only rollback by skipping the DB rollback step.
    • Back out all of the fields added in the schema change
  • Fail back the services to the Primary Server
  • Perform Software Rollback on the Seondary