When a rebuild is genuinely cheaper than fixing it

Any developer looking at code they did not write wants to rewrite it. That instinct is wrong most of the time, because the existing system encodes years of fixes for problems nobody remembers, and a rewrite rediscovers them one production incident at a time.

Sometimes it is right. Here is how to tell.

Signals that favour rebuilding

1. 01Every change takes longer than the last, and the reason is structural rather than lack of knowledge.
2. 02The platform or framework is unsupported and receiving no security updates. This is a deadline, not a preference.
3. 03Nobody can safely change it. Not "it is unfamiliar" but genuinely nobody, including the original author.
4. 04A required capability is architecturally impossible, not merely awkward.
5. 05The running cost exceeds a rebuild within a sensible payback period.

Signals that do not justify it

• It uses a framework the current team dislikes.
• The code is untidy. Untidy and working beats elegant and unfinished.
• It is slow, without anyone having measured why. Most slowness is a handful of specific causes.
• Someone new wants to work with something more current.

The option people forget

Rebuild incrementally. New functionality goes into a new system, the old one keeps serving what it already does, and routing decides which handles a request. Sections migrate one at a time.

This is slower in total than a clean rewrite and dramatically less risky, because at no point is there a single launch day where everything must work. It also means you can stop halfway if priorities change and still have something coherent.

If you do rebuild

1. 01Write down what the current system does, including the odd behaviours. Those are usually requirements someone forgot to document.
2. 02Keep the URLs. A rebuild that changes every address is also a migration, and the search cost is real.
3. 03Ship in slices, each one live. A rebuild that only exists in staging for six months is where projects die.
4. 04Agree what will not be in version one, in writing. Rewrites overrun because scope grows by default.

The honest test

If you cannot articulate what the new system will do that the current one cannot, it is a preference rather than a business case. That does not make it wrong, but it should be paid for from a different budget and scheduled accordingly.