When an upgrade really means a re-implementation
Upgrades are inevitable in the on-premise world. They are like an intrusive physical you must take every 5 to 7 years. They are costly, disruptive, and not pleasant. You cannot avoid them since you need to keep up with your application. On the other hand, they are also reflection points - an opportunity to step back and assess your status. In such moments, you will ponder on whether you should upgrade what you already have or re-implement the whole thing with a fresh look. Let's try to answer that question.
You need first look at the technology side of the upgrade. 5 to 7 years is a long time in today's business applications world. This is especially true if you are moving from an on-premise to a cloud environment. You may find that your customization, integration, and migration frameworks have changed significantly. The bigger the technology uplift, the more rework you need to take on. Most software vendors provide tools for upgrades, yet you shouldn’t underestimate the work on hand. When that technology gap is bigger, the costs are higher which then triggers the next set of questions. Should you really upgrade what you have or enhance it to the next level?
This brings up the functional side of the upgrade. The new version of the software is likely to have several additional features. Some may eliminate your existing customizations. It will be good to assess them at this point. You have three options: 1) replace them with standard functionality, 2) drop them since they are no longer relevant; or 3) upgrade them. Next, you need to look at the new features that may be applicable to your business. Is there enough business value to expand your functional scope to introduce them during the upgrade?
Once the technology and functional sides are considered, the people side of the upgrade comes into play. You should not underestimate the business involvement to validate the upgrade - especially if you are expanding the functional scope. The upgrade project team may look like a regular implementation team. The members need to be chosen carefully (please see this blog). The initiative needs executive support (please see this blog).
It is common to see an upgrade start with a technology uplift discussion and quickly morph into a functional scope decision. I think when the technology change is big (which then drives up the upgrade cost), the companies increase their functional scope in order to justify the whole initiative. No wonder why most upgrades cost as much as new implementations. The long-term solution is to endorse a cloud-based application that enables continuous minor updates rather than major disruptive upgrades (please see this blog).
If you are interested to learn more, please connect with me on LinkedIn, follow me on Twitter, or watch me on YouTube.
My name is Cem and this has been another gem.
