Retire a legacy monolith step by step: route traffic through a facade, move features to decoupled Go and Python microservices, and delete legacy code only when it is safe.
Design targets · not measured results from past client work
Designed so traffic moves by routing changes, not maintenance windows.
Shadow traffic mirrors live requests so behavior can be compared before users are affected.
Legacy infrastructure overhead falls as microservices progressively take over load.
Edge routing gateways proxy traffic at the perimeter with minimal overhead.
The strangler fig pattern is a way to modernize a legacy system gradually instead of rewriting it all at once. A routing layer, usually called a facade or proxy, sits in front of the old system. New services are built behind it, requests are moved to them one feature at a time, and the old code is retired once nothing depends on it. The name comes from strangler figs, which grow around a host tree and eventually replace it. Martin Fowler popularised the pattern for software.
Put a proxy in front of the legacy system. At first it sends every request to the old code, so nothing changes for users.
Build one slice of functionality as a new service, test it against live traffic, then move traffic to it in steps while the legacy path stays available.
When a slice has no traffic and no dependants, remove its legacy code. When everything is moved, decommission the legacy system and decide whether to keep or remove the facade.
Each phase is gated by success criteria before the next one starts, with rollback triggers armed throughout.
Deploy an edge gateway layer in front of the existing monolith. Dynamic proxy rules allow selective traffic interception without changing legacy application code. All requests keep reaching the monolith while the new routing layer is validated in parallel.
Mirror live production requests to the new microservice layer. Automated parity harnesses compare response payloads, status codes, latency distributions and side-effect patterns between legacy and new systems. Users see no change at this stage.
Begin canary shifting real user traffic to validated microservices: for example 1% to 5% to 10% to 50% to 100%. Each increment is gated by automated rollback triggers. If error rates or latency breach thresholds set in advance, traffic reverts to the legacy path.
The strangler fig pattern suits large systems that must keep running during the change. It is not the right answer for every system.
| Approach | Delivery risk | First value | Rollback | Best for | Main risk |
|---|---|---|---|---|---|
| Strangler fig | Spread across many small steps, each with a rollback route. | Early. The first migrated slice can go live in production. | Simple while the legacy path still exists. Costly once legacy data and objects are removed. | Large or critical systems that must keep running; teams that can intercept traffic and modify the legacy system. | A long migration, a facade that becomes a bottleneck, or slices that stay tightly coupled. |
| Big-bang rewrite | Concentrated in one cutover date. | Late. Nothing is live until the rewrite is complete. | Hard. The old system may be unmaintained by the time problems appear. | Small, well-understood systems that are simple to replace. | Scope growth, lost behavior nobody documented, and a single high-stakes cutover. |
| Rehost (lift and shift) | Low. Code and architecture stay the same. | Quick infrastructure change, but no architecture change. | Simple. Move back to the old hosting. | Exiting a data centre or contract quickly. | The monolith remains, so the original delivery and scaling problems remain too. |
Microsoft lists cases where the pattern does not fit: requests that cannot be intercepted, a legacy system that cannot be modified, a small system that is simple to replace, and a need to decommission quickly. See the references below.
Core engineering building blocks included in every strangler fig engagement.
Edge gateway configuration intercepting API calls at the network perimeter. Rules are hot-reloaded without service restarts, enabling safe routing experiments.
During overlap, data moves between legacy and new stores through change data capture and an event stream, with one system of record per data set at any time, instead of ad-hoc dual writes that can drift apart.
Custom test harnesses continuously compare response payloads, latency and side effects between legacy and new services. Differences surface in real-time dashboards.
SLO-gated circuit breakers monitor error rates and p99 latency per endpoint. A breach of thresholds agreed before cutover sends traffic back to the legacy path without waiting for a person.
Routing is the easy part. The discipline is in rollback thresholds, data ownership and exit criteria.
upstream legacy_monolith { server legacy.internal:8080; }
upstream orders_service { server orders.internal:8080; }
# Same account always lands on the same side
split_clients "${http_x_account_id}" $orders_backend {
5% orders_service; # canary step, raised as gates pass
* legacy_monolith;
}
server {
location /orders/ { proxy_pass http://$orders_backend; }
location / { proxy_pass http://legacy_monolith; }
}Raise the percentage only while error rate and p99 latency stay inside the thresholds you set before the first canary. Hashing on a stable key keeps each customer on one path. Rollback is a one-line change while the legacy path and its data are intact.
Six failure patterns we design against from the first week.
New services that share the legacy database or call each other in long synchronous chains carry the old coupling into a more complex system. Give each service ownership of its data and keep boundaries clear.
Writing to two stores from application code can leave them out of step when one write fails. Pick one system of record, sync with change data capture, and reconcile on a schedule.
A slice that takes months to ship brings back big-bang risk. Choose slices that can go live, be measured and be rolled back in weeks.
The routing layer sees every request, so it needs redundancy, monitoring and capacity. Microsoft warns it can become a single point of failure or a performance bottleneck.
Rolling back is simple for read-only features. Once a slice writes data, it needs reverse synchronization and a tested plan. Rehearse it before the first real canary.
Without exit criteria, the legacy system lingers and costs double. Keep the facade only if you choose to, and delete legacy code when each slice exits.
Deployed edge gateway with real traffic interception wired to a shadow microservice running in isolation on AWS or GCP.
Behavioral comparison report: response diffs, latency heatmaps and side-effect parity across shadow traffic.
Phase-by-phase migration blueprint with Terraform infrastructure, rollback runbooks and go/no-go criteria per phase.
Six questions to ask any firm, including us, before you commit.
Ask how they choose the first slice and the order after it. Look for reasoning based on business value, risk and coupling, with slices small enough to ship in weeks.
Ask how data stays consistent while both systems run. Look for one system of record per data set, change data capture and reconciliation.
Ask what triggers a rollback and who decides. Look for thresholds agreed in advance, automated triggers and rehearsed runbooks, plus honesty about writes.
Ask how they prove the new service behaves like the old one. Look for shadow traffic, response diffing and side-effect checks with stubs.
Ask how you will know a slice is finished. Look for named criteria: zero legacy traffic, no dependants, validated data, closed rollback window.
Ask what you own at the end. Look for code, infrastructure as code, runbooks and training handed over, with acceptance criteria agreed up front.
It is an incremental way to replace a legacy system. A facade or proxy sits in front of the old system and routes requests either to it or to new services. Functionality is moved one piece at a time, and the legacy system is decommissioned once nothing depends on it. The name comes from strangler figs, plants that grow around a tree and eventually replace it.
Place a proxy in front of the monolith, then build new functionality as services behind it. Shadow traffic against the new service to compare behavior, then move real traffic in canary steps with rollback thresholds set in advance. Keep data consistent with change data capture, and remove each legacy slice only after its exit criteria are met.
Yes, but how easy it is depends on the slice. Rollback is simple while the legacy path and its data still exist, and especially simple for read-only features. Once a slice writes data to the new store, you need reverse synchronization and a rehearsed plan. Microsoft notes that rollback becomes costly after legacy objects are removed, so treat removal as a deliberate final step.
Give each data set one system of record at any time. Use change data capture and an event stream to replicate changes, validate consistency before cutover, then switch ownership. Avoid ad-hoc dual writes from application code, because a failed second write leaves the two stores out of step. AWS describes synchronization between old and new stores as a tactical solution, to be replaced by a longer-term data design.
Microsoft lists four cases: when requests to the back end cannot be intercepted, when the legacy system cannot be modified, when the system is small enough to replace outright, and when the original solution must be decommissioned quickly. In those cases a rewrite, rehost or another approach may fit better.
You choose. Often the facade is removed and clients call the new system directly. Alternatively it stays as an adapter for legacy clients while the core moves on. The risk is keeping it by accident, so decide explicitly and make sure it never becomes a single point of failure.
It depends on the size of the system, how tightly it is coupled and how many slices you choose. The pattern is designed to deliver value early: the first slice can reach production while the rest of the migration continues. A proof of concept on one slice is the quickest way to get a realistic estimate.
Last reviewed: October 2026
Book a technical audit with our principal architects to blueprint your incremental migration roadmap.