A Few Thoughts on Upgrades

It is a reality of enterprise software that eventually you have to upgrade the stack. I know that the cloud lobby say they solved that problem but I will not take on that conversation in this post. As with  everything in technology reality is very different from the marketing. This is one of the biggest topics here at DevCon and I had a few thoughts to share on the subject.

Everyone that has deployed an ECM system has to decide when not if they will upgrade the system and migrate their data. The first step in the process is to determine your upgrade objectives. I tend to classify these objectives into three categories.

• Feature driven – there is something that the old version did not do that the new version can that users need. I stress the user’s need because a new capability or characteristic of a platform that has no intrinsic business value is NOT a valid upgrade driver no matter how cool it is.
• Cost driven – The cost of maintaining an aging stack is not always easy to quantify. There are some systems that were developed and deployed prior to the advent of production virtualized environments and significant savings come from shrinking the physical footprint. Others are well contained, do the job and cheaply sit in a corner.  Nevertheless, cost of maintaining a stack will follow a curve that starts high early, drops for the manageable life of the system but rises over time, at times with the proverbial hockey stick when something in the environment (db, o/s,hardward) reaches its practical end of life.
• Date driven – This is sadly the most common trigger to an upgrade cycle.  All software companies have limits on how long a given version will be supported. Time marches on and so do underlying operating systems, databases and design patterns. At some point vendors must move on and drop support for older versions. The challenge here is the definition of support.

Your motivation for upgrade is a mixture of these categories.

A end of support date is often the trigger objective for an effort but if you do not evaluate the other dimensions you will fall short of the business needs. It is extremely rare that business requirements remain static over the lifespan of a given application. There will be features and efficiencies that can benefit your business but they must be sufficient to justify the cost of doing the effort required to meet the strategy you adopt.

In many cases what you end up doing is not an upgrade at all. It is a new system that you are populating with legacy data. this creates both budget and political challenges because often “new” is harder to fund, comes with more risk and might take longer than expected.

The longer you wait, the more likely this will be the outcome. Upgrade rarely gets cheaper over time. From a pure logistics and budgeting perspective, the more content you have, the more the business rules evolve, the more users you have the more expensive the effort will become.

The need to upgrade a system based on date alone should never be a surprise. End of service dates are known the day you install the software but to be honest no company is thinking about that when they deploy a new system. One of the most frustrating behaviors I see in the field though is customers going through the challenge of an upgrade but installing something that is not the latest release artificially shortening the lifespan of the installation. This was a habit the community adopted when service packs were less stable but it is no longer a recommended practice.

The upgrade objectives you have drive your migration objectives. Chris Dyde in the keynote this morning did a great job discussing this in the context of several  customer cases . In this he mentioned the migration assessment offering from professional services. This is an engagement to walk you through evaluating your objectives and develop a strategy that makes the most sense for your systems. IF you need guidance developing this strategy that is an option you should definitely consider.