Before you rebuild: a checklist for legacy modernisation

There is a moment in the life of most business applications when the team maintaining it stops saying 'we should improve this' and starts saying 'we should replace this'. The change in language matters, because a replacement is a fundamentally different proposition: it pauses improvement of the thing customers use today, in exchange for a benefit that arrives at an uncertain point in the future.

Sometimes that is the right trade. More often the same outcome is available through a series of smaller changes that never require the business to hold its breath. Before committing either way, these are the questions worth answering.

1. What is the actual complaint?

'The system is old' is not a business problem. Slow delivery of new features, an inability to recruit people willing to work on it, unacceptable downtime, cost of operation, or a security position that is failing customer review — those are business problems, and they have different remedies. A rewrite addresses some of them and not others. Write the complaint down in terms a finance director would recognise before deciding anything.

2. Where is the knowledge?

Legacy systems accumulate rules that exist nowhere else: the discount that applies to one customer category, the file that must be produced for a regulator every quarter, the tax edge case handled by a condition somebody added in 2016. If that knowledge lives only in the code and in the memory of people who may have left, a rewrite is not a software project. It is an archaeology project with a software project attached.

The test is simple and uncomfortable: can anyone produce a list of the system's business rules? If not, budget for discovering them, and expect that discovery to reveal at least one rule everybody had forgotten and one the business would like to change.

3. Can it be replaced in pieces?

The most reliable modernisation pattern is incremental replacement: put a routing layer in front of the old system, move one capability at a time to new code, and shrink the old system until what remains can be retired quietly. It is slower to start and considerably safer, because every step is small, verifiable and reversible.

It is not always possible. A monolithic data model with no clean boundaries may resist decomposition to the point where the effort exceeds the rewrite. But the question deserves a real attempt before being dismissed, because the alternative asks the business to accept a long period with no improvement and a single, large moment of risk at the end.

4. What happens to the data?

Migration is routinely underestimated, and it is where rewrites go over schedule. Years of accumulated data will contain records that violate the constraints the new system assumes: missing fields, duplicates, values that were valid under rules that changed, encodings from a previous decade.

Run a migration rehearsal against a full copy of production early — not near the end. The point is not to succeed. It is to find out now how bad the data is, while there is still time for that knowledge to change the plan.

5. Who will run it afterwards?

A modern system is not automatically an easier system. Replacing one application with a distributed architecture can trade a maintenance problem for an operations problem, and hand a team that was comfortable with the old system a set of failure modes it has never seen. Choose the target architecture partly on the basis of who has to operate it on a Sunday.

6. How will you know it is correct?

Where the old system has few automated tests, the safest verification is comparison: run both systems against the same inputs and compare outputs until the differences are either zero or explained. This is more work than it sounds and it is worth it, because 'the new system produces a different number' is a problem you want to find before your customers do.

7. What does doing nothing cost?

This is the question most often left out, and it is a real option that deserves pricing like any other. Sometimes the honest answer is that the system is unloved but stable, the complaints are aesthetic, and the money would do more good elsewhere. A recommendation to leave a system alone for another two years is a legitimate outcome of an assessment, and a considerably cheaper one than discovering the same thing halfway through a rebuild.

The goal is not a modern system. The goal is a business that can change quickly without being afraid of its own software.

If you do decide to rebuild

Keep the old system running and authoritative until the new one has genuinely proven itself. Ship the first capability to real users early, even a small one, because a replacement that has never met production traffic is an estimate rather than a system. Agree in advance what would cause you to stop. And write down the business rules as you find them, in a document rather than only in code, because the next team will thank you and it may well be you.