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.
Frequently Asked Questions
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, less than 20% of the original authors remain 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. The #1 reason rewrites fail is underestimating the edge cases embedded in the old system.
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.