The rewrite trap, and how to tell if you are in one

A proposal to rewrite a core system arrives roughly once every two years in most organisations. Sometimes it is correct. More often it is an attempt to solve a process problem with a technical decision.

The difference matters, because a rewrite is one of the few engineering decisions that can consume a year and deliver nothing.

Four signals

1. The complaint is about velocity, not capability

“We cannot ship changes” is usually a release process problem. If the current system deploys in twenty minutes but requires four approvals and a change board, a rewrite will not help. The new system will inherit the same approvals.

Test: how long does a one-line change take to reach production today? If the answer is measured in days, the constraint is not the code.

2. The defect rate is blamed on the architecture

Long-lived systems accumulate defects in proportion to the number of people who have edited them without understanding them. That is a documentation and review problem, and it will reproduce itself in the new system within eighteen months.

Test: are the defects concentrated in modules with a single long-term owner, or spread evenly? Concentration suggests a knowledge problem, not an architectural one.

3. Nobody can state the scaling limit

If the justification is performance, there should be a number. “It cannot handle our growth” is not a measurement.

Test: what is the current peak load, and what is the measured ceiling? We have cancelled more rebuilds than we have recommended, almost entirely on the basis of this question. In one case the system handled four times the load the team believed it could.

4. The scope has no end date

A rewrite with an open scope is a programme, not a project. Programmes continue until someone senior stops them.

Test: what is explicitly not being rewritten? If the answer is nothing, the scope is unbounded.

What to do instead

When two or more signals are present, an incremental path is usually available:

Strangle the edges first. Route one low-risk capability through a new service while the old system keeps running.
Measure the constraint. Spend two weeks producing a real number for the limit. It is cheap and it frequently ends the debate.
Fix the process before the code. If deploys are slow, shorten them first. This is independently valuable and tells you whether the architecture was ever the problem.
Set a reversal point. Define in advance what evidence would justify abandoning the rewrite. Without it, sunk cost will carry it forward.

When to actually rewrite

Rewrite when the constraint is structural and measured: the data model cannot represent something the business now requires, the runtime cannot meet a demonstrated load, or the dependency is unsupported and unpatchable.

Those are all statements about capability with numbers attached. Everything else is a process improvement wearing an architecture costume.