Clients often come to us to assist with their system upgrades. One of the key areas of discussion is around what version should they upgrade to and when should the upgrade occur?
There are several reasons why you may need to upgrade or apply a system patch/point release: take advantage of newer features; keep aligned to vendor supported version; to address a bug/issue with your current installed version;… Whatever the reason is it is important that you have a upgrade strategy. An upgrade strategy should address the software version that you are planning to upgrade to (eg, N or N-1); the frequency of major releases from the vendor; the available window to perform the upgrade in; the anticipated budget of performing the upgrade; the recovery/roll-back strategy in case the upgrade needs to be aborted; what system and user testing is required after the upgrade; communications to the end users of the system upgrade and any actions required by them;…
First, the frequency question. Some may say this is an easy problem to solve but what if the vendor only releases one major release a year. Then if you adopt an N-1 policy for updates then your system could be potentially two years old for your users! Conversely if releases are five times a year and you want to adopt an N-1 strategy then you are potentially looking at five upgrades in a year. This may become cost prohibitive for the benefit that you gain. Balance is the key here. As a rule of thumb, you should perform at least two upgrades per year approximately 6 months apart and away from any blackout window or other critical processing periods.
The next question is whether you should adopt an N or N-1 upgrade strategy. This becomes more of a question around your confidence in the vendor to provide a quality release with minimal bugs. We normally advise that you follow an N-1 approach assuming the software vendor does several major releases a year as a starting point. If releases are more frequent and the core of the software is stable and isn’t changing, then you may consider following an N approach. Perhaps when there are significant changes to the core of the software fall back to an N-1 release for several upgrades and then go back to an N approach. Some clients may decide to temporarily change from N-1 to N to take advantage of a new critical feature that is in demand by the business.
Finally, should you upgrade for minor/dot releases? The simple answer is no unless it fixes a bug that your business is experiencing, provides additional security or provides a feature that you need for your business.
You must not forget to perform upgrades as you introduce risk to the business by not regularly upgrading. Data and system security are often cited as a concern by not upgrading but another risk is that you may be unintentionally holding the business back by not taking advantage of new software features. System stability is often stated as another reason not to upgrade which I feel is a short-sighted view. When you do eventually upgrade you are placing a significantly increased risk on the business post upgrade. The reason is that the upgrade is no longer a routine business task, and this leads to the upgrade potentially becoming a major project which will attract other risks and costs.
Not sure how to plan an upgrade strategy, email AtoBI at firstname.lastname@example.org and let us help.