7 Good Project Management Practices for Replacing a Legacy System

There were compelling reasons to replace the legacy system: It was fragile, arcane, and difficult to support; evolving regulations required frequent changes; design debt makes changes expensive and error-prone; the hardware platform was expensive and beyond end of life; and the few people who could support it were aging and eligible for retirement.

Because the system was mission-critical, the project to replace it was perceived late the day it began. A cursory review of requirements was performed and a replacement product quickly procured. A slideshow for executives explained the benefits of a modern system in terms of increased functionality and flexibility as well as decreased cost and risk. A budget guess and crude schedule were thrown together and approved, and the project began.

These paragraphs could be in the summary of several legacy replacement project autopsy reports I’ve written over the last ten years.

There are several classic challenges with legacy systems:

• Dirty data
• Design debt
• Poor documentation
• Absence of source code
• Obscure interface logic
• Underestimating the scope of organizational change

The risks associated with these challenges require careful consideration and planning, but when an organization realizes a mission-critical platform is “burning,” it’s tempting to set aside good project management practices and push forward recklessly. I’ve seen this result in huge schedule delays, significant cost overruns, data problems, organizational chaos, and many unhappy faces in the executive suite.

Teams that performed well did several things that made a difference:

1. Take time to understand and document the existing system, its files, and interfaces. Work with people who understand the system to document what you can, as soon as you can—some of those folks may leave before your project is finished.
2. Don’t choose the replacement system until you understand what you are replacing. “Best of breed” sounds great, but know whether there is existing functionality that will be lost or will require customizing the new system.
3. Start data conversion and cleanup as soon as you can. Assume data conversion will be messy and take longer than anyone thinks.
4. Don’t underestimate interface complexity. Interfaces can be difficult, and your interface partners may not share your urgency.
5. Invest in effective organizational change. The organization may have extensive business processes built around the legacy system, which means retooling and retraining that take time and resources.
6. Don’t accept an arbitrary target date. Management can tell you when they want the project completed, and they may have good reasons, but you shouldn’t commit to the target if you can’t develop a credible plan that says it is attainable.
7. Ask for needed resources. Don’t lowball estimates to avoid upsetting executives.

When systems must be replaced quickly, it can encourage sloppy and counterproductive practices. Take the time to understand the problem, plan and estimate the solution, and organize your project for success. The executive suite may not like how much the project will cost, but they usually prefer a painful truth to a rushed fiction.