Legacy software: modernise, rewrite or replace?
The three options for an old system the business depends on, the questions that decide between them, and the staged path that usually wins.
The short answer
An old system the business depends on presents three options. Modernise: keep it and improve it in place with tests, monitoring, dependency updates and targeted fixes. Rewrite: build a new system to the same purpose and switch over. Replace: buy a product that does the job and migrate to it. Four questions decide between them: does the system still do what the business needs, can it be changed safely, can it be run and secured, and is there a product that genuinely fits? Rewrites are the most attractive option and the most often regretted. The path that usually wins is staged: stabilise the old system, put a stable interface in front of it, and replace it piece by piece while it keeps running.
The three options
| Modernise | Rewrite | Replace with a product | |
|---|---|---|---|
| What it is | Improve in place: tests, monitoring, updates, refactoring, targeted rebuilds | Build new to the same purpose; switch over when done | Adopt a product; migrate data; adapt processes |
| Best when | The system does the job and the foundations can be trusted once stabilised | The foundations cannot be trusted and no product fits | The process is standard and a mature product fits |
| Risk | Slower to transform; some constraints remain | Longer than planned; lost behaviours; nothing delivered until the end | Fit gaps; migration; vendor dependence |
| Delivers value | Continuously | At the end | At go-live |
| Typical mistake | Never getting past patching | Choosing it because new is more fun | Forcing a non-standard process into a standard product |
The four questions
- Does it do what the business needs? If yes, the case for a rewrite is weak; modernise. If no, what is missing, and can it be added?
- Can it be changed safely? With tests, types, a pipeline and documentation, changes are safe. Without them, add them first; that is modernisation, and it is often enough.
- Can it be run and secured? Unsupported platforms, unpatched dependencies and unavailable skills are real reasons to move, in stages.
- Is there a product that fits? Honestly assessed: standard process, clean migration, acceptable exit. If yes, replacing beats building again.
The staged path
Stabilise first: backups, monitoring, the riskiest updates, tests around the behaviours that matter. Put a stable interface in front: an API or a routing layer that callers use, so what sits behind it can change. Move one function at a time to the new implementation, behind a flag, comparing outputs with the old one until confident. Retire each old piece as its replacement proves itself. At every stage the system works, value is delivered and the next step is reversible. The rewrite happens, but nobody has to bet the business on a launch date.
What this means for you
Do not choose between modernise, rewrite and replace by instinct. Answer the four questions with evidence, stabilise the old system regardless, check honestly whether a product fits, and prefer the staged path over the big bang. The old system that everyone fears usually needs a safety net more than a replacement, and the replacement, when needed, goes best one piece at a time.
Frequently asked questions
The system works but nobody dares change it. Which option is that?
Modernise first: add tests around the behaviour that matters, add monitoring, update the riskiest dependencies, document what it does. That alone often turns a frozen system into a changeable one. If, after that, the foundations still cannot be trusted, replace the worst parts in stages. The fear is usually about the absence of a safety net, not the code.
Why are rewrites so risky?
Because the old system encodes years of decisions nobody wrote down, in edge cases and quirks users depend on. A rewrite rediscovers them one complaint at a time, after launch. And it delivers nothing until it is finished, which is always later than planned. Staged replacement delivers value throughout and keeps the old behaviour available for comparison.
When is buying a product the right answer?
When the process the system supports is genuinely standard, when a mature product fits without heavy customisation, when the data can be migrated cleanly, and when the exit terms are acceptable. Many internal systems were built because nothing fitted; the market may have caught up. Check honestly before building again.