Many software upgrades must occur in a limited time frame with indeterminate downtime, where all pieces of the solution are upgraded at once. This is referred to as a synchronous upgrade. At the beginning of a synchronous upgrade, a solution is taken offline to install new versions and uninstall legacy versions which creates a lengthy series of configuration steps that are both independent and interdependent. The number of steps taken and changes made all at once can make this process difficult to document completely and even more difficult to test.
If any major issues are found after a synchronous upgrade is complete, they can significantly negatively impact users or processes. Because so many changes are made at once, troubleshooting a synchronous upgrade can be very complex.
These steps describe a high-level overview of the synchronous upgrade process:
- Test the upgrade by performing it in a test environment, and then test the resulting configuration. The test environment should match the production environment as closely as possible. During this phase, identify and document upgrade processes. Note any areas where the process could be improved, and implement the changes in the next phase.
- Perform the Synchronous Upgrade in the production environment, ideally over a weekend. Update relative paths, complete related tasks, and perform a smoke test of the whole system. This test will inform the decision to go live or to roll back.
- After the upgrade, await the outcome. Help desk staff, administrators, and IT must be ready for emergency issues not encountered during testing. Be prepared for a rapid response to issues, up to and including rollback to the previous version.
Following an upgrade, the potential for issues to negatively impact the organization is far greater than any impact associated with the original installation. While an initial software installation that is delayed or over budget is also considered a significant risk, in most situations the business can continue to operate successfully while waiting for the project to complete. A failed upgrade holds significantly more risk because the organization is now dependent on the solution.
If the solution improved efficiency, an organization may no longer have the resources required to perform some tasks without automation. If the system was installed some time ago, the organization may no longer have the processes or know-how to conduct business in the previous manner, and much of the current staff may not even know how their tasks were done previously.
Despite the fact that an enterprise software upgrade has higher risk than the original installation, most organizations provide fewer resources, processes, controls, or investment around an upgrade. OnBase typically becomes a mission-critical application after installation, and risk mitigation planning and activities should be part of the upgrade process.
Most Hyland Technical Support Representatives have assisted in situations where customers have encountered problems during a synchronous upgrade. Hyland has a Code Blue support status for escalating issues and to align all employees when a customer is materially impacted by a solution not functioning. Historically, more than half of all Code Blue situations were related to upgrades.