Strangler Fig in Practice: Migrating a Legacy Monolith Without a Rewrite

Big-bang rewrites fail more often than they ship. The history of enterprise software is littered with multi-year rewrite projects that delivered nothing, or delivered something worse than what they replaced. The strangler fig pattern exists precisely to sidestep that failure mode — and yet most teams still misapply it, treating it as a vague philosophy rather than a concrete engineering plan.

Here is how we actually execute it.

What the Pattern Really Means in Production

The strangler fig is named after a tropical vine that grows around a host tree, eventually replacing it entirely. In software terms: you build new capability alongside the legacy system, route traffic to the new surface incrementally, and decommission the old code only after the new path is proven stable. The legacy system keeps running — and keeps earning revenue — while you replace it piece by piece.

The critical word is incrementally. Not feature-by-feature in a backlog, but slice-by-slice with a routing layer in front of both systems at all times.

Step One: Install the Facade Before You Write a Line of New Code

The first engineering artifact is a routing proxy — an HTTP gateway, a load balancer with routing rules, or a thin application layer — that sits in front of the legacy system and passes 100% of traffic through unchanged. This sounds trivial. It is not optional.

Until that proxy exists, you have no mechanism to shift traffic. Teams that skip this step end up doing a rewrite anyway, because they have no incremental cutover path. Install the facade on day one, validate that latency and error rates are identical to direct access, and only then start carving out the first slice.

Step Two: Define Slices by Bounded Context, Not by UI Screen

The most common mistake is slicing by page or endpoint — migrating /invoices because it seems self-contained. Endpoints are not bounded contexts. If /invoices calls into shared stored procedures that also power /payments and /reports, you have not isolated anything; you have just moved the coupling.

Slice by business capability with a clear data ownership boundary. Good first candidates share these traits:

• They own their own tables, or can be given ownership with a clear extraction plan.
• They have low write-contention with the rest of the monolith during the migration window.
• They have measurable business outcomes — so you can prove the new slice is correct before cutting over.

In a recent engagement migrating a multi-site dental group's practice management integrations, we started with the appointment-status sync module specifically because it had a narrow data footprint and a clear event boundary. The rest of the legacy system continued untouched for months while that slice ran in parallel and accumulated confidence.

Step Three: Build an Anti-Corruption Layer for Shared Data

During migration, both systems will need to read the same data. The legacy system owns the schema; your new service cannot be allowed to depend on that schema directly or you will never be able to decommission the old code.

The anti-corruption layer (ACL) is a translation service — often just a set of read models or a thin API — that exposes legacy data in the new system's domain language. The new service talks only to the ACL. When you eventually migrate the underlying tables, you update the ACL, not every consumer.

Concretely: the ACL might be a small FastAPI service that reads from the legacy PostgreSQL schema and returns typed Pydantic models. It adds a layer, yes. That layer is what makes decommissioning possible later.

Step Four: Run Dark, Then Shadow, Then Cut

Before shifting real user traffic to a new slice, run it in three phases:

• Dark mode: The new service receives a copy of production requests but its responses are discarded. You observe behavior without risk.
• Shadow mode: Both systems respond; the legacy response is served to the user, but you diff the outputs and alert on divergence.
• Cutover: Route a percentage of traffic — 5%, then 25%, then 100% — to the new service with fast rollback in the proxy if error rates spike.

This sequence turns a scary cutover into a boring operational event. Boring is the goal.

Practical Takeaway

Start with the routing facade — not the new service, not the database migration, not the architecture diagrams. The facade is the migration. Everything else is just building behind it. If you cannot route traffic independently of your legacy codebase, you do not have a strangler fig; you have a rewrite with extra steps.