Why the strangler fig pattern so often stalls — and how to keep it moving

The strangler fig pattern is one of those ideas that sounds finished the moment you hear it. You wrap the old system, route new functionality through a façade, migrate one capability at a time, and let the legacy monolith quietly shrink until there's nothing left to switch off. On a diagram it's elegant. In a real organisation, it stalls more often than it succeeds — and when it does, the cause is rarely the code.

We've inherited enough half-finished migrations to see the same pattern behind the pattern. The technique is sound. What breaks is everything around it.

The first stall is organisational

A strangler migration only progresses if someone keeps deciding which capability moves next, and keeps funding the move. That decision is easy in month one, when leadership is paying attention. By month eight, the new platform handles the visible 30% — the customer-facing flows everyone wanted modernised — and the remaining 70% is unglamorous back-office logic that no executive is asking about. The migration doesn't fail. It just quietly stops, and the company now runs two systems forever, which is the single most expensive outcome available.

The second stall hides in the seams

The façade that routes between old and new is not free. Every capability you move adds a translation point: data that has to stay consistent across two stores, a transaction that now spans a boundary, an identity or permission model that has to mean the same thing on both sides. Teams underestimate this because the façade is invisible on the architecture diagram — it's the line between two boxes. In production it's where the incidents live.

The third stall is measurement

Most stalled migrations we've seen had no honest definition of "done" per increment. "Migrate the orders capability" is not a unit of work; it's a wish. Without a precise contract for each slice — what moves, what stays, how the two reconcile, and how you roll back if the slice misbehaves — every increment becomes a negotiation, and negotiations are slow.

How to keep it moving

Start from the strangler's actual prerequisite, which is observability, not architecture. Before you move a single capability, you need to see exactly what the monolith does — which calls, which data, which dependencies — because you cannot safely wrap what you can't measure. Teams that skip this step spend the migration discovering hidden couplings the hard way, in incidents.

Sequence by risk and reversibility, not by visibility. The instinct is to migrate the exciting customer-facing piece first. The discipline is to migrate the slice that teaches you the most about your seams while being cheap to roll back. Early increments are where you pay down your ignorance; spend them on learning, not on demos.

Make each increment a contract. For every slice: the capability that moves, the data ownership after the move, the consistency guarantee across the boundary, the rollback path, and the metric that says it worked. If you can't write those five things down, the slice isn't ready.

And give someone a standing mandate to keep choosing the next slice. The strangler fig is a biological metaphor for a reason — the fig kills the host slowly, over years, only because it never stops growing. The moment it stops, you don't have a migration. You have two systems and a maintenance bill.

None of this is a reason to avoid the pattern. For large, load-bearing monoliths it's still the safest way we know to modernise without a high-stakes big-bang cutover. It just isn't a free pattern, and treating it as one is the most reliable way to end up stuck halfway.