Rewriting a legacy application: when it is the wrong call

The meeting usually goes the same way. A developer who has spent a year inside an old system says, with complete sincerity, that it would be faster to start again. The code is tangled, the platform is out of date, every change hurts. A clean rewrite, six months, and all of this goes away.

It is an honest opinion and sometimes it is right. It is also the proposal most likely to cost a business a year and leave it where it started. The decision deserves more than a feeling about the code.

Why a rewrite is so tempting

Old code is harder to read than to write. Every odd condition in it looks like a mistake to someone who was not there when it was added. Many of those conditions are the record of a real problem: a payment provider that answers twice, a customer type with its own rules, a browser fault from four years ago. Joel Spolsky made this argument in 2000, writing about Netscape, which went almost three years without a major release while it rewrote its browser from scratch. The old code, he pointed out, had been used, tested and fixed; throwing it away throws away that knowledge too.

The same holds for a website. Its pages, addresses and internal links are the result of years of small corrections, and search engines have learned them. A rewrite that ignores them starts again in search as well as in code.

Three routes, not two

The choice is rarely "keep it" or "rewrite it". There are three routes, and most systems suit the second.

• Repair. Keep the system, pay down the worst of its technical debt, upgrade what is out of date. Lowest risk, and enough when the foundations are sound.
• Rebuild in stages. Build the new system beside the old one and move one part at a time, with the old one still serving the rest. Martin Fowler named this pattern the strangler fig, after a plant that grows around a tree until it replaces it. Each stage goes live and is checked before the next begins.
• Rewrite. Build the whole replacement, then switch. Nothing reaches users until the end, and the old system needs upkeep the entire time.

The approaches are compared in more depth in legacy system modernization approaches.

When a full rewrite is the right answer

There are cases where starting again is the sound choice. Look for these conditions together, not one at a time.

1. The platform has no future. It is no longer supported, security fixes have stopped, and there is no upgrade path.
2. The system is small. Small enough that the replacement can be finished in weeks, so the period with nothing new is short.
3. The behaviour is written down. You have, or can produce, a list of what the system does, including the odd cases.
4. The business can wait. No change is urgently needed in the old system while the new one is built.

If the second or third fails, a rewrite is a gamble on finishing before the money or the patience runs out.

What to check before deciding

Whatever the route, the same five things need to be known first. None of them requires a decision about technology.

• An inventory. Every page, address, form and integration the current system has. What is not listed gets lost.
• What earns. Which pages bring visitors and enquiries today. These are protected first.
• What is actually wrong. Slow pages, a blocked upgrade and an unsafe plugin are three different problems with three different costs.
• A baseline. Speed, search visibility and enquiries measured before any work, so the result can be compared afterwards.
• The cost of waiting. What another year on the current system costs. This is the number every option is weighed against.

This is what a modernization assessment produces. You can read a complete sample assessment of a real site to see the level of detail.

A worked example

Take an invented case: a training company with a nine-year-old website, three hundred pages, a booking form connected to its accounts system, and a platform two major versions behind. The developer recommends a rewrite on a new framework.

The inventory changes the picture. Forty of the three hundred pages bring nearly all the search visitors. The booking form has eleven rules nobody had listed. The platform can still be upgraded, but the theme cannot.

So the route becomes a staged rebuild. First the forty pages, on the new platform, at their existing addresses. Then the booking form, with its eleven rules written down and tested one by one. Then the remainder, with pages that earn nothing retired and redirected. At every stage there is a working site, and a measurement against the baseline.

What to do next

Before anyone estimates a rewrite, ask for the inventory and the baseline. If they do not exist, that is the first piece of work, and it is useful whichever route you take. Our website modernization service begins there, with a fixed scope.

Sources

• Joel Spolsky, Things You Should Never Do, Part I, 2000.
• Martin Fowler, Strangler Fig, revised 2024.