Why the instinct to rebuild from scratch is almost always more expensive than the alternatives — and when it is actually the right call.
There is a moment in almost every engineering team's history when someone says it.
"We should just rewrite this."
The reasoning is familiar. The existing system has accumulated years of technical debt. Every new feature is harder than the last. Onboarding new engineers takes too long. The architecture reflects decisions that made sense at a different stage of the product and no longer serve the current reality.
The rewrite, in this framing, is not just a technical decision. It is a release. A clean start. An opportunity to build the system correctly — with the knowledge the team now has, without the constraints imposed by decisions made under conditions that no longer exist.
This feeling is real and understandable. The instinct it produces is almost always wrong.
What the Data Says About Rewrites
Complete software rewrites fail at a rate that should give any engineering leader pause before committing to one.
The most common failure mode is not technical. It is temporal. The existing system continues to evolve while the rewrite is in progress — new features are added, bugs are fixed, edge cases are handled — and the rewrite is perpetually chasing a moving target. By the time the rewrite is complete, it is already behind. The business has grown around assumptions about the existing system's behaviour that the rewrite team did not fully capture. Users who have adapted to the existing system's quirks encounter the new system's differences as regressions, even when the underlying capability is equivalent.
The second failure mode is scope. A rewrite begins with the intention of reproducing the existing system's functionality. During the build, the team makes decisions that are sensible in isolation but collectively produce a system with different behaviour in edge cases that the original system handled implicitly. The gaps are only discovered after the rewrite is deployed — often by users, often in production.
The third failure mode is opportunity cost. A team focused on a rewrite is not focused on the product. Features are deferred. Competitive responses are delayed. The business pays the cost of the engineering team's divided attention over the full duration of the rewrite — which is almost always longer than estimated.
The Alternative That Gets Underestimated
The approach that consistently outperforms complete rewrites — both in outcome quality and in total cost — is incremental modernisation.
Not as a philosophy, but as an engineering discipline: identifying the specific components of the existing system that are generating the most cost, addressing those components incrementally while keeping the rest of the system operational, and deferring work on components that are functioning adequately.
This is harder to sell than a rewrite. It does not carry the same sense of resolution. It requires ongoing judgment about where to invest rather than a single large commitment. It produces improvements that are visible in delivery velocity and incident rates rather than a dramatic architectural transformation.
But it is almost always the right answer — for the same reason that the Strangler Fig pattern is the right answer for most large-scale migrations: because it keeps a working system operational throughout the improvement process, bounds the risk at each step, and produces measurable value before the entire programme is complete.
When a Rewrite Is Actually Justified
There are circumstances in which a rewrite is genuinely the right decision. They are narrower than most teams assume.
A rewrite is justified when the existing system's architecture is so fundamentally misaligned with current and future requirements that incremental modernisation would require rebuilding it entirely anyway — just more slowly, at higher cost, with a longer period of running dual systems. This situation is rarer than it appears from inside a system that feels broken.
A rewrite is justified when the existing system is built on a technology that is no longer viable — a language or framework that the team cannot hire for, a database architecture that cannot support the current load characteristics, a dependency that is no longer maintained and cannot be safely operated. These constraints are real and require genuine replacement rather than incremental improvement.
A rewrite is justified when the existing system is so poorly understood — so thoroughly lacking in documentation, tests, and institutional knowledge — that incremental modernisation carries risks that are genuinely comparable to the risks of a rewrite. This situation is more common than teams acknowledge and deserves honest assessment rather than optimistic assumptions about what the existing system actually does.
Outside these circumstances, the rewrite is almost always a response to accumulated frustration rather than a response to a technical situation that requires it.
The Conversation Worth Having First
Before any significant modernisation decision, one conversation is worth having explicitly: what, precisely, is the system's current state costing the team?
Not in general terms. In specifics.
Which components are generating the most incident volume? Which are slowing down delivery the most? Which have the highest concentration of knowledge in individuals who are flight risks? Which are preventing product features that are on the roadmap?
The answers to these questions produce a prioritised map of where modernisation investment will generate the most return — and that map is almost always different from the map that instinct produces.
The most painful system is not always the most costly one. The oldest code is not always the biggest drag. The component that generates the most internal complaints is often not the one that, if addressed, would produce the most measurable improvement.
Start with the cost map. Let the cost map determine the scope. The scope it produces is almost always narrower — and more tractable — than the scope that the rewrite instinct generates.
Preserving What Works
There is something important embedded in the rewrite instinct that deserves to be acknowledged rather than dismissed.
A system that has been in production for years, handling real workload, has accumulated implicit knowledge about the problem domain that is genuinely valuable. It handles edge cases that the team has long since forgotten were edge cases. It embodies decisions about behaviour under load that were hard-won through actual incidents. It reflects the accumulated experience of everyone who has operated it.
A complete rewrite discards all of this, along with the technical debt that motivated it.
Incremental modernisation preserves what works while improving what does not. That distinction — preserving accumulated domain knowledge while reducing technical cost — is the most compelling argument for the incremental approach that is rarely articulated clearly enough.
The goal is not to eliminate the history of the system. The goal is to stop paying for the parts of that history that have become a liability.
WiseAccelerate approaches modernisation with a bias toward what can be preserved and improved over what should be discarded and rebuilt. The result is faster delivery of value, lower risk, and systems that carry operational knowledge forward.
→ Has your team been through a rewrite that went as planned? Genuinely interested in the cases where it worked — the conditions seem to matter a great deal.
Top comments (0)