The choice between refactoring and rewriting is a choice about delivery risk, migration and evidence.
The choice between refactoring and rewriting is a choice about delivery risk, migration and evidence. Refactoring changes structure while preserving useful behaviour. A rewrite creates a replacement that must reproduce or deliberately retire existing behaviour and data. Begin with the constraints that block the product, then compare bounded options rather than arguing about whether the current code feels clean.
Inventory what must survive
List customer journeys, integrations, operational workarounds and data that cannot be lost. Record undocumented behaviour through examples and tests. A supposedly small product may contain years of edge cases around billing or permissions. Decide which behaviours are contractual, which are useful and which can be removed with a migration plan.
Test a bounded refactor
Choose one expensive or unstable area and estimate the smallest change that addresses its cause. Add characterisation checks before changing it, then measure delivery or reliability afterward. This experiment reveals whether the difficulty is local or structural. It also produces evidence for a rewrite decision instead of assuming that all existing modules share the same problems.
Estimate the transition, not only the replacement
A rewrite budget includes data migration, compatibility, parallel operation, customer communication and retirement of the old system. Determine how new product work continues during the transition. Compare total effort and risk over the same horizon. A new framework may reduce one maintenance burden while creating unfamiliar operational responsibilities.
Use explicit decision gates
Prefer incremental replacement when boundaries can be isolated and customer continuity matters. Consider a broader rewrite when critical constraints cannot be repaired economically and the required behaviour is understood. Assign a checkpoint at which the team can stop, narrow or change the approach. The final decision should include migration acceptance criteria and rollback limits, not simply a target launch date.
- Related service
- Taking over a software project from another agency
- Why an MVP is slow: diagnose before optimising
Compare the full cost of two options
Model implementation, migration, recurring operations and exit costs over the same horizon. Enter your own quotes and assumptions for each option.
Enter all costs for both options. Use 0 for costs that do not apply.
Your inputs are planning assumptions, not market prices. Contingency applies to implementation and migration only. Recurring costs increase every 12 months; exit cost occurs at the end. Discounting assumes month-end payments. Taxes, revenue, financing and currency conversion are excluded. Cost crossing is not a return-on-investment forecast.
Frequently asked questions
Is old technology enough reason to rewrite?
No. Assess support, security, delivery and operational constraints rather than age alone.
What is a characterisation test?
A check that records important existing behaviour before structural change, including behaviour not yet documented.
Can we replace one module at a time?
Often, if interfaces and data ownership can be separated. Validate those boundaries first.
Why are rewrite estimates often incomplete?
They may count feature implementation while omitting migration, coexistence and hidden operational behaviour.
Who should make the decision?
Product, engineering and operating owners should agree the evidence, business trade-offs and transition risk.
Bring the scope. We will help make it buildable.
Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.
Further reading
Taking over a software project from another agency
A software takeover succeeds when the new team can build, deploy and operate the product without relying on undocumented access held by the previous supplier.
Why an MVP is slow: diagnose before optimising
A slow MVP needs a measured diagnosis before a new hosting plan or framework.
Recover a failing software project: the first two weeks
The first two weeks of project recovery should produce a credible picture of the product and a workable next decision.