I have spent the past 15 years of my career doing application consolidation -- namely, replacing legacy systems. Someone would decide that a legacy application no longer supported the business, and so we would launch a project to implement something new and better. Application consolidation projects are complex and challenging, but the biggest challenge has not been to manage the team, the stakeholders, timelines, deliverables and costs.
That's right; I have struggled most with convincing the organization to actually decommission legacy applications once a new system is in production. It seems a human tendency to want to hold on to things that we think we might need.
Many years ago, I managed a large ERP project for a consumer packaged goods company. About midway through the project, the company acquired one of its competitors. As you might expect, the acquired company had its own applications for order management and distribution. When we tried to include the company in our ERP project, the acquired management team had a fit.
The new system could not possibly support the company's order-entry and shipping processes. Somehow, it was not enough that 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
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 of their separate legacy applications and refuse to consider application consolidation to narrow it down to one or the other.
Perhaps you have not been able to pull the plug on a legacy application you replaced. When you first put in the new application, there might have been a good reason to keep the legacy application 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 not only alive and kicking, but 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.
Shuting off legacy systems
After years of being frustrated with my inability to turn off duplicate and legacy systems, I have developed a few 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
legacy 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.
- Recently, most of us have been asked to reduce IT costs. One way I can reduce costs is 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
- 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. This 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 with that decision.
Niel Nickolaisen is CIO at Western Governors University in Salt Lake City. He is a frequent speaker, presenter and writer on IT's dual role enabling strategy and delivering operational excellence. Write to him at email@example.com.
This was first published in October 2009