Software Upgrade Process

Today I’m going to try list the common patterns of upgrading DBMSs, OSs, and ERPs from my experiences during our whole 8-year project duration. Upgrade is a major task of system administrators or system support stuff. During our project life-cycle, our project team continuously contributed system management of many systems. Upgrade is an installation process to make working system better. Yes, it gets better but you have to pay its cost by sacrificing your team weekends and after-hours.

Upgrade process is an element of SCM (Software Configuration Management) and System Management. There are 2 kinds of upgrade;

Version Upgrade: You just install a newer version of an application. Software is a living being and if it didn’t end its lifecycle, it will be developed and fixed periodically.

Migration: You replace an application with a similar product from another vendor. This is a harder upgrade compared with version upgrade.


Upgrade Process Steps

1- Planning: We make requirement analysis in this phase. We answer which versions are needed, version prerequisites and dependency analysis. We should also plan upgrade execution like system down-time period and user’s appropriate times.

2- Preparation: We prepare test environment. We obtain required upgrade packages and its dependencies. We check again hardware and software prerequisites to make sure everything is alright. We should also prepare recovery plan for upgrade failures.

3- Test: We install upgrade version to the copy of production system. We note installation steps, problems and their fixes. We prepare an “Installation Notes” document in addition to vendors’ release notes.

4- Upgrade: This is the execution phase. If upgrade is offline, we close user connections and start upgrade. Before upgrade, we should backup required components for recovery. If everything goes smoothly, upgrade is tested for confirmation. If upgrade fails, then it may be re-attempted or may be rolled back. When rolling back upgrade, our recovery plan is executed.

5- After-Upgrade: We open the system and users begin to use. We should accompany users during their first usages. It is probable that some problems would arise. After we are sure that system is stable and operates correctly, that means upgrade is finished.


Upgrade Best Practices

Upgrade is painful: I placed this on top of the list. The folks who upgrade the systems know this very well. Touching a running mission-critical system is just like working in a power station.

Upgrade should be tested: If you don’t test upgrade, this is identical with Russian roulette. Everything may be bogged down after upgrade. If system availability is very important, that interruption costs a lot.

Upgrade should be phased: If upgrade will be applied to many systems, than a phased approach is very paying. You can begin with a pilot system and then continue with the rest by gaining installation knowledge. That makes upgrade process smoother.

Recovery Plan should be tested: If upgrade fails, you face with your recovery plan. Whether it is an OS backup, a DB backup or a folder backup, or an application backup, restoring existing backup is critical. Recovery process should be as simple as possible.

Upgrade should be managed: Some upgrades may require managerial decisions like to continue or not when a problem is met.

Upgraded software requires more hardware resources: This is true in most of the situations. Even if it is said that software works better in new version, it always would require more hardware to reach that goal.

Upgrade infrequently: Upgrade process requires a very valuable time even though it seems a little installation. If there is no mandatory requirement, upgrade should be given a mid-level priority.

Upgrade to one version below highest version: Safest version is always one version level below the highest version of that application. Although software vendor make many tests to make the release robust, it is generally in beta stages before fix-packs. Fix-packs require time (installations and usage) to emerge. If you don’t like extreme sports, you should not be on the edge.


Some Upgrade Memories

During our ERP project, I’ve got two unforgettable upgrade memories. One was the upgrade of DB2 installed on AIX server. It was a very critical requirement for the project to apply some fix-packs. After working for hours on Saturday, time was running out. At Saturday night, it was 2:30 AM that I succeeded to execute DB2 instance. That was a perfect moment I can’t describe it. If we can’t succeed then system admin was expected to restore OS from backup in Sunday morning.

My other amazing upgrade memory is an ERP upgrade work. We had finished branch systems’ upgrade during last month and our system support team who made all upgrades were very tired (worked for many weekends). Last upgrade was the central system upgrade. For that upgrade, we worked during weekend and it couldn’t complete it. We then convinced users to continue on Monday. However, we couldn’t finish it during the daytime. After talking with upgrade team, I supposed they will finish it before the night. But it was a wrong assumption; they called me at night for resolutions of some problems. I hurriedly went to company and support them to eliminate the problems. By means of unbelievable devotion and tenacity of that team, we had completed upgrade before Tuesday morning. It was a great moment when system was up in the morning.