Every enterprise software development team that inherits a fifteen-year-old system eventually proposes the same plan: freeze features, rebuild in parallel, cut over on a long weekend. We have never seen that plan survive contact with a real business. Feature freezes leak, the parallel build drifts from the production behaviour it is meant to replace, and the cutover weekend becomes a cutover quarter.
The strangler fig pattern is the alternative, and it is well documented. What is less documented is the operational detail: where the routing seam actually lives, how you move data while both systems write to it, and how you keep an organisation patient for eighteen months. This is how we run it.
Start with a seam, not a service
The first artefact is not a microservice. It is a routing layer that sits in front of the monolith and can send any request to either the old system or a new one, per route, per tenant, per percentage of traffic. Until that seam exists and is carrying one hundred percent of production traffic to the unchanged monolith, no migration work should begin.
We usually implement it as an edge proxy with a rules table rather than code, because the people who need to flip a route at 2am are not always the people who can ship a deploy.
route: /api/billing/invoices -> target: legacy canary: 0% owner: payments-teamWhat makes a good first slice
Pick the slice that is simultaneously low-risk and high-signal. Reporting endpoints are the classic choice: read-only, tolerant of a few hundred milliseconds of extra latency, and they exercise the full stack including auth, observability and deployment.
Read-heavy and idempotent, so a bad canary is recoverable by flipping one row.
Owned by a single team that can absorb a month of migration work.
Backed by tables the new service can eventually own outright.
Instrumented well enough that you can compare old and new responses in production.
The data problem is the whole problem
Routing is a weekend of work. Data ownership is the eighteen months. In a 400-table schema, the tables that matter are the ones with foreign keys pointing at them from everywhere - customers, accounts, orders. Those are the last things you move, not the first.
Dual-write, then read-shift, then own
For each table the new service will own, we run a three-phase sequence. Phase one: the new service writes alongside the monolith and a reconciliation job compares both copies hourly and alerts on drift. Phase two: reads shift to the new store while writes continue to both. Phase three: the monolith stops writing and the legacy columns are renamed with a deprecation prefix so any forgotten query fails loudly instead of returning stale data.
The renaming step is non-negotiable. A column you merely stopped writing to is a column some batch job is still reading a year later.
Change data capture beats scheduled sync
Logical replication out of Postgres into the new service gives you a replay log, a measurable lag number, and a way to backfill without a maintenance window. Scheduled ETL gives you a nightly moment of inconsistency that nobody can reason about during an incident.
Keeping the organisation patient
A migration that delivers nothing for a year gets cancelled in month nine. We tie each slice to something the business can feel: a page that got faster, a report that now runs in seconds, a compliance control that is finally automated. The architecture work is the vehicle, not the pitch.
We also publish a single number - percentage of production traffic served by new services - on a dashboard that executives see. It goes up slowly and monotonically, and it ends arguments about whether the programme is moving.
When not to strangle
If the legacy system is small enough that a full rewrite is under four months of work for the team you actually have, rewrite it. The strangler pattern carries real overhead: dual-running costs, reconciliation code, two mental models in every engineer’s head. That overhead is worth paying when the alternative is a cutover you cannot roll back. It is not worth paying to avoid a two-month rewrite.
