Decision
Rebuild or Refactor? A Test That Takes Ten Minutes
The question every business with ageing software asks. Five questions that answer it honestly — and why the rewrite is usually the more expensive mistake.
Almost everyone asking this has already decided they want the rewrite. It feels clean. It is also the decision that most often costs a year and delivers a system with the same problems and none of the accumulated knowledge.
Five questions
- Does anyone understand what it does? If the answer is “only the code”, a rewrite is a guess. Refactor and document first.
- Is the platform actually dead — no security updates, no hiring pool — or just old? Old is fine. Dead is not.
- Is the pain in the architecture or the interface? Ugly screens over a sound core are the cheapest fix in software.
- How much of it changes each month? Rewriting a stable module is spending money to stand still.
- Can you afford two systems for a year? Because a rewrite means running both, whatever the plan says.
| Symptom | Usually the answer |
|---|---|
| Slow, but correct | Refactor: indexes, queries, caching |
| Unsupported framework, open CVEs | Upgrade |
| One module blocks everything | Strangle that module only |
| Interface hated, logic sound | New front end, keep the core |
| Platform genuinely dead, system small | Rebuild — the rare honest case |
If you do rebuild
Write down what the old system does before deleting anything, keep it running in parallel, and migrate the data early rather than at the end. The data migration is where rewrites die, and it is always underestimated.
Questions
Is a rewrite ever cheaper?
When the system is small, well understood and the platform is genuinely unsupported. That is a much smaller set of cases than the number of rewrites that get started.
How do we decide without a big consulting exercise?
A 30-minute read of the code and one conversation with whoever operates it. We do that free and tell you which of the five cases you are in.
