Rebuild or Refactor? How to Decide What to Do With an Ageing System

Why the question comes up

It usually starts with a slow team, a system that breaks in surprising places, or a new technical lead who doesn't trust the code. Each of these tends to end with a proposal to start again. Sometimes that is right. More often the cost and risk of a rewrite are underestimated, and the business pays twice: once for the new system, and again for keeping the old one alive while it is built.

Signs refactoring is the better path

In these cases, improving the worst areas incrementally, with tests around them first, usually delivers value sooner and with far less risk.

• The system works for customers; the pain is mostly in changing it
• Problems are concentrated in a few modules rather than everywhere
• The data model is broadly sound
• The stack is still supported and you can hire for it
• The business cannot afford months without new features

Signs a rebuild may be justified

Even then, a gradual replacement is usually safer than a single big-bang switch. Move one capability at a time behind a stable interface.

• The platform or framework is end-of-life and security updates have stopped
• The core data model no longer fits the business
• The product itself is changing so much that little of the old behaviour is needed
• Nobody can safely change the system, and the knowledge cannot be recovered

Questions to ask before approving a rewrite

If the answers are vague, the plan is not ready.

• What exactly will be better, and how will we measure it?
• What does the old system do that nobody has written down?
• How will data be migrated, and how will we roll back?
• Who maintains the old system until the switch?
• What happens to the roadmap during the rebuild?

Get an independent view

Rewrite proposals often come from the people who will do the work, which is a natural conflict of interest. A short, independent technology audit covering architecture, code, delivery, and risk gives leadership an evidence-based recommendation before committing the budget.