High Availability environments can provide a means of upgrading the Operations Center platforms without significant impact on the user population.
One possible approach is described here as a sample upgrade methodology:
Verify that the Primary and Backup servers are available.
Swing all DR users off the DR box.
Shut down Operations Center on the DR server.
Export the configuration from Production and import it into another configStore instance.
This should be separate from the “primary” configStore instance.
Turn off the Cluster option in the customizer.
Start Operations Center on the DR server.
Point Operations Center at the copy of the production configStore instance.
Test, test, test.
After testing is complete on the DR server, start the process of upgrading the rest of the environment; users would log in to the DR server while the Primary and Backup are being upgraded. While users are in the DR environment, most Operations Center administrators choose not to make and/or synchronize changes to the Operations Center configuration (such as Service Models, Users/Groups, and so on); however, operators are still be able to perform real-time operations, such as closing/acknowledging alarms, opening tickets, and so on.
This process, as described above, typically does not cause an outage because the Load Balancers swing users from one system to another. For instance, you might be able to instruct end users to log out and log in again without specifying the server; the Load Balancer could be reconfigured moments before hand to automatically redirect the users when they log in again.
While upgrades can require patches on the client, client upgrades are automatically downloaded when a users logs in again.