The Strangler Fig in Practice: How We Decompose Monoliths Without the 18-Month Rewrite Risk

“We’ll rebuild it properly this time.” It is the most expensive sentence in enterprise software. It launches the 18-month rewrite — the parallel effort to replace a monolith wholesale, on the promise that the new system will finally be clean, fast, and maintainable. Eighteen months later, the business has shipped no new features, the rewrite is 60% done and 200% over budget, and the original monolith is still in production because nobody dared switch it off.

There is a better way, and it is not new. The strangler fig pattern lets you migrate a monolith to microservices incrementally — delivering value the whole way, spreading risk across dozens of small steps instead of concentrating it on one terrifying go-live. This is a field account of how we actually run a microservices migration with it, where it pays off, and — because the territory is full of bad advice — where it doesn’t.

What the strangler fig pattern actually is

The name comes from the strangler fig, a vine that germinates in the canopy of a host tree, grows its roots down and around the trunk, and gradually envelops the host until the new plant stands on its own and the original is gone. Martin Fowler borrowed the image to describe an approach to legacy modernization: grow the new system around the old one until the old one can be removed.

In practice, that means three things happening together. You place a routing facade in front of the existing monolith. You extract one capability at a time into a new service. And you point the facade at each new service as it goes live, so callers keep working while the implementation moves out from under them. The monolith keeps serving everything you haven’t migrated yet, and shrinks with every extraction.

Strangler fig vs. the big-bang rewrite

The contrast that matters is with the big-bang rewrite. A rewrite builds a complete replacement in parallel and flips a switch at the end. The strangler fig pattern never has that switch — it has a hundred small ones, each of which you can throw and, crucially, throw back. One approach concentrates all risk on a date. The other dissolves it across a sequence of reversible steps. That single difference is why the strangler fig is the default we reach for on a serious monolith-to-microservices migration.

Why the big-bang rewrite keeps failing

It is worth being blunt about why the rewrite is so seductive and so dangerous, because CTOs are pitched it constantly.

• It freezes feature delivery. While the new system is being built, the old one is usually put in maintenance-only mode. The business stops getting new capabilities for the duration — and “the duration” always grows. This is where rewrites lose executive sponsorship: not on a technical failure, but on a year of no visible progress.
• The blast radius is the entire system. With a big-bang cutover, the first time the new system meets real production traffic in full is on go-live day. Everything that was implicit in the monolith — the undocumented edge cases, the data quirks, the integrations nobody remembered — surfaces at once, at the worst possible moment.
• You end up running two systems anyway. Because the cutover is so risky, teams hedge: they keep the monolith running “just in case.” The “just in case” becomes permanent. Now you maintain both, which is the exact opposite of the outcome you were promised.

None of this is an argument against microservices. It is an argument against getting there in one leap.

The strangler fig in practice: how we decompose monoliths

Here is the method, stripped to what actually matters in the field. It is five steps, and the order is not negotiable.

1. Find the seams

You cannot cut a monolith cleanly if you do not know where it is already loosely joined. Before any code moves, we map the system into bounded contexts using domain decomposition — the domain-driven design work of identifying where responsibilities and data naturally separate. The goal is to extract services along the domain’s real seams, not along arbitrary technical lines. Get this wrong and you build a distributed monolith: all the operational cost of microservices with none of the independence.

2. Stand up the routing facade first

Before extracting anything, we put a routing facade — a gateway or reverse proxy — in front of the monolith. Initially it does nothing but pass traffic straight through. That is the point: it is a seam you install while everything still works, so that later you can redirect one route at a time to a new service without callers ever knowing the implementation moved. Installing the facade first is what makes every subsequent step reversible.

3. Extract one service at a time

Now the strangling begins. We take a single bounded capability and move it into a new service, sitting behind an anti-corruption layer — a translation boundary that keeps the legacy model’s assumptions from leaking into the new service’s design. Traffic for that capability is redirected through the facade to the new service; everything else still hits the monolith. One capability, one deployment, one small blast radius. Then the next.

4. Migrate the data deliberately

Data is where migrations get dangerous, because it is the one thing you cannot roll back casually. We handle it deliberately: dual-write to old and new stores where needed, reconcile and verify consistency, and cut a service’s data over only once the new path is proven. No data step is a point of no return until we have evidence it is safe to make it one.

5. Retire the monolith incrementally

As each capability is strangled out, the monolith shrinks. Eventually what remains is small enough — and low-risk enough — to decommission on its own terms. There is no dramatic switch-off, because by the time the monolith goes, almost nothing is still running on it. That anticlimax is the entire goal.

A field example: Wonder Cement’s monolith to microservices

The pattern is not theoretical for us. Wonder Cement, a leading Indian cement manufacturer, ran its in-plant logistics on a rigid, vendor-locked monolithic system — high annual maintenance costs, slow to change, and heavy with manual weighment, loading, and vehicle-sequencing steps.

We re-architected it into a microservices architecture on Azure — built on .NET Core and Angular, with Azure Service Bus for event-driven communication between services, Blob Storage for documents, Azure Cache for low-latency access, and IoT integration across the plant. The decisive part for this discussion: it was delivered in two phases over three months, with zero operational disruption, and it eliminated the legacy system’s annual maintenance costs entirely. The microservices design reduced the blast radius of every change and let each capability scale independently.

That is the thesis in one engagement: a real monolith replaced by microservices, sequenced into independent low-risk phases — not a frozen 18-month rewrite.

Where incremental decomposition pays off across verticals

The strangler fig pattern earns its keep most clearly where the business genuinely cannot afford a big-bang cutover — and that describes more industries than teams admit.

• Manufacturing. Plants run around the clock. A logistics or MES-adjacent system that goes dark for a risky cutover costs real production. Incremental extraction lets the plant keep operating while the software modernizes underneath it — as the Wonder Cement work shows.
• Healthcare. Uptime and compliance make a feature freeze and a high-risk go-live especially hard to justify — clinical and administrative systems are expected to keep running and keep meeting their obligations throughout. Strangling functionality out one bounded context at a time keeps the system continuously available and each change independently verifiable.

The cross-vertical rule is simple: the higher the cost of downtime and the longer the system must keep running during the change, the stronger the case for incremental decomposition over a rewrite.

When not to use the strangler fig pattern

Opinionated advice has to cut both ways, so here is the honest counter-case. The strangler fig pattern is not free. It adds a routing facade, anti-corruption layers, and a stretch of time where you deliberately run two systems in parallel. That overhead is worth it for a large, entangled, business-critical monolith. It is not always worth it:

• Small or simple applications. If the system is modest and well-understood, the facade-and-extract machinery can cost more than a clean rewrite or an off-the-shelf replacement would.
• Systems near end-of-life. If the application is being retired soon anyway, incremental modernization is effort spent on something you are about to switch off.
• Genuinely unknown domains. If you cannot yet identify the bounded contexts, you cannot extract along them. Do the domain decomposition first; attempting to strangle a monolith whose seams you have not found produces a distributed mess.

Knowing when the pattern is the wrong tool is part of using it well.

What this means for CTOs and heads of architecture

If you are staring down a monolith and being sold an 18-month rewrite, the practical read is this:

• Reject the single go-live. Any plan whose value arrives only at the end is a plan that concentrates all its risk at the end. Insist on a sequence that delivers and de-risks continuously.
• Fund the seams work. The domain decomposition up front is not overhead — it is what determines whether you get microservices or a distributed monolith.
• Measure by services shipped, not percent complete. “60% done” on a rewrite tells you nothing. “Four capabilities extracted and live” tells you exactly where you stand.

Done well, monolith to microservices migration stops being a bet-the-quarter project and becomes a steady, low-drama program that keeps delivering the whole way through. That is the promise of the strangler fig pattern — and, unlike the 18-month rewrite, it is one the approach can actually keep.