Every few years I am asked to look at a system that someone has already decided to replace. The decision came first; my job, as framed, is to help execute it. I almost always start by trying to talk them out of it — not because rewrites are never right, but because the decision has so rarely been examined.
A rewrite is the most expensive thing a software team can choose to do. It pauses delivery, discards hard-won knowledge encoded in the existing system, and bets the next year or two on getting right, the second time, the same problems that were got wrong the first time — with the same people, the same constraints, and a deadline that now includes “catch up to where we already were.”
What the system is usually saying
When a platform feels unbearable, the feeling is real but the diagnosis is often wrong. “It’s all legacy” almost always means “two or three parts of it cause most of our pain, and we have stopped distinguishing them from the rest.”
That is a structural observation, and structural observations have structural remedies that fall well short of starting again:
- A single load-bearing component, isolated and rebuilt behind a stable interface.
- A consistency boundary redrawn so that the part needing strict guarantees is separated from the part that does not.
- A hotspot extracted into its own service precisely because it scales differently from everything around it.
Each of these is targeted. Each leaves the working majority of the system in place. Each can be delivered and validated in weeks, with the option to stop if the pain subsides — which it often does, because the pain was concentrated all along.
When a rewrite is genuinely right
I am not categorically against rewrites. There are real cases: a platform built on a runtime that no longer exists, a data model that cannot represent what the business now is, a security posture that cannot be remediated in place. The honest test is whether you can name the specific, structural reason the current system cannot be evolved.
If you can name it precisely, a rewrite may be the right call. If the reason comes out as a feeling — “it’s just old,” “nobody likes working in it” — that is not yet a reason. That is a prompt to go and find the two or three places that are actually generating the feeling.
Replace what cannot be evolved. Evolve everything else. The art is in telling the two apart before you commit a year to the wrong one.
The teams that get this right are not the ones that are most willing to start again. They are the ones that have looked closely enough to know they do not have to.
Worried about a system you're thinking of replacing?