Every ageing system eventually produces the same meeting: the one where someone proposes the rewrite. A clean codebase, a modern stack, freedom from a decade of compromises. The proposal is seductive precisely because its costs are invisible — they arrive later, as a two-year tunnel during which the business gets neither the new system nor improvements to the old one.
Why rewrites stall
A rewrite must reimplement years of accumulated behaviour — including the undocumented quirks your customers depend on — while the old system keeps changing underneath it. The target moves. Scope grows. Meanwhile, the team maintaining the legacy system watches its best people leave for the greenfield project. Most rewrites don't fail dramatically; they fade, absorbed into a hybrid nobody planned.
The strangler alternative
Incremental modernisation takes the opposite bet: replace the system where it hurts most, one seam at a time, inside the running application. Extract the module with the worst performance or the highest change cost, put an interface in front of it, rebuild behind the interface, and cut over when the numbers prove out. Each slice ships value on its own — faster pages, cheaper infrastructure, safer deploys — and each slice de-risks the next.
Fix the platform before the code
The highest-return first slice is usually not code at all. Making deploys boring — pipelines, tests, observability — reduces the cost of every subsequent change, including the modernisation itself. A team that can release safely every week can modernise anything. A team that releases quarterly, with held breath, cannot — no matter how modern the target stack is.
The question is not monolith versus microservices or old stack versus new. It is whether next quarter's roadmap ships while the architecture improves. Slices say yes. Rewrites ask you to wait.
