IT Systems Upgrades: How to Avoid the Pain


Over the course of 10 years in Information Technology, I have found that the process of upgrading or migrating to new systems is almost always painful for most of the people involved. In particularly challenging cases, that pain extends also to customers. The way to mitigate or avoid some of this pain is to ensure that an organization makes a solid case for what they gain and lose from the upgrade/migration and that they set realistic expectations for how their internal processes will need to change to integrate the new system.

Why is upgrading usually painful? In my experience, the pain is usually felt due to two sets of circumstances. The first is that newer versions of a product usually implement the same functionality differently. Often this is because a newer version attempts to solve additional problems or it uses a different or newer technology. The result is that any processes that a business has developed using the old system, such as reporting or workflow, will be disrupted. A similar issue often occurs when the replacement system comes from a different vendor.

The second set of circumstances relates to the business processes that evolve around a system. Often, the new system will offer a different set of interfaces or produces output differently. Because of this, an organization’s internal processes will not interface seamlessly with the replacement system.

When should organizations upgrade or migrate to new IT systems? Often decisions to upgrade will be made based on a somewhat superficial evaluation. For example, one company I worked for decided to upgrade one of it’s systems almost immediately following the vendor’s announcement that they would be producing a new version based on the newer platform. Management made the assumption that the older platform would be phased out quickly. There may also have been a little machismo in the decision (e.g., “We’re always first, always pushing the envelope…”) In fact, the vendor did not end up phasing out the older product quickly and early releases of the new product lagged behind in terms of stability and functionality in some areas.

An organization should conduct a reasonably thorough systems analysis that assesses the benefits and costs of moving to the new system. This analysis should include information related to how existing internal business processes and systems will have to change. Where possible, the organization should quantify or at least clarify the expected revenue generating or cost saving benefits that result from the new system. I do not suggest that such assessments are ever particularly objective, but clarity is a good first step and can help identify potential pitfalls. If, for example, the analysis cannot point to any compelling reasons to move to a new platform (e.g., an existing platform provided by a vendor has a very specific sunset date, the new system provides opportunities to dramatically increase revenue or decrease costs) perhaps a move is not in the best interest of the organization.

I have also seen some circumstances where organizations have had to come to grips with their expectations for a system’s useful lifetime. At my current company, we have a customer that is using our last generation product at volumes well beyond what it was designed to handle. Because their business is growing rapidly and they rely on our system to generate revenue, they must upgrade to our latest generation system. While rapid growth is not always predictable, in their case we could have planned a little more carefully so that the upgrade would taken on such an acute flavor.

What can organizations do to avoid some of the pain associated with an upgrade? I have found that the ideal situation is for a systems analyst to outline the benefits and costs of the new system in terms of revenue and capital/operation costs. If you can articulate the top and bottom line impacts of a new system and the net result is positive, your basis for migrating or upgrading is simplified. You can convey this vision to your organization and it can help to smooth out the bumps that you will surely encounter. It is not a panacea–change is still difficult for most people. But you will not likely have to fight the subversive challenges that come along when people realized 70% of the way through a migration that the new system costs more and does little to increase revenues.

In some cases you cannot tie clear lines between the system upgrade, changes in revenue generation and operating expenditures. In these cases, you best bet may be to clearly articulate the cost savings over and above the current system.

In less glamorous cases, you are essentially forced to upgrade just to keep pace. In these cases, you will probably want to investigate changing to systems that will simultaneously reduce operating costs. If there don’t seem to be a lot of options out there to gain at least minor cost reductions, it may be time to revisit the organizations business model. I realize that’s easy to say but hard to do. However, these cases usually work out best when you work with executives to develop a solution rather than just ask for more capital or bigger operating budgets.