Engineering Practitioner Brief / 18 May 2026
Big-Bang Rewrite Cost
The big-bang rewrite is the most-attempted, most-warned-against, and most-failed pattern in software engineering. Every team eventually meets a codebase that feels unbearable. Every team eventually considers throwing it out and starting again. The published warnings (Spolsky, Brooks, the long tail of case histories) are clear, and yet the pattern recurs. This page lays out the cost arithmetic so the decision can be made with the numbers in front, not on the strength of the impulse.
Median observed overrun of big-bang rewrites against the original estimate, across published case histories from the past three decades.
Sources: Joel Spolsky, Fred Brooks, Standish CHAOS reports, the academic literature on software project overrun.
The Three Structural Causes of Overrun
Feature-Parity Tax
The original system contains years of accumulated bug fixes, edge-case handlers, and quiet defenses against weird user behaviour. None of this is documented. None of it shows up in the requirements document the rewrite team starts from. All of it has to be rediscovered, often during user acceptance-testing or production cutover, often the hard way.
The cost of replicating a single existing function in a new system is typically 2x to 4x the cost of writing it originally. The rewrite author has to study the original implementation (read time), trace the corner cases (test time), implement the replica (write time), then verify the replica matches (regression-test time). The original author had to do only the third step.
Across a system of any size, the feature-parity tax dominates. The Netscape rewrite that Spolsky documented in Things You Should Never Do, Part I spent multiple years re-implementing features the original Navigator already had. Market share dropped during the rewrite. The cost was not measurable as engineer-hours; it was measurable as a permanent loss of position in the browser market.
Opportunity Cost of Frozen Development
During the rewrite the existing system either continues to develop in parallel (doubling team load and guaranteeing a moving target for the rewrite) or freezes (in which case no new features ship for the duration of the rewrite). Most teams choose the freeze, because parallel development of the same features in two codebases is operationally untenable. The freeze means customers see no improvements for 12 to 36 months while competitors keep shipping.
For growth-stage products this is usually the most expensive single cost of a big-bang rewrite. A product shipping at a 30 percent slower velocity (or zero, during a freeze) compounds against competitors. Customer churn rises during the period when nothing visibly improves. Sales pitches weaken because the roadmap looks unconvincing. The revenue impact across a 2-year rewrite can equal or exceed the direct engineering cost.
Second-System Effect
Fred Brooks identified the second-system effect in The Mythical Man-Month (1975). The pattern: an engineer's first system is constrained by their inexperience and ships lean. Their second system overreaches because they finally know what they wish they had built the first time, and they try to build all of it at once.
In the rewrite context, the second-system effect shows up as scope creep. "Since we're rewriting anyway, let's also fix the architecture, replace the database, modernise the front-end framework, and add the new feature we've been wanting." Each addition is locally reasonable. The cumulative effect is a 6-month rewrite that becomes a 30-month rewrite. Most published rewrite failures include some version of this dynamic.
What the Cost Actually Looks Like
A worked example. The original system is a 50,000-line web application built over four years by a team of six engineers. Original development cost, roughly: 6 engineers x 4 years x $200K fully-loaded = $4.8M. The team estimates the rewrite at 18 months with the same headcount, projecting $1.8M to ship the equivalent system on a modern stack.
The actual outcome of this kind of project, based on case-history medians:
| Component | Original Estimate | Typical Actual |
|---|---|---|
| Duration | 18 months | 36 to 54 months |
| Engineer-hours direct | 9,000 | 22,000 to 35,000 |
| Direct cost at $85 / hr | $765K | $1.9M to $3M |
| Opportunity cost of frozen dev | Not modelled | $1M to $5M+ |
| Production-incident cost during cutover | Not modelled | $100K to $1M |
| Total realised cost | $1.8M planned | $3M to $9M+ |
When Big-Bang Actually Wins
The pattern is not always wrong. Three cases where big-bang is the correct choice:
The problem domain has fundamentally changed. The existing system encodes requirements nobody defends. The business has moved on, customer expectations have shifted, regulatory requirements are different. Incremental refactoring of the existing system would end up with a worse system than starting fresh, because the existing system is a faithful expression of the wrong problem.
The existing system is small enough. Under roughly 5,000 lines and one or two engineers, the cost arithmetic flips. Feature parity is tractable because there are few features. Frozen development is acceptable because the system is not central to revenue. The rewrite is small enough to ship in weeks, not months.
Nobody can maintain the existing system. The original team has dispersed, the language or framework is unmaintainable (Flash, ActionScript), no engineer is willing to work on it. A rewrite is the only way to recover any ability to ship. The opportunity cost of frozen development is high but unavoidable, because incremental work is also impossible.
The Alternatives
For most situations where a big-bang rewrite is being considered, one of these patterns is a better fit:
- Strangler-fig migration. Replace the system one piece at a time, routing traffic incrementally to the new components. Total elapsed time is similar to a big-bang rewrite, but value ships continuously throughout. See strangler-fig migration cost.
- Parallel-run rewrite. Build the new system in parallel, running it in shadow mode against production traffic until it matches the old system's behaviour. Cut over only when correctness is verified. See parallel run refactor cost.
- Aggressive incremental refactoring. Spend the same money the rewrite would have cost, but on cleaning up the existing system. The result is rarely as satisfying as a fresh start but is often closer to the desired end-state than the original instinct suggested. See legacy code refactoring cost.
- Re-platform with automated transpilation. Useful for language-migration cases (COBOL to Java, .NET Framework to .NET) where commercial transpilers exist. Lower risk than a rewrite, lower benefit too. See COBOL mainframe debt cost.
Related Reading
- Strangler-fig migration cost
- Parallel run refactor cost
- Monolith decomposition cost
- COBOL mainframe debt cost
- Legacy code refactoring cost
Frequently Asked Questions
Why does big-bang rewrite cost so much?
Three reasons. First, feature parity is harder than it looks: the original system contains years of accumulated bug fixes and edge-case handlers that have to be rediscovered. Second, no value ships during the rewrite, so competitors keep gaining ground. Third, the rewrite typically encounters second-system effect (Brooks): scope creep driven by 'we should also fix that' impulses.
Why do teams still attempt big-bang rewrites?
Because the existing codebase looks ugly. Engineers see the accumulated debt and underestimate the value of the working features. Management sees the velocity drag and overestimates the upside of starting fresh. Both incentives are reinforcing. Joel Spolsky's 2000 essay on Netscape remains the canonical warning; it has not stopped the pattern from recurring.
When does big-bang actually win?
Three cases. First, when the original problem domain has fundamentally changed and the existing system represents requirements nobody defends anymore. Second, when the existing system is small enough that the rewrite cost is genuinely tractable (under 5,000 lines, single developer). Third, when the existing system is unmaintained and a rewrite is the only way to recover any team's ability to ship against it.
How much does feature parity cost?
More than the original feature development, usually. A function that took 1 engineer-hour to write originally takes 2 to 4 engineer-hours to replicate accurately. The new author has to understand the original intent, study the implementation, write tests against the old behaviour, then implement the new version. The implementation step is the cheapest part.
What is the opportunity cost of a rewrite?
The value of the features that would have shipped in the existing system during the rewrite period. For a growing product, this is the largest single cost of a big-bang rewrite. A 2-year rewrite during which the existing system shipped 30 percent fewer features represents real lost revenue. For mature stable products the opportunity cost is smaller because each marginal feature has lower revenue impact.
Should I do a rewrite if the code is unmaintainable?
Usually no. Try the strangler-fig pattern first: rewrite one piece at a time while the rest continues to ship. Most 'unmaintainable' codebases turn out to be maintainable enough for incremental work, and the strangler-fig approach captures most of the benefit of a rewrite while avoiding most of the cost. See the strangler-fig page.