When a rewrite is the wrong answer
The strangler-fig case, from Missguided and Sky Casino. Why the honest answer is usually "keep it running and replace it in slices."
Somebody has quoted you for a rewrite. The number is large, the timeline is optimistic, and the pitch is that everything gets better on the other side.
The pitch is usually wrong, and not because rewrites never work. It is wrong because the thing being proposed is a replacement, and what you actually own is a live system with customers on it.
What the rewrite quote is really pricing
A rewrite prices the code. It does not price the behaviour: the decade of accumulated edge cases, the undocumented integration that finance depends on, the branch of logic that exists because a regulator once asked for it.
That behaviour is the expensive part, and it is not in anybody's estimate because it is not written down anywhere. It is discovered, slice by slice, usually after the new system is already carrying traffic.
The alternative, concretely
On Missguided the front end came off a legacy Magento stack while the site kept trading. On Sky Casino the Next.js front end was re-platformed on a product serving millions of customers, in a regulated sector, with no maintenance window available. Neither was a rewrite. Both were migrations run in slices:
- Stand the new path up beside the old one. Not instead of. Beside.
- Move a thin slice of traffic across. One route, one journey, one customer segment.
- Verify parity against production, not against a spec. The old system is the specification, whether or not anyone likes that.
- Retire the legacy path for that slice, and only then take the next one.
Every step is reversible. That is the entire point. On a bad day you move traffic back and go home, rather than discovering at 2am that the rollback plan was a paragraph in a document.
When a rewrite genuinely is right
It happens. The honest signals are narrow:
- The runtime or framework is out of support and cannot be upgraded in place.
- The data model is wrong in a way that no amount of refactoring reaches.
- The system is small enough that a full replacement fits inside one planning cycle with room to spare.
Notice that "the code is bad" is not on that list. Bad code that works is an asset with a maintenance cost. Bad code that has been replaced by unfinished code is a liability with no revenue attached.
The question to ask instead
Not "should we rewrite this?" but "what is the smallest slice we could move and prove?"
If nobody can answer that, the system is not understood well enough to replace yet, and the rewrite would have failed on exactly that gap, six months and a lot of money later.