When a Rewrite Is the Wrong Decision

In almost every system that has grown over time, there comes a moment when the idea becomes irresistible: let's throw out the old one and rebuild it properly. The code is hard to follow, the decisions made back then look wrong, every change feels like a struggle — and the rebuild promises a clean start, free of the baggage, with today's tools. Few proposals are as tempting, and few fail as reliably. This document is about why that is — and about when a rebuild is the right decision despite everything.

It is a document about restraint. A software company that earns money from a rebuild will often advise against one here, and that is precisely what makes the advice credible: the honest answer to "should we rebuild?" is usually no, and anyone who only says so when it serves their own business is not a reliable advisor. The text names no tool and no number; it describes what a rewrite really costs, what it throws away, and the few cases in which it is still the right path.

1. Why the rewrite is so tempting

The appeal of a rebuild draws on a real experience: the existing system is unpleasant. You read someone else's old code or your own, no longer understand the decisions behind it, run into entanglements nobody can explain anymore, and every change feels like reaching into clockwork whose springs you don't know. Against this stands the image of the rebuild: a blank sheet, today's tools, the freedom to get it right this time. The math seems simple — the old is hard, the new would be easy.

That math is seductive because it pits a real pain against an imagined ease. The pain of the old is concrete and felt every day; the ease of the new is an idea that has not yet touched reality. You compare a system that carries all the compromises of reality with one that hasn't made a single compromise yet — and overlook that the new system will make the same compromises as soon as it meets reality. The appeal of the rewrite is the appeal of the unburdened, and it stays unburdened only as long as it doesn't exist.

Trade-off. Resisting the appeal means continuing to bear the daily pain of the old instead of following the promise of the new — that is uncomfortable and feels like standing still.

Cost. Restraint requires improving the unpleasant system instead of replacing it — more tedious, less satisfying work than starting over.

When we decide differently. Where the old system is not merely unpleasant but fundamentally built wrong (see chapter 5), the appeal is not an illusion but a signal — and then you follow it with care.

2. What a rewrite really throws away

An existing system is more than its code — it is condensed knowledge. Every odd branch, every special case, every comment that sounds like a forgotten incident is the trace of an experience: a bug that once occurred and was fixed, an edge case reality demanded, a requirement nobody documented anymore but somebody still needs. This knowledge is invisible as long as the system runs — and it is exactly what a rewrite throws away.

The rebuild starts from a clean model of the requirements as they are understood today — and that understanding is always incomplete, because the old system took years to collect the exceptions it handles correctly today. The new system won't know these exceptions until it makes the same mistakes again, goes through the same incidents again, and learns the same edge cases again, painfully. What looked like messy code was often hard-won correctness. A rewrite trades a system that knows the exceptions for one that has to learn them all over again — and you don't pay that price in code, you pay it in outages.

Trade-off. Giving up the embedded knowledge buys a clean start at the cost of everything the old system has learned over the years.

Cost. The lost knowledge comes back as a series of incidents — the new system learns the exceptions all over again, this time in production and in full view of its users.

When we decide differently. Where the old system's embedded knowledge is slight or wrong anyway — a young system, a fundamentally flawed one — losing it weighs little, and the rebuild loses its terror.

3. The second-system effect

There is a recurring irony in rebuilds: the second system a team builds is often worse than the first, not better. Freed from the constraints of the old and driven by the wish to get it right this time, the rebuild tends to want too much — to include every idea that was missing in the old system, to provide for every flexibility anyone ever wished for, to introduce every abstraction that seems more elegant. What emerges is not the lean, clean system you had imagined but a new one weighed down by its own ambition.

The reason is as predictable psychologically as it is technically. The old system was created under pressure and with limited knowledge, and therefore has a certain plainness — it does what was needed. The rebuild grows out of frustration with the old and the belief that you know better, and that attitude invites overdelivery. You don't rebuild what is needed but what is wanted — and what is wanted is always more than you need. Premature abstraction, over-engineered flexibility, complexity without cause: the rebuild is their natural breeding ground. What was meant to be a leaner system therefore often becomes a more complex one — just with newer code and without the quiet maturity of the old one, which had at least paid dearly for its complexity.

Trade-off. Avoiding the second-system effect requires a discipline in the rebuild that runs counter to the liberating feeling of the blank sheet.

Cost. That discipline strips the rebuild of the very appeal that made it attractive — the right to finally build in everything you ever wanted.

When we decide differently. An experienced team that knows the effect and deliberately forces itself toward simplicity can contain it; where that maturity is missing, the effect is almost unavoidable and the rebuild all the riskier.

4. The running system is a moving target

The practical reason rewrites fail so often is simple: the old system doesn't stand still while you build the new one. It keeps running, it carries the business, and it has to be maintained and extended — every urgent requirement, every new edge case, every fix that comes up during this time goes into the old system. The new system, which is supposed to catch up with the old one, is chasing a moving target. No sooner has it caught up than the old one has moved on.

Diagram: While the rebuild catches up, the old system keeps evolving. You are chasing a moving target — and in the long interim, you run two systems instead of one.

What makes it especially treacherous is that the rebuild feels almost finished long before it is. The visible, common cases are rebuilt quickly and create the impression that most of the work is done. What's missing are precisely the rare exceptions and edge cases — the ones the old system collected over years and that make up most of its true complexity. So the rebuild often sits at seemingly almost done for a long time while the most laborious remainder is still outstanding. This gap between perceived and actual progress is one of the main reasons rewrites overrun their deadline and budget so reliably — and why the interim lasts longer than any plan anticipated.

This long interim is the real price. As long as the rebuild isn't finished — and it almost always takes longer than planned — you operate and maintain two systems: the old one that runs and the new one that can't do the job yet. The capacity you would need for actually moving forward is tied up, and the business stands still even though a lot of work is being done. It is precisely in this phase that most rewrites lose the trust they would need to be completed.

Trade-off. The incremental alternative avoids the moving target, but buys that with slower, less visible progress instead of one big fresh start.

Cost. Over its entire, usually underestimated duration, a rewrite ties up the capacity for two systems and paralyzes actual product development.

When we decide differently. Where the old system can be frozen — no new requirements, only upkeep — the moving target disappears, and a rebuild becomes more manageable.

5. When a rewrite is the right call after all

This document is not a rejection of every rebuild, only of the rebuild born of frustration. There are cases in which the rewrite is the right decision — and they share one characteristic: the foundation of the old system is fundamentally wrong, not just unpleasant. When the load-bearing structure fundamentally cannot meet a requirement that is central today; when the underlying technology has reached the end of the road and has no future; when the cost of evolving the old system exceeds that of a rebuild over the foreseeable lifetime — then the rebuild is not an escape but the sober answer.

The difference lies between "the old system is hard to change" and "the old system cannot become what it needs to be." The first is a reason to modernize; the second is a reason to rebuild. The honest assessment therefore doesn't ask whether the old system is unpleasant — almost every grown system is — but whether its core can carry what will be required in the future. If the answer is yes, the rewrite is almost always the more expensive route to the same destination. If it is no, it is the only route, and then you take it deliberately and with open eyes about its price.

Trade-off. Choosing a rebuild only when the foundation is fundamentally wrong means continuing to put up with many unpleasant systems — in exchange for separating the rare right rebuild decision from the common wrong one.

Cost. The honest assessment requires separating your own frustration from the objective finding — a self-discipline that is hard to muster when you are annoyed with the old system.

When we decide differently. If the finding is clear — a dead foundation, an unmeetable core requirement — you don't hesitate on principle; the restraint applies to the rebuild driven by discomfort, not the one driven by objective necessity.

6. The alternative: replace incrementally

There is almost always a third way between "carry on as before" and "rebuild everything": replace the old system incrementally, piece by piece, while it keeps running. You extract one part, rebuild it, switch over, and the system remains functional the whole time. That way you get renewal without the long, risky interim of the big rebuild, without the moving target and without losing all the embedded knowledge — because you only replace what you have understood and keep the rest until its turn comes.

Diagram: The big rebuild carries its risk concentrated at the end; incremental replacement spreads it across many small switchovers, none of which endangers the whole system.

This path is less satisfying than the big fresh start, because it offers no clean break and no day on which everything is new. That is exactly its strength: at no point does it risk losing the entire system, because at no point does it replace the entire system. Anyone who feels the pull of the rewrite but knows its price usually finds in incremental replacement what they really wanted — a better system — without what they didn't want — the risk of losing it along the way. What this path looks like in practice is covered in modernization without a big bang.

Trade-off. Incremental replacement buys safety and continued operation with slower, less visible progress and by giving up the clean break.

Cost. For a while, you have to live with a system that is half old and half new, and carefully maintain the boundary between the two.

When we decide differently. Where a system cannot sensibly be broken down into replaceable parts and its core has to be renewed anyway, the incremental path is artificial; then a deliberate rebuild is more honest.

7. Common mistakes

The recurring patterns on which the rewrite decision fails — almost all of them variations of mistaking frustration for a reason:

• Rebuilding because the old system is unpleasant, without checking whether its core can carry what the future requires.
• Overlooking the old system's embedded knowledge and dismissing hard-won exceptions as messy code.
• Comparing the clean, unburdened new system with the compromise-laden old one — and forgetting that the new one has yet to make the same compromises.
• Succumbing to the second-system effect and building into the rebuild everything that was missing in the old one, until it is weighed down by its ambition.
• Underestimating the moving target and overlooking that the old system keeps running and changing while you build the new one.
• Underestimating how long the rebuild will take and tying up the capacity for two systems over the long interim.
• Overlooking the incremental alternative and narrowing the choice to "carry on" or "rebuild everything."
• Turning the rare right rebuild into a rule — or the common wrong one into a dogma against every rebuild.

8. Decision checklist

Before deciding on a rewrite, clarify the following in order:

• Unpleasant or impossible? Is the old system merely hard to change — or can its core fundamentally not become what it needs to be?
• Technology future-proof? Has the underlying technology reached the end of the road, or does it still hold up?
• Embedded knowledge considered? Is it clear which exceptions, collected over years, a rebuild would have to learn all over again?
• Second-system effect? Does the team have the discipline to rebuild what is needed rather than what is wanted?
• Moving target? Can the old system be frozen — or will it keep running and changing while you build?
• Duration and parallel operation? Have the usually underestimated duration and the burden of running two systems been honestly factored in?
• Incremental option checked? Can the system be replaced piece by piece instead of all at once?
• Frustration or finding? Is the decision based on an objective finding about the core — or on annoyance with the old system?

Anyone who can answer these questions has separated the rare right rebuild decision from the common wrong one — and knows whether to rebuild or, better, to modernize.

FAQ

Why do you advise against something you would earn money from? Because advice is only worth as much as the willingness to give it against your own interest. A rewrite is expensive and lucrative for a software company — and usually the wrong choice. Anyone who only says so when it benefits them is not a reliable advisor. The honest answer to "should we rebuild?" is usually no, and we give that answer even when yes would bring in more revenue.

Isn't messy code a good reason to rebuild? Rarely. What looks like messy code in a grown system is often hard-won correctness — the trace of bugs already fixed and edge cases already learned. A rebuild throws that knowledge away and has to relearn it in production. Messiness is a reason to clean up, rarely a reason to rebuild.

When is a rewrite actually the right call? When the foundation is fundamentally wrong, not just unpleasant: when the core fundamentally cannot meet a requirement that is central today, the technology has reached the end of the road, or the cost of keeping the system exceeds that of a rebuild over its lifetime. The difference is "hard to change" versus "cannot become what it needs to be."

What is the second-system effect? The tendency to make the second system worse than the first — overloaded with every idea that was missing in the old one, every flexibility anyone wished for. Freed from constraints and driven by the wish to get it right, the rebuild often builds not what is needed but what is wanted, and is weighed down by its ambition.

Why do rewrites so often fail midway through? Because the old system keeps running and changing while you build the new one — a moving target the rebuild never quite catches. During the long, usually underestimated interim, you run two systems and paralyze actual product development. That is exactly where most rewrites lose the trust they would need to be completed.

What is the alternative? Replacing the old system incrementally, piece by piece, while it keeps running — modernization without a big bang. You get renewal without the risky interim, without the moving target and without losing all the embedded knowledge, because you only replace what you have understood. Usually that is exactly what you wanted, without the risk you didn't want.

Further reading

• Legacy Modernization Without a Big Bang — the alternative to a rewrite: replace incrementally while the system keeps running.
• Taking Over a Legacy System — the First 90 Days — first understand what you are considering replacing.
• Why Software Projects Really Fail — why the big rebuild is a particularly irreversible bet.
• Real-Time Without a Rebuild — a modern requirement integrated without a rewrite.

The foundation is the Batunet Engineering Method: understand what exists, renew it in small, reversible steps, and choose a rebuild only when the foundation is fundamentally wrong.

Closing engineering principle

The desire to rebuild is almost always the desire to avoid the pain of understanding — and that is exactly why it leads you astray. Understanding an existing system is laborious; throwing it away and starting over feels like liberation. But the liberation is an illusion: the new system inherits the same reality, makes the same compromises and learns the same exceptions — only without the knowledge the old one had acquired at great cost. The most mature decision is therefore usually to improve what is unpleasant instead of replacing it, and to reserve the rebuild for the rare situation in which the core truly cannot carry the load. Rebuilding because the old system is hard trades a known problem for an unknown one — and you pay for the trade with what you already knew.

A rewrite promises to leave the pain of the old behind. All it leaves behind is the knowledge — and it takes the pain along once more, this time without the lessons that had made it bearable.