Page 1 of 2
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.
