Choosing between a rewrite and a strangler

The request usually arrives already decided. Budget has been approved for a replacement, someone has drawn the target architecture, and the question put to us is how long it will take. By the second conversation it often emerges that nobody currently at the client has read the code in the system being replaced.

We start from the assumption that a strangler is correct and ask the client to argue us out of it. Rewrites are not always wrong. The asymmetry sits in the failure modes. A strangler that stalls leaves a working system and a wasted quarter. A rewrite that stalls leaves two systems, neither of which anyone fully trusts, and a business that has stopped investing in either.

What the strangler actually costs

The pattern is well documented. The cost is less so. You put a facade in front of the old system, route one capability at a time through the new one, and retire the old path once the new one has carried real traffic under real load. For the duration you are running two systems, paying for two sets of infrastructure, and reconciling their outputs.

Reconciliation is where the budget goes. On anything with money in it, comparing the two systems is a standing team activity for the length of the migration, and it finds genuine differences. Most of those differences turn out to be the old system being quietly wrong in a way the business adapted to years ago. Deciding whether to reproduce the bug is a commercial decision, and it will come up more than once.

The seam is the other expensive part. Every capability you move needs a decision about where its data lives during the transition, which system is authoritative, and what happens when the two disagree at three in the morning. Teams who have only read about the pattern draw a clean vertical line through the architecture and discover later that the line runs through a shared database table four other capabilities also write to.

When a rewrite is genuinely correct

Four conditions, and they apply to anything large enough for the question to be worth asking. We look for all four, and we have yet to see a case where three were enough.

• The behaviour of the existing system is known, written down, and small enough that one person can hold it in their head. Having the source code is a different thing from having the behaviour.
• The platform is genuinely unsupportable. No build, no toolchain, nobody who can compile it. A facade needs something to attach to, and at that point there is nothing to attach to.
• The business process is changing anyway, so behaviour parity was never the goal. When the target is a different process, the old system stops being the specification.
• Every downstream consumer can be enumerated and contacted. This is the condition that fails.

A system that has run for a decade grows consumers the way an old building grows cabling. Scheduled extracts. An ODBC connection someone set up for a quarterly board pack. A nightly email to a distribution list that still contains two people who left. A spreadsheet in a shared folder that pulls one table and drives regional targets. None of these appear on the integration diagram. All of them break at cutover, and they tend to break in the second week rather than the first, which is worse, because by then the launch has been declared a success.

Where we got this wrong

We argued for a strangler on a system that did not need one. The facade took a quarter to build and sat in front of an interface with a handful of callers, every one of which we could already name. Replacing the thing outright would have taken less time than the scaffolding did. The evidence was sitting in our own discovery notes: we had listed every consumer on a single page. We had a default position and we applied it instead of reading our findings.

The argument worth having is rarely about the pattern. It is about the inventory: what runs against this system, who owns each of those things, and how much confidence anyone has that the list is complete. Answer that honestly and the pattern tends to choose itself. Teams that skip it usually choose the rewrite, because the rewrite is the option that lets you avoid finding out.