The big rewrite almost always loses. I have seen it kill momentum at companies that were otherwise winning, burn through 18 months of engineering capacity on a project that shipped late, over-budget, and missing half the features that made the original valuable. I have seen leadership teams, convinced they were being bold, hand their competitors a window they never recovered from.
And yet the rewrite conversation comes up constantly. Every leadership team sitting on a legacy codebase eventually reaches for it.
Here is my position, sharpened after watching this play out across energy, insurance, reinsurance, and manufacturing: a full rewrite is the right call in exactly one situation. Outside that situation, it is almost always a failure of imagination — or nerve.
Why Rewrites Feel Rational (And Aren't)
The argument for a rewrite is seductive because it is built on a real problem. The existing system is slow to change. Engineers spend 60% of their time on maintenance. New features take three sprints when they should take one. The architecture — made sense in 2016 but doesn't scale to where the company is now. The founding engineer who understood it all left in 2022.
All of this is real. And all of it can be addressed without a rewrite.
The rewrite argument commits a systematic error: it treats the accumulated knowledge embedded in the existing system as worthless. It isn't. Legacy systems, however messy, contain years of hard-won understanding: edge cases discovered in production, compliance requirements that were built in after a painful audit, integration behaviours that aren't documented anywhere but are relied upon by downstream systems.
Joel Spolsky called it in 2000: "It's Netscape's biggest mistake." The browser market changed while Netscape rewrote from scratch. By the time they shipped, Internet Explorer owned the web. The new codebase was not better enough to compensate for the time lost.
The pattern repeats across industries. The Why is always the same: the team building the new system learns what the original team learned — but they learn it from scratch, at the cost of competitive time, and they usually underestimate it by a factor of 2 to 3.
Hofstadter's Law, applied to rewrites
Rewrites take longer than you think, even when you account for the fact that they take longer than you think. The original system's hidden complexity — the edge cases, the production-hardened behaviours, the integrations nobody documented — does not appear in the new system's scope until the new system goes to production. Then it appears all at once.
What "Modernise Without a Rewrite" Actually Looks Like
The alternative to a full rewrite is not accepting the status quo. It is a disciplined programme of incremental improvement that delivers business value throughout — not at the end of an 18-month project.
The canonical approach is the Strangler Fig pattern, named by Martin Fowler: you build new functionality around the edges of the existing system, gradually replace components, and decompose the monolith over time without ever stopping the business to do it. The old system shrinks as the new system grows. At no point is the company entirely dependent on an unproven replacement.
This approach has a critical property: it is reversible at every step. If you build a new payments microservice and it underperforms, you route traffic back to the monolith. The company loses a sprint, not a year.
The Strangler Fig pattern in practice looks like this:
| Approach | Time to first production value | Risk profile | Reversibility | Competitive window ceded |
|---|---|---|---|---|
| Full rewrite | 12–24 months (usually more) | Very high — entire bet on delivery | None until done | Large |
| Strangler Fig / incremental | 4–8 weeks (first slice) | Low — each slice is small | Yes, at every step | Minimal |
| Big bang module replacement | 6–12 months | High — coordinated cutover | Partial | Medium |
| Replatform (infra only) | 2–4 months | Medium | Yes | Small |
The table above is a simplification, but the pattern holds: incremental approaches deliver earlier, carry less risk, and preserve optionality. Full rewrites maximise all three risk factors simultaneously.
The Signals That Lead to the Wrong Decision
Rewrite proposals usually emerge from one of three organisational failure modes — none of which are solved by a rewrite.
Engineering frustration without business context. Engineers who live inside a painful codebase develop strong aesthetic preferences for a clean-slate solution. This is entirely understandable. It is also not a business case. Slow feature delivery, high maintenance cost, and technical debt are legitimate business problems — but the business case should evaluate all solutions, not assume that the most radical one is also the most effective.
New technical leadership. A new CTO or VP Engineering arrives, spends 90 days assessing the codebase, and proposes a rewrite. This is almost reflexive in the industry. The incoming leader wants to build their reputation on something definitive, and "we're going to modernise the platform" sounds bold. Measured against the alternative — a multi-year incremental programme with less dramatic framing — the rewrite feels more decisive. The company pays for that feeling.
Using technology as a proxy for strategy. Sometimes companies want to rebuild because the business is struggling, and the hope is that a new technology stack will solve problems that are actually about product-market fit, go-to-market, or organisational dysfunction. Technology is a lever. It cannot substitute for strategy.
What I ask before any modernisation conversation
'What business outcome are you unable to achieve today because of the current system — and by how much?' If the answer is vague (the team is unhappy, the code is messy), the problem is not architectural. If the answer is specific (we cannot launch in Germany because the data model doesn't support multi-tenancy, and that's costing us €2M ARR), we have something to work with. Specific business problems have specific solutions. They rarely require a full rewrite.
The One Exception: When a Rewrite Is Right
There is exactly one situation where a full rewrite is the right call.
When the existing architecture cannot support a mandatory, near-term business requirement — and the cost and risk of incrementally adapting it exceeds the cost and risk of replacement.
This is a high bar. Let me make it concrete.
The situation I have seen justify a full rewrite: a company acquires a competitor, and the two systems must become one. The combined product must exist within 18 months for regulatory or contractual reasons. The integration path between the two systems is genuinely intractable — not difficult, but architecturally impossible without rewriting both. And the combined market opportunity is large enough to justify the investment and the risk.
Or: a system built on a technology platform that has reached genuine end-of-life — not just "old," but actively unsupported, with no security patches, and no upgrade path. The incremental migration is more complex than a rebuild because the framework assumptions are so different that every component must change anyway.
Or: a compliance requirement (GDPR, PCI DSS, DORA) that the existing architecture structurally cannot satisfy — not because it wasn't implemented, but because the data model or security architecture makes compliance impossible to retrofit.
In all three cases, note what is not on the list: "the code is hard to work with," "engineers prefer a different stack," "the architecture is not what we'd design today," or "we want to adopt microservices." These are not valid reasons for a full rewrite.
The test is: Can I articulate a specific business outcome that is structurally impossible with the existing system, where the cost and risk of incremental change exceed the cost and risk of replacement? If yes — and only if yes — a rewrite is on the table.
How to Run a Rewrite If You Must
If you have passed the test above and a rewrite is genuinely the right call, the execution discipline is what separates a survivable rewrite from a fatal one.
The existing system stays live and continues to receive critical bug fixes throughout the rewrite. The new system is developed in parallel. There is no moment where the company is dependent on a system that hasn't yet been proven in production.
Specify in advance: what does the new system need to demonstrate before traffic is routed to it? Load test results, feature parity list, compliance certification, acceptance testing with key customers. If you do not define this upfront, the cutover decision becomes political — and political decisions under schedule pressure are almost always wrong.
Even when doing a "full" rewrite, migrate customer segments incrementally. Start with the simplest 10% of users. Run the old and new systems in parallel for overlapping user cohorts. This surfaces production behaviour before it affects critical accounts.
Every behaviour in the old system — including the undocumented ones — is a feature until proven otherwise. Log extensively what the old system does in edge cases. Replay production traffic against the new system before cutover. Assume you have missed something; build the infrastructure to find it.
Organisations routinely maintain both systems in perpetuity because the cutover is uncomfortable. This doubles the maintenance burden. Set a date before the rewrite starts. After that date, the old system gets no engineering investment and is decommissioned. This creates the pressure to actually cut over — and prevents the indefinite parallel operation that defeats the purpose of the rewrite.
The Conversation I Have With Every Leadership Team
When a CEO or board asks me about a rewrite, my first question is always: "What would it take to achieve the same business outcome without one?"
This is not a rhetorical question. I work through it seriously. If the answer is "18 months of incremental work vs. 18 months of rewrite," the incremental path wins on risk alone. If the answer is "we'd have to restructure the data model across 47 tables and it would be more disruptive than a rewrite," that is useful — and sometimes the honest conclusion is that a targeted rewrite of a specific component (not the full system) is the right call.
Most rewrite proposals, when interrogated properly, turn into targeted modernisation programmes. A specific service that genuinely needs replacing. A database migration that unlocks a new capability. An API redesign that enables the partner integrations the business needs. These are all rewrite-adjacent — but they are scoped, bounded, and deliverable without betting the company on an 18-month programme.
The companies that navigate legacy modernisation well are the ones that resist the theatrical appeal of the clean slate and instead build the discipline to improve continuously. They are never "done" modernising, but they are also never stopped by it.
The companies that bet on the big rewrite — without meeting the one legitimate exception — typically find out why it was a bad bet about 14 months in, when the original system is still running, the new system is six months behind schedule, the engineers who know the old system are exhausted, and the competitive window that justified the investment has quietly closed.
The bottom line is hard but clear: the rewrite is almost always the wrong answer. The discipline to improve incrementally, to make the hard architectural changes in small steps, and to resist the false promise of the clean slate — that is the work. It is less dramatic. It compounds.
If you are facing a legacy modernisation decision and want a clear-eyed assessment of whether a rewrite is actually justified or whether there is a better path, let's talk — book a 30-minute discovery call and we will work through the decision framework together.