Every legacy system reaches the moment someone says "we should just rewrite it." That instinct feels responsible and it's usually the most expensive mistake an engineering org can make. This guide lays out the real economics of the three modernization paths, and how to choose on numbers instead of frustration.
The default nobody prices honestly: rewrite from scratch, pay to run the old system and build the new one for the entire (over-running) timeline, get zero new value until cutover, and quietly re-incur every bug the old code already fixed.
The path the economics support: strangle incrementally build the new system around the old one and migrate piece by piece turning one enormous all-or-nothing bet into a series of small, reversible steps that each deliver value along the way.
Build new from scratch, then cut over. Highest upfront cost, longest time-to-value, highest risk you rebuild everything at once and get nothing new until the switch. Right only for small or truly dead systems.
Keep it running and improve incrementally. Low risk, continuous value but bounded: it can't escape a fundamentally wrong architecture. Right when the bones are sound and the problem is accumulated mess.
Stand up new components alongside the old system and migrate one piece at a time until legacy can be switched off. The endgame of a rewrite with the risk profile of refactoring - usually the path that actually finishes.
Sound bones with accumulated debt → refactor. Genuinely wrong platform or architecture → you need new components: strangle (or, rarely, rewrite).
If the system can be carved into independently replaceable pieces, strangle. If it's a true monolith, creating those seams is the first (still cheaper) step.
Need value along the way? Rule out the rewrite, which pays only at the end. Strangle and refactor both deliver continuously.
If a failed cutover would threaten the business, the all-or-nothing rewrite is the wrong risk profile that's the 17% "black swan" territory. Incremental paths keep failure survivable.
Modernization fails when it's driven by frustration instead of economics. Treat it as a portfolio of small, value-delivering steps refactor where the bones are good, strangle where you need something genuinely new, and reserve the rewrite for the rare cases where its math actually works.
Sometimes - for small systems you can rebuild fast, dead platforms, or systems being retired anyway. But the larger the system and the more the business depends on it, the worse the rewrite's economics get, which is why it fails so often on big programs.
Doing nothing has a cost: enterprises commonly spend the majority of their IT budget just keeping existing systems running. Legacy is a standing tax on your ability to build, so "wait" is a priced decision, not a free option.
CTOs, CFOs, and Heads of Engineering weighing how to modernize a system the business still depends on.
Martin Fowler's approach of building the new system around the old one and migrating functionality piece by piece until the legacy system can be switched off turning one giant risky bet into many small, reversible ones.
That's the advantage of strangling each step is small, delivers value on completion, and justifies itself, so you're not asking the board for one enormous multi-year bet.
