The case against the big rewrite

The big rewrite is an appealing story. The old system is a mess, the team is frustrated, and a clean slate feels like the only way forward. So a programme is funded, the old system is frozen, and two years later the new one is half-built and the business is running on a platform nobody is allowed to touch.

Why it fails

The old system encodes years of decisions, including the ones nobody documented. A rewrite team discovers them one at a time, in production, usually as bugs. Meanwhile the business keeps changing, so the target moves while the team builds.

There is also a knowledge problem. The people who understand the existing system are rarely the ones building the replacement, and they are usually fully occupied keeping the lights on.

The alternative: replace it in slices

We favour incremental replacement. Put a stable interface in front of the existing system, then replace one capability behind it at a time. Each slice ships, is measured, and either stays or is rolled back. The business never stops, and the team learns the domain as it goes.

• Start where the pain is highest and the coupling is lowest.
• Write tests around the old behaviour first so you can prove the new slice matches it.
• Keep the old path live until the new one has run in production through a full cycle.
• Retire the old component only when nothing calls it, not when the calendar says so.

It takes discipline

Incremental replacement is harder to explain on a slide than a rewrite. There is no dramatic launch, and progress is measured in capabilities migrated rather than a completion percentage. But it is the approach we have seen succeed, repeatedly, in systems where a rewrite would have been a gamble with the business itself.