The Art of CTO Rewrite vs Refactor Framework systematically evaluates whether to rewrite, refactor, or leave a system alone using risk modeling, business context analysis, and hybrid migration strategies like the strangler fig pattern.
Should we rewrite this system, or is that a trap?
Rewrite, strangler fig, refactor or leave alone, with a risk-modelled roadmap.
About 10 min · Assessment · Free
About this toolWhy it matters, common mistakes, FAQ
Should You Rewrite This System — or Is That a Trap?
Rewrites routinely take far longer than estimated. Meanwhile, your competitors ship features. But continuing to patch a fundamentally broken system costs more every quarter as debt compounds.
Engineers romanticize rewrites ("we will do it right this time") while underestimating the edge cases embedded in the old system. Managers refuse rewrites until the system is so broken that even refactoring is impossible. Both extremes are costly.
Questions CTOs ask
- When should you rewrite a system instead of refactoring it?
- A full rewrite is justified when: the current architecture fundamentally cannot meet requirements (not just slow — structurally incapable), test coverage is too low to refactor safely, most of the original authors have left and documentation is minimal, the technology stack blocks hiring, and the business can afford a feature freeze during the rewrite. Even then, a strangler fig approach (incremental replacement) is usually safer than a big-bang rewrite. Rewrites most often fail on the edge cases embedded in the old system — the behaviour nobody documented because nobody decided it.
- What is the strangler fig pattern for system migration?
- The strangler fig pattern incrementally replaces a legacy system by building new functionality alongside the old system and gradually redirecting traffic. Four phases: (1) identify seams — find boundaries where you can intercept requests, (2) build an abstraction layer — a facade that routes to old or new code, (3) implement new components behind the facade, (4) redirect traffic and decommission old code. This reduces risk by keeping the old system running throughout migration, allowing rollback at any point, and delivering incremental value instead of a big-bang cutover.
Related Reading
Vendor Lock-in Exit Strategy Framework: How CTOs Assess Risk and Plan a Clean Exit
Vendor lock-in assessment tool guide: a vendor exit strategy framework for CTOs
frameworksThe Fig Tree (Strangler) Pattern: Replace Legacy Systems Without a Big-Bang Rewrite
Key Takeaways: The fig tree or strangler pattern works when you can control traffic at a choke point and measure outcomes per route.
guidesEngineering Experimentation Framework: How CTOs Build A/B Testing Rigor and a Learning Culture
Engineering experimentation framework: Are you shipping features or shipping learnings?