Help, I Can't Upgrade!

Although I am a big fan of customization, it can become a roadblock to upgrading your system. When this happens, it can cause major headaches and even jeopardize business operations. Eventually a system can fall so behind on upgrades that it becomes a cybersecurity risk because it requires obsolete infrastructure versions and old browsers to operate. At this point it can become a crisis and demand drastic action.

What are the controlling factors

There are several factors that can cause a roadblock to your upgrade. Many are under your control, and some are beyond your control. Unfortunately, when you get the message that you are not upgradable, you are past the point of best practices and easy fixes and must look at what you can do with what you have.

What does it really mean

So, what does the message “You are unable to upgrade” really mean. Well, it does not mean you cannot upgrade. You can always load the new version of the base upgraded system. This is what the vendor sends you “Out of the Box”. ?You may need to do some infrastructure upgrades as well to meet minimum requirements, but this is all very achievable.

A better translation

The actual translation is probably closer to “we cannot get you back to your current level of functionality on the upgraded system without a huge amount of rework of the customizations we have developed.” Now we have the real message - it is a huge effort, not that it is impossible.

What went wrong

What are some of the reasons we need a huge effort? In my experience it comes down to a few key areas. We have poor configuration management and have lost the source code for the customizations, we have lost the level of expertise required to remediate and install the customizations, or the vendor has significantly changed the architecture of the system (data or interface) so our customizations are fundamentally misaligned.

We control much of this

The first two reasons are within our control and shame on us if we let them get away from us. The last one is not under our control directly, but we could have followed robust customization practices that minimize the risk.

Issue: Loss of source code

If we look at loss of source code, we are back to zero from a coding standpoint, but do have the requirements somewhat defined in the working system. We need to recreate our old functionality to the extent that it makes sense. We start with the new upgraded base system. We will then evaluate some sort of triage of what additional customizations we will need to operate effectively going forward.

Triage

In some cases, the new base system will now do the things that required customization in the past. We can develop new training and adopt the new methods. In some cases, the customizations are absolutely required to operate, and we will need to recreate them from scratch using the old customizations as a definition. In some cases, the new functionality is close to what we need and will only require minor tweaks in the business process or customizations to become useful.

The plan

This then becomes our upgrade plan, and we just need to find the funding for the additional work. The loss of source code is no longer a roadblock, now it is just money and resources. This is something we can deal with. The justification process will also help us refine our triage as we do a cost/benefit analysis of each customization.

Issue: Loss of Expertise

Next, we can look at loss of expertise. I have seen many times where a strong team is created to implement a new system. They have the expertise to develop and maintain the customizations required to run the business. Once the system is in steady-state operation and working well, the expense of the team is considered excessive, and some team members are let go to free funding for other priorities.

Attrition too

There is probably also a lack of succession planning, and the team loses additional expertise through attrition until it can just barely keep the system running. When an upgrade comes along, they just don’t have what it takes to execute it.

Bigger learning curve

This one is difficult to recover from because anyone new to the system will need time and effort to figure out the architecture of the customizations, the configuration management system, and the build process. Depending on the level of formality of the original team, this could be a huge exercise.

Probably more challenging

The solution, in this case, is like the first scenario, but the customizations will not need to be recreated from scratch. The new factor is acquisition of new resources and developing expertise. This can, in some ways, be an even more challenging activity than the first one.

Do it or buy it?

You will have to start with a make/buy decision to see if you should build a new team internally or if you should outsource the effort to an external team. Internal teams are usually cheaper and more focused, but harder to maintain over time. External teams are more expensive and focused on their own revenue generation, but you do not have to worry as much about succession planning and rewards. (If you do not maintain a relationship with the external company, you could find yourself right back in the same spot when the next upgrade rolls around.)

Triage again

Once you have a team, you should evaluate a triage of what is needed and not needed and develop a plan. Like the first plan, the justification process will drive additional triage and refinements.

Issue: Architecture changes

The last issue is vendor architecture changes. These often show up as Data Model changes or Application Programming Interface (API) changes. If you have all your source code and a strong team, these can be annoying but are usually manageable.

Data model changes

A Data Model change could clobber data elements that you have created or enhanced. In this case, you will need to change your data model to be compatible with the upgraded Data Model. In most cases, this is easy. The harder part is changing all the interactions between the customizations and the Data Model. This can be extensive. You will probably also have to do a limited data migration to transform or populate the new data elements.

API changes

API changes are always challenging. The worst case is when they represent totally new ways of doing things in the system driven by new behaviors in the base system. You must identify all the places in the code that use the API and then translate them into the new API or the new paradigm using the new API. New paradigms are challenging because in many cases it is not one call to one call. You either make multiple calls to do what one call did in the past, or one call to do what multiple calls did in the past. There may be additional parameters required that were not comprehended by the old paradigm. It is rarely a simple global replacement.

Bonus Issue: End of life

These are the three main areas where a seemingly overwhelming roadblock can stymie efforts to upgrade. There is one more consideration that can complicate the upgrade decision process and that is when the old system is near the end-of-life or is out of support. In this case, an additional decision is if you are already doing a huge amount of work to complete the upgrade of the old system, would it be better to just jump to a new base system while you are at it.

Changing may be more affordable in the long run

Pricing for purchasing a new system when it is replacing a competitor’s system is usually very attractive. Do you really want to pour more money into an aging system when it would probably not cost that much more to just move on to the new system now. This is especially true in scenario two where you are trying to develop expertise in an old obsolete system that is losing ground, and the pool of expertise is shrinking as people abandon it.

Conclusion

Getting caught in an impossible upgrade situation is never fun and can be very stressful. We have discussed several ways you can get caught and some ideas of how to respond. Do you have a horror story to tell? How did you escape the impossible upgrade trap? We would love to hear your tale in the comments.

?

Digital Guideposts is written by Mark Pendergast – retired Data Junkie, Deep Thinker and Innovator. He worked with product data for over 30 years of his 41-year career in Automotive Components Manufacturing. His background includes work in Engineering, Operations and Information Technology. He is also an Electrical and Computer Engineer (BS-ECE) and a Certified Project Management Professional (PMP). In his spare time, he mentors a High School FIRST Robotics Team, reads and plays on his computer.

?

?

?