The Hidden Costs of Replacing Software

Over the years I have been involved with a number of projects trying to replace/rewrite existing software systems. And every one went over schedule and budget. That may be a small sample size, but I saw a few patterns when it came to estimating the total time needed. Some or all of the following cost factors were not considered when laying out the roadmap:

1. You do not know what you are replacing
2. You will continue to pay for the old one until the new is ready
3. Someone has to maintain the old system (and it is not glamorous)
4. You are not replacing version 1.0 with 2.0
5. There will be feature creep

With all of that said, replacing or rewriting software is not always the wrong choice. Sometimes it may be the only feasible one.

However, it is my firm belief that many replacement projects should not be done at all. Costs between improving existing solutions and replacing them with new systems are often not properly compared. And I want to write about those cost factors that I have seen omitted in initial estimations and budgeting.

You do not know what you are replacing

Why are we replacing existing software solutions? One common reason is that the old system is deemed no longer maintainable.

The people that initially built it are no longer around, documentation is long outdated, and nobody knows how the stuff works. Especially tricky are integration points with other software, cronjobs, and background processes. Those "invisible" parts are easily overlooked and often hide powerful mechanisms crafted over years.

When deciding to replace such a system, you have to ask yourself the uncomfortable question: "If I do not know how the existing system works and what it is doing, how do I know what the new one is supposed to do?"

Considerable effort should be invested in understanding the existing solution before replacing it. But that leads to the obvious question: If I need to reverse engineer the existing one anyway, can I not just keep it once I understand it?

You will continue to pay for the old one

... until the new system is ready for production.

Building a new software system can take a while. During that time you are stuck running the old system. That comes with all the costs of maintaining the existing one, and also the opportunity costs of investing all your effort into the new system.

Imagine you have a client who is expanding and would love to buy more of your services. But the old system simply does not support that additional load.

You could maybe find a way, but your resources are all tied up in developing the new, fancy system.

Someone has to maintain the old system

The projects I have been part of had the existing software run for years after the project to replace them started. That was because we underestimated the effort of replacement, but also because of the following dilemma:

The people best suited to build the new system are the same people that keep the old one running.

Splitting up a team is not easy, especially if half of it is stuck maintaining the old system until it is phased out. And what will happen to those engineers once their know-how is no longer needed? Will they move over to develop on the new system? Or do you have enough engineers to do that already?

And having people rotate to work on the new and old system is causing a different set of problems.

You are not replacing version 1.0

This ties into the point from earlier: you do not know what the old system is doing.

You also are not aware of all the tricky bugs that were fixed over the years, the edge cases that caused trouble for months, and the hacky workarounds that were necessary because of reasons nobody remembers.

The old software may be ugly, and slow, and outdated, but is also one other thing: battle-hardened.

When rolling out a new system, there is always problems with it. And especially when replacing a powerful old software monolith, the newly hatched successor may simply not be ready to handle production load.

In more than one case I have seen new systems having to be rolled back, business suffering from repeated outages, and, following those problems, the old system being maintained and run for months or years longer than planned.

That is why I say: you are not replacing version 1.0 with 2.0. You are trying to replace system 1.18.127, and 2.0 is simply not stable enough.

There will be creep

As a project manager trying to replace the old system, how do you obtain budget for the effort?

In the projects I have been part of, often the budget is only agreed on by senior management if the new system can also satisfy business needs the old one can not.

Then there are other stakeholders that want to use the opportunity to get their desperately needed feature in. And it is hard to always say no - especially since you need those stakeholder's cooperation in the project effort.

The scope expands, and expands, until so does the timeline. And the budget.

Conclusion

None of those problems are unsolvable. But before starting on a major replacement effort, carefully consider the alternative:

Renovating old software is hard, but often still quicker and cheaper than replacing it.

Evaluate carefully before you begin working on projects you regret starting!