Legacy systems: full rewrite or refactor in place?

In most cases, replace it piece by piece. A rewrite from scratch is only justified when the underlying platform has lost security support, or when the original data model is blocking the business from growing. Short of that, you will spend two years rebuilding features that already worked.

The request always arrives with the same sentence: “this system is a mess, better to rebuild it from scratch”. Sometimes that is true. Most of the time it is the natural reaction of someone dealing with code they did not write, and a full rewrite is the most expensive decision you can make about a system in production.

What a rewrite actually costs

The budget always accounts for rebuilding what you can see. It never accounts for five years of invisible fixes baked into the current system.

That odd if in the shipping calculation is not bad code. It is the exception in the contract with that large customer, sorted out on a Friday afternoon in 2019. The new system, clean and well architected, will not have that if. It will have the same problem that customer complained about in 2019.

Then there is the detail that kills schedules: during the rewrite, the old system cannot stop evolving. The business keeps asking for things. Either you freeze the product for two years, which no company survives, or you implement everything twice.

When a rewrite genuinely is justified

There are legitimate cases and they are recognisable:

• The platform has lost security support. A language or framework version with no vulnerability patches is not technical debt. It is legal and operational risk.
• The data model blocks the business. The system was built for one company and one currency, and now there are five branches across three countries. If every new requirement hits the same structural wall, the foundation is the problem.
• Nobody can touch it anymore. Not because it is ugly, but because nobody with that technology exists in the market and there is no test giving anyone confidence to change anything.

Notice that “the code is ugly” and “we do not like that language” are not on the list.

The alternative: strangle the legacy slowly

The approach that works is known as the strangler fig, after the tree that grows around its host until it replaces it entirely. In practice:

1. Put a router in front of the old system. Everything keeps working as before.
2. Pick one feature with a clean boundary and high value. Rebuild only that, in the new stack.
3. Route that feature’s requests to the new system. If it goes wrong, route them back in under a minute.
4. Repeat. With every cycle the legacy shrinks.

The advantage here is not even technical, it is political. The project delivers visible value every month instead of asking for two years of faith. That changes how the board sees the investment and, in practice, is what gets the project finished.

Before choosing either path, put a net under the legacy

Whatever you decide, do this first, because it serves both strategies:

• A backup you have restored. Not “backups are configured”. Restored, into another environment, with a date written down.
• Tests on the flows that make money. Do not chase broad coverage. Cover the five paths that cannot break.
• Logging and monitoring. You need to know what the system is doing before you change it. Plenty of teams discover at this stage that half the screens are never used, which halves the scope of the rewrite.
• A staging environment that is a faithful copy. Without it, every change is a gamble.

That work takes three to six weeks and frequently changes the conclusion. I have watched several systems that “had to be rebuilt” turn into perfectly acceptable systems once they had monitoring, indexes and the removal of what nobody used.

The question that decides it

Just one: is the current system stopping the company from doing something it needs to do in order to grow?

If the answer is no, it is annoying, it is slow, it is ugly, but the business runs, then improve it in place. If the answer is yes and you can name exactly what is blocked, there is a concrete case. And even then, replacing piece by piece usually gets there sooner.