Every leadership team with an aging system eventually faces the question: refactor or rewrite? It is usually asked at the worst possible moment — after an incident, before a funding round, or when the third consecutive release has gone badly. And it is usually answered with instinct, because the evidence that should drive the decision lives undocumented inside the system itself.
Both wrong answers are expensive. A rewrite that wasn't necessary burns quarters re-implementing behaviour that already worked — and quietly loses the business rules nobody remembered until they were gone. Patching a system that genuinely needed replacement burns the same money in smaller, less visible installments, plus the opportunity cost of everything you couldn't ship.
Why the debate stalls
The refactor-versus-rewrite debate stalls because the two sides argue from different evidence. Engineers closest to the code argue from pain: the tangled modules, the fear of touching billing. Leadership argues from outcomes: slow delivery, rising costs, competitor speed. Both are right, and neither view is sufficient — because the decision depends on facts that usually nobody in the room actually has.
- How much of the system's behaviour is actually still correct and needed
- Which business rules exist only in code, with no other record
- Which dependencies would break, and what they touch downstream
- Whether poor performance comes from code, data, infrastructure or architecture
- How much of the system a rewrite would have to faithfully reproduce — including the undocumented parts
The questions that actually decide it
Strip away the emotion and the decision reduces to a small set of answerable questions. Answering them takes evidence work — but far less than the cost of guessing wrong.
- What must be preserved? Inventory the business rules, workflows and integrations the organization depends on. This is the rewrite's hidden budget: everything on this list must be rediscovered, re-specified and re-tested.
- What is actually creating the pain? Profile it. Slow delivery traced to a missing test suite has a very different remedy than slow delivery traced to architecture. Many 'legacy' problems are delivery-process problems wearing an architecture costume.
- Can boundaries be drawn? If seams can be introduced — an API layer, a module boundary — the system can be modernized incrementally, and the rewrite question dissolves into a sequence of much smaller, safer questions.
- What does each path cost when it goes wrong? Not the plan cost — the failure cost. A failed refactoring wastes weeks. A failed rewrite can take the roadmap hostage for years.
- Can the business tolerate the transition? Parallel running, data migration, retraining, frozen features. The transition, not the destination, is where modernizations die.
The options are not binary
Refactor-versus-rewrite is a false binary. In practice there is a spectrum, and the right answer is usually a combination staged over time:
- Stabilize: tests, observability and deployment safety around what exists — the prerequisite for every other option
- Refactor: improve internals incrementally behind stable interfaces
- Modularize: introduce boundaries so parts can evolve independently
- Re-platform: move where it runs without changing what it does
- Replace selectively: rebuild the components where evidence shows rebuilding pays
- Postpone: a legitimate choice when the risk is tolerable and attention is better spent elsewhere
The strangler-fig pattern — wrap the legacy system in a boundary, grow replacements alongside it, retire old components only when the replacement has proven itself in parallel operation — turns the biggest, riskiest decision in engineering into a series of small, reversible ones. For live business-critical systems, it is almost always the risk-dominant strategy.
Deciding on evidence
Our rule is simple: no rewrite recommendation without an evidence base that would survive hostile review. That means a documented current-state map, a business-rule inventory, a ranked risk register, and options costed against business continuity — the material a CTO can defend to a board, and an engineering team can execute against. If the evidence says a smaller intervention protects the business, that is the recommendation, every time.
This framework is the backbone of our Modernization Evidence Pack — a two-to-three-week assessment that turns an undocumented system into a defensible modernization decision.
Not sure the question warrants a full assessment yet? Start with a five-day Architecture Risk Triage. Learn about the Triage