How To Kill Off Legacy Systems

Niel Nickolaisen is the chief information officer for Western Governors University, a nonprofit, entirely online university. He is also one of the founders of Accelinnova, a think tank focused on improving organizational and IT agility. Here, he discusses how to move a customer off of a legacy system for good.—Jennifer Bosavage, editor

I have spent the past 15 years of my career replacing legacy systems. When those systems no longer appropriately support the business, I launch projects to implement something new and better.

These are complex, challenging projects. The biggest challenge of is not managing the team, stakeholders, timelines, deliverables and costs. The biggest struggle is convincing the organization to decommission the legacy system once the new system is in production. It seems a human tendency to want to hold on to things we think we might need.

Many years ago, I managed a large ERP project for a consumer packaged-goods company. Midway through the project, the company acquired one of its competitors. The acquired company had its own systems for order management and distribution. When we tried to include them in our ERP project, the acquired management team responded that the new system could not possibly support their order-entry and shipping processes. The new system could accurately take an order, process an order, allocate inventory, ship the order, and integrate with the accounts receivable system. The new system would not work because it was not “their system.” So, in order to keep our ERP project on pace, we went ahead without them.

After the new system went into production, I left the company. Recently, I was talking with the CIO that took my place. Guess what? I learned that the company is still using both systems to process orders.

If you are like most of us, you have orphan and duplicate applications in your portfolio. Perhaps one department implemented one collaboration suite while another department implemented something different. Both departments are enamored with their separate applications and refuse to consider using one or the other. Perhaps you have not been able to pull the plug on an application you replaced. When you first put in the new application, there might have been a good reason to keep the legacy system alive. Someone needed access to historical data that you did not want to convert. Or, the accounting department wanted to do one more financial close on the old system. But, that was five years ago, and the thing is still alive and kicking. And consuming support time and dollars, adding to IT complexity, and pulling some of our best people back to continue to do work on an application that should be retired.

Next:: Three ways to kill off legacy systems

After years of being frustrated with my inability to turn off duplicate and legacy systems, I have developed three practices I use to minimize the temptation to keep them alive. These are:

• When developing the project plan for a new application, I also plan the decommissioning of the application we are replacing. For this planning, I develop a checklist that defines how, at each phase of the implementation, I will phase out the legacy application.

• I reduce costs by eliminating duplicate systems. If we are using multiple applications that perform similar or nearly similar tasks, I determine the fully burdened costs to support each system and then ask the business to select which one it wants to keep. The business then manages the transition to a single platform.

• I regularly report on what is in our application portfolio. When people see a diagram of what applications we are supporting and what tasks those applications are performing, they start to ask why we have two order management applications, why we have five reporting and analysis tools, and why we can’t just use one intranet application. Each time we add or delete an application, I update the diagram and send it out to my business customers. That one thing does wonders; especially when the CEO is on my distribution list.

The most important lesson I have learned about application consolidation is to plan for it. I budget for it. I put it on my list of opportunities. I communicate the options and benefits. Ultimately, the business decides what to consolidate. I just want to help them with that decision.