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.
- Protecting The Business From Cloud Application Security Risks
- The Massive SaaS Opportunities For VARs
- A Reseller's Guide: Recipe For Channel Partnership Success
- Cloud Connection: Seven Steps To Effective Public Cloud Services
- From CapEx To OpEx: Channel Strategy In The Federal Push To The Cloud
- A Reseller's Guide: Coming Out On Top In The Face Of Channel Conflict
- How To Create A Case For Disaster Recovery Plan
- How To Offset Your Customers' BYOD Risks
- How To Ease Client Anxiety About Private Cloud Deployments
- How An SMB Cloud Provider Can Create 'Swagger' In A Competitive Market
- A Reseller's Guide: Creating A Successful Solution Provider Event
- How to Prepare for the Future of the IT Solutions Industry
- How to Consolidate Data Protection Services for Greater Customer Value
- 10 Attributes to Support Revenue Marketing and Sales Success.
- How To Improve Efficiency: Upgrade Mountain Lion and iOS6
- How To Cash In On the Cloud Through Collaboration
- How To Sell Cloud Storage In Five Steps
- How To Protect High-Value Data Assets
- Moving Data to the Cloud: Options for SMBs and Small Enterprises
- How To Apply Big Data Security Analytics to Detect Advanced Threats and Breaches