Strategy · 7 min
When not to rewrite
The rewrite is the most expensive and most seductive decision in engineering. A framework for deciding when it is right — and when it is the wrong call dressed up as progress.
Rewrites are the most expensive decision a technology organization can make. They are also the most seductive, because the code in front of you always looks worse than the code you imagine writing next.
The honest test is not whether the current system is imperfect. Every system is imperfect. The test is whether the cost and risk of rebuilding, including the opportunity cost of what your team will not build while rebuilding, is lower than the cost of continuing to extend what exists.
A useful framework: rewrite when the cost of a unit of change in the current system exceeds the cost of a unit of change in a new one, and when the migration can be sequenced without halting the business. Otherwise, refactor. The refactor is almost always the right answer for longer than it feels.
When a rewrite is right, sequence it. Use a strangler pattern, validate in parallel, and never make it a big-bang. The organizations that survive rewrites are the ones that never stopped shipping while doing them.