The Strangler Fig Pattern: Migrating Legacy Systems Without the Big Bang

The big bang migration is how organisations end up with two years of parallel development, a cutover weekend that goes wrong, and a new system that goes live already damaged — with the people responsible for running it no longer trusting it.

The script is familiar. The legacy system is expensive, brittle, and impossible to change. A decision is made to replace it. A new system is built in parallel. A cutover date is set. As the date approaches, the gap between what the new system handles and what the legacy system handles doesn't close as fast as planned. The cutover gets pushed. It gets pushed again. Eventually it happens, because the business can't maintain two systems forever. Something breaks that wasn't caught in testing — often something nobody knew to look for because the legacy system had undocumented behaviour that only manifested in production with real data. You're either rolling back or you're scrambling. Either way, trust in the new system is damaged before it's had a chance to establish itself.

The big bang migration is not a failure of execution. It's a failure of strategy. Concentrating all the risk into a single cutover event is the wrong shape for this problem.

How the Strangler Fig Works

Martin Fowler named the pattern after the strangler fig tree, which germinates in the canopy of a host tree, drops roots to the ground, and gradually envelops the host — drawing more and more of the structural load — until the host tree dies and the fig stands on its own. The host tree doesn't know it's being replaced. It just keeps functioning until it isn't needed anymore.

The technical implementation follows the same logic. A facade layer — a proxy, a gateway, an API — sits in front of both the old system and the new one. All traffic enters through the facade. The facade routes requests: new functionality goes to the new system, everything else goes to the legacy system. As more functionality migrates, the routing rules change. The legacy system handles fewer and fewer requests. Eventually, nothing routes to it. It can be decommissioned quietly.

The migration is a continuous process rather than an event. Each piece of functionality that migrates is a discrete, bounded change. If it breaks, the facade routes that piece back to the legacy system while the fix is made. The rest of the migration continues. Risk is isolated to whatever was just migrated, not to the entire system.

Why Incremental Migration Succeeds Where Big Bang Fails

The fundamental advantage is that risk stays proportional to scope. Migrating one module and having it fail in production is a contained problem. Rolling back one module is straightforward. Understanding what went wrong is tractable because the change surface is small. On a big bang, a failure in production means the entire migration is suspect, the rollback affects everything, and debugging is a forensic exercise across a system that's been entirely replaced.

Production testing is also genuinely possible with the strangler fig. You can route a small percentage of real traffic to the new system for a migrated component before routing all of it. Canary deployments, blue-green switching, gradual rollouts — all of these become available when you have a facade layer. You find issues with real data under real load before those issues affect all users. On a big bang, the first time you test with real production traffic is the cutover.

The business keeps running throughout. The legacy system continues handling everything it always handled. Users don't experience a flag day where everything is different. Teams don't spend two years in a code freeze waiting for a cutover that keeps slipping.

The Parts That Are Still Hard

The facade layer adds operational overhead. It's another component to build, maintain, monitor, and eventually decommission. On a long migration, the facade itself can accumulate complexity as routing logic grows. It needs to be treated as a first-class production system, not a throwaway shim.

Some legacy systems are too tightly coupled to route around cleanly. If the system you're replacing is a monolith with deeply shared state — where every module reads and writes the same tables, where there's no clear seam between different areas of functionality — finding a clean boundary to route at is genuinely difficult. The strangler fig requires the ability to say "this request goes here, that request goes there." Systems that resist that partitioning resist the pattern.

Data migration is often harder than code migration, and the strangler fig doesn't make it easy. When the old system and the new system run in parallel, they frequently need to stay in sync — writes that happen in the legacy system need to be reflected in the new system, and vice versa for migrated functionality. If the schemas are different, which they usually are, that synchronisation requires transformation logic running in both directions simultaneously. Getting that logic right, and keeping it right as the migration progresses, is often the hardest part of the whole programme.

When the Pattern Doesn't Fit

Highly coupled monoliths with truly indivisible shared state are the main case where the strangler fig breaks down. If you can't partition the system into pieces that can migrate independently, you can't build the facade routing that makes the pattern work. You may need to do significant refactoring of the legacy system before migration becomes tractable — which is its own project with its own risk.

There are also cases where the integration cost of a facade layer genuinely exceeds the migration cost — typically very small systems where the legacy codebase is simple, well-understood, and the new system is nearly identical in structure. A careful big bang migration of a small, well-scoped system can be safer than introducing the operational complexity of a facade that will outlive its usefulness.

These exceptions are real but narrower than most organisations think when they default to big bang planning. The strangler fig isn't always the right answer, but it should always be the first option considered for any migration of meaningful size. The alternative — betting the entire programme on a single weekend — has a track record that should make anyone nervous before they commit to it.