What would disprove this analysis? (Criterion 1)

A majority of ground-up rewrites are completed on time and within budget

What would disprove this analysis? (Criterion 2)

Rewritten systems show measurably lower technical debt than incrementally improved systems after 3 years

What would disprove this analysis? (Criterion 3)

Feature velocity during a rewrite period remains within 20% of pre-rewrite levels

When should you avoid rewrite fallacy?

The existing system is still generating revenue and serving users. You cannot articulate exactly which business rules the legacy system encodes

What are alternatives?

Strangler fig pattern: Incrementally replace components while keeping the old system running. Modular extraction: Extract the worst modules into services, leave the rest. Invest in tests first: Add comprehensive tests to legacy code, then refactor safely

Catalog

T010

Technology

Rewrite Fallacy

HIGH(85%)

February 2026

4 sources

Context

A codebase has accumulated years of technical debt, inconsistent patterns, and legacy decisions. The team is frustrated. Someone proposes the solution that feels obvious: rewrite it from scratch. Clean slate. Modern stack. Do it right this time. Leadership approves. The rewrite begins with optimism and ends — if it ends at all — years later, over budget, with a new system that has its own set of problems and has lost years of battle-tested edge case handling.

Hypothesis

What people believe

“Rewriting a legacy system from scratch is faster and cheaper than incrementally improving it.”

Actual Chain

→

Team underestimates scope by 3-5x(Estimated 6 months, actual 18-36 months)

└

Legacy system encoded thousands of implicit business rules

└

Edge cases discovered only when users hit them in production

└

Second system effect — team over-engineers the replacement

→

Two systems must be maintained simultaneously(Engineering cost doubles during transition)

└

Bug fixes must be applied to both old and new systems

└

Feature development stalls — all capacity goes to rewrite

└

Competitors ship features while you rewrite plumbing

→

Organizational patience runs out(50-70% of rewrites are abandoned or scaled back)

└

Leadership loses confidence in engineering estimates

└

Team morale collapses when rewrite is cancelled or descoped

→

New system accumulates its own debt within 2 years(Debt cycle restarts)

└

The same organizational pressures that created the original debt still exist

└

Team proposes another rewrite — the cycle repeats

Impact

Metric	Before	After	Delta
Project timeline vs estimate	6-12 months estimated	18-36 months actual	+200-300%
Feature development during rewrite	Normal velocity	Near zero	-80%
Rewrite completion rate	100% planned	30-50% completed as designed	-50-70%
Engineering cost	Baseline	2-3x during transition	+150%

Navigation

Don't If

•The existing system is still generating revenue and serving users
•You cannot articulate exactly which business rules the legacy system encodes

If You Must

1.Use the strangler fig pattern — replace incrementally, not all at once
2.Define a strict feature freeze on the new system — parity first, improvements later
3.Set a hard deadline and scope cut ruthlessly if behind
4.Keep the old system running as fallback for at least 6 months post-migration

Alternatives

Strangler fig pattern — Incrementally replace components while keeping the old system running
Modular extraction — Extract the worst modules into services, leave the rest
Invest in tests first — Add comprehensive tests to legacy code, then refactor safely

Falsifiability

This analysis is wrong if:

A majority of ground-up rewrites are completed on time and within budget
Rewritten systems show measurably lower technical debt than incrementally improved systems after 3 years
Feature velocity during a rewrite period remains within 20% of pre-rewrite levels

Sources

1.
Joel Spolsky: Things You Should Never Do
The canonical essay on why rewrites fail — Netscape's rewrite killed the company
2.
Martin Fowler: Strangler Fig Application
The incremental alternative to big-bang rewrites
3.
Fred Brooks: The Mythical Man-Month (Second System Effect)
Teams over-engineer the second system, making it bloated and late
4.
Herb Caudill: Lessons from 6 Software Rewrite Stories
Analysis of Basecamp, FogBugz, Gmail, Netscape, and others — most rewrites fail or barely succeed

A015 T002 O005