Almost every team that lives with an old system has the same dream. Stop patching. Start again. Build it properly this time, with modern tools and everything we have learned.
I understand the dream. I have shared it. And I have seen what usually happens next.
The rewrite takes longer than planned. The old system keeps running, keeps changing, and keeps needing fixes, so the team is split between two products. The new system has to match years of behaviour that nobody documented. Halfway through, the business asks for new features, and they have to be built twice. Eventually, someone asks the question nobody wants to answer: when will the new one actually replace the old one?
Big-bang rewrites are not always wrong. But they are wrong far more often than teams expect, and the cost of being wrong is enormous.
Why Rewrites Disappoint
The old system is ugly, but it is also full of knowledge. Every strange condition, every special case, every odd piece of logic is there for a reason. Some reasons are obsolete. Many are not. They are customer agreements, regulatory details, and fixes for incidents that happened years ago.
A rewrite throws all of that away and assumes the team can rediscover it. In practice, they rediscover it the hard way: in production, from unhappy customers.
There is also a simpler problem. A rewrite delivers no value until it is finished. For months, sometimes years, the business pays for a second system that nobody uses. That is a hard position to defend in a budget meeting, and many rewrites are cancelled before they finish. The company ends up with the old system, plus a half-built new one, plus a tired team.
The Strangler Approach
There is a quieter alternative, named after the strangler fig: a plant that grows around an old tree, slowly, until it can stand on its own and the old tree is no longer needed.
Applied to software, the idea is simple. You do not replace the system at once. You replace it piece by piece, while it keeps running.
- Put a layer in front. Route traffic to the old system through a thin layer you control: a proxy, a gateway, or an interface in the code. At first, it passes everything through unchanged.
- Pick one piece. Choose a part of the system that is valuable to improve and reasonably separate from the rest. Build the new version of just that piece.
- Redirect gradually. Send a small share of the traffic for that piece to the new version. Compare results. Fix differences. Increase the share when you trust it.
- Retire the old piece. When the new version handles everything, remove the old code for that piece.
- Repeat. Move to the next piece. Each step delivers something real and reduces the size of the old system.
At every point, the business keeps running. At every point, you can stop, and what you have built is still useful.
Five Decisions for Every Component
Not every part of an old system needs to be replaced. Strangling works best when each component gets a deliberate decision, with the reasoning recorded:
Keep It works, it rarely changes, and it is not blocking anything. Leave it alone.
Refactor The behaviour is right but the structure is painful. Improve it in place, under tests.
Replace The behaviour is understood, but the implementation cannot carry where the business is going. Rebuild that part, not the whole system.
Isolate It is risky and poorly understood, but stable. Put a clear boundary around it so it stops constraining everything else.
Retire Nobody uses it, or nobody should. Remove it. This is often the cheapest improvement available.
A modernisation plan is just this list, in order, with the business reason for each choice.
What Makes It Work
Strangling is not free. It needs a few things in place:
- Tests around current behaviour. Before you replace a piece, capture what it actually does today, including the strange parts. These tests are how you know the new version is equivalent.
- Observability. You need to see what each version is doing in production, so you can compare them with evidence instead of hope.
- A clear order. Start where the value is highest and the risk is manageable. Do not start with the most tangled core.
- Patience from leadership. Progress is steady, not dramatic. There is no single launch day to celebrate. There are many small ones.
When a Rewrite Is Actually Right
To be fair, there are cases where starting again is the better choice. When the system is small. When the technology is truly unsupported and cannot run safely. When the business itself has changed so much that the old behaviour no longer matters.
But "the code is ugly" and "nobody wants to work on it" are not, on their own, good reasons. They are reasons to improve it.
The Business Keeps Running
The best modernisation is one your customers never notice. No freeze, no migration weekend, no months of waiting for a new system. Just a product that steadily becomes easier to change, safer to release, and cheaper to run.
You do not have to stop the business to fix the system it depends on. Grow the new one around the old, one piece at a time, until the old one is simply no longer needed.
