Legacy Systems Will Have to Be Replaced — What Are You Waiting For?

In my last post, “The Cost of Doing Nothing May Exceed the Cost of Changing”, I began to examine the topic of replacing outdated, legacy systems in enterprise environments. I’m not referring to upgrades or enhancements. This is about complete replacement. It’s a daunting prospect.

I laid out two basic approaches: 1) Build a parallel system and cut over to it when ready or; 2) Replace the target system one major component at a time. Which approach to use depends upon the particulars of the situation. It’s not a simple decision.

Which ever approach you use, it’s imperative to apply agile development techniques to mitigate risks and control costs. Starting down a replacement path, getting everyone excited about the prospects, then not delivering the solution for many months (or even years) guarantees disappointment at best and failure at worst.

Some things to think about…

• Engage the stakeholders and end users early in the process and keep them engaged throughout.
• Actively seek feedback throughout the development effort and take immediate action on it. Don’t simply add suggestions to the product backlog and forget about them.
• Recognize that implementing an entirely new system will cause some disruption to daily business activities. Allocate time and effort toward minimizing it.
• Communicate and keep communicating. Keep everyone informed of what has been done, what is being done, and what’s next.
• If an unforeseen problem occurs (and it will), be responsive. Drop everything and fix it.

In the Parallel System Approach…

• Seek out ways to operate the legacy system and its replacement in parallel as early as possible. Don’t wait until the replacement is fully built out.
• Identify new capabilities and workflow improvements at the outset. Build them into the new system early to get the users interested in using the new system. Areas to explore include simplified data entry, improved workflow, and better reporting.
• Don’t expect users to repeat their entire workflows on the new system. Target specific areas for review and comment. Keep it simple.

In the Component Replacement Approach…

• Find opportunities to add value. Many of the backend changes will be transparent to the users making it difficult to engage them. Find areas where new capabilities can be introduced even if it means running a separate UI or batch process.
• Identify pain points in the legacy system and alleviate them at the earliest opportunity. This will build goodwill with the stakeholders and end users making the inevitable disruptions more tolerable.
• Breaking down the old system into many components will make it easier to build replacements but may also complicate the process of integrating the old and the new. Always evaluate risk, cost and time. Minimize two of them and let the third float.

Lastly, don’t wait for that legacy system to die or become too painful to use and maintain. What are you waiting for?