Software Modernisation
Modernizing a legacy system while it keeps running the business
Rewrites fail predictably; incremental replacement succeeds boringly. The practical mechanics of the strangler approach: seams, routing, parallel runs, and knowing when to stop.
Modsurf Engineering · April 18, 2026 · 9 min read
Why the rewrite keeps getting proposed
The full rewrite is emotionally attractive: a clean start, modern tools, none of the old code's compromises. It fails for a structural reason — for months or years, the organization funds two systems while only one delivers value, and the old system keeps changing underneath the rewrite. The finish line moves faster than the project.
Incremental replacement inverts the risk. The legacy system remains the system of record while functionality is routed out of it one seam at a time. Every phase ends with a working production system, which means the program can pause, re-prioritize, or stop without stranding the business.
The mechanics that make it work
The first engineering task is finding seams: boundaries where a coherent capability can be extracted — often where the legacy system already integrates with something else, or where a distinct user group touches a distinct workflow. The second is building the routing layer that decides, per request or per record, whether the old or new path handles the work. That layer is the safety mechanism for the whole program.
Parallel running settles the arguments data cannot. For a period, both systems process the same inputs and their outputs are compared automatically. Discrepancies are triaged: some are new-system bugs, and some are legacy behaviors nobody knew about — which is exactly the knowledge a rewrite would have discovered in production.
- Extract along existing seams, not org-chart lines
- Route traffic through a layer you control and can flip back
- Run old and new in parallel and reconcile outputs automatically
- Retire legacy components explicitly — decommissioning is a deliverable
Knowing when to stop
Not everything needs replacing. A stable component with no change pressure and manageable risk can stay, wrapped behind the same routing layer, for years. The goal of modernization is removing constraint and risk from the business — not achieving stack purity. Programs that internalize this finish; programs that chase purity become the next legacy problem.