Skip to content

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

SOFTWARE MODERNISATIONLegacy systemmonolith · shrinkingRouting facadegradual cutoverBilling servicemigratedAuth servicemigratedReporting servicequeuedCatalog servicequeuedstrangler migration · the system keeps running throughout

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.

Related insights

All insights

Working through a similar problem?

Tell us where you are — we will suggest the shortest credible path to a working system.