Should we rewrite our software or improve what we have?
Short answer
Rewrite only when you can explain which business constraint the existing system cannot reasonably overcome and how you will manage the transition. Compare a replacement with targeted improvements and gradual migration. Include the cost of maintaining both systems, rediscovering existing behaviour and delaying other work, not just the appeal of a newer stack.
Name the constraint before choosing the solution
Is the problem slow delivery, unacceptable operating cost, unreliable behaviour or an inability to support a required product change? Establish the evidence. An unfamiliar codebase or an unfashionable framework is not enough to justify replacement.
Ask what happens if you do nothing for now, and whether the constraint is genuinely architectural. A rewrite will not resolve unclear ownership or continually changing priorities.
Compare credible options
- Targeted improvement: repair the bottleneck while retaining the rest.
- Gradual migration: replace a bounded capability and move traffic or users in stages.
- Full replacement: rebuild with an explicit transition, validation and retirement plan.
For each option, consider customer disruption, operational risk, team capability, data migration and how long the business must fund parallel work. Test the most uncertain assumption before committing to the whole programme.
Make progress independently valuable
A useful migration milestone should improve something the business can observe, not just report that another percentage of code has been rewritten. Establish how you will compare behaviour and when it is safe to retire the old path.
I led the BBC move from a legacy PHP monolith and on-premises infrastructure to AWS, and reengineered Festicket’s platform during rapid growth. The relevant lesson is to connect architecture work with the business it must support.
Related questions
Is a rewrite ever the right answer?
Yes. It can be justified when the existing approach cannot meet an important requirement at a reasonable cost or risk. Make that case explicitly and test the migration assumptions.
How can a nontechnical CEO assess the proposal?
Ask for the business constraint, alternatives, evidence, transition risks and measurable milestones. An independent perspective can help clarify the decision without taking ownership away from your CTO.