The Strangler Fig pattern is a modernization strategy in which a new system grows around the old one and takes over its functions module by module — until the old one can be safely switched off. The name comes from the strangler fig, a plant that germinates on a host tree, wraps it in roots and gradually takes its place. In practice it is the safest known way to replace a system running in production, without a big-bang switch and without downtime.
Key takeaway: Strangler Fig inverts the risk of a rewrite — instead of building a new system "beside" the old one and switching over in a single moment, you take over functions one at a time. Every taken-over module runs on new code, every remaining one on old code, and any step can be rolled back. The pattern was described by Martin Fowler; the practice comes from systems that cannot afford downtime.
The problem this pattern solves
A classic rewrite-from-scratch has two nightmarish moments: building the new version "blind" for months, and switching production over, when every untested edge case surfaces at once. On top of that comes decision paralysis — until the new system is ready, the old one must live and be developed, so work happens twice.
Strangler Fig removes both problems. New code reaches production from day one — handling one feature, next to the old one. Every takeover is small, verifiable and reversible. The old system keeps running the whole time and can be switched off feature by feature until it is empty. This pattern turns a "big bang" into a series of controlled steps.
The wider context — where this strategy sits in the modernization plan, safety tests, CI/CD — is described in Legacy Code Modernization — Step by Step.
How Strangler Fig works — the interception layer
The mechanics rely on an intermediate layer standing between the user and both systems — old and new. That layer decides where each request goes:
- features not yet migrated — traffic goes to the old system, unchanged,
- taken-over features — traffic goes to the new implementation,
- features mid-switch — traffic can be split (e.g. a percentage of users to the new system) and both implementations compared.
The interception layer can be a reverse proxy (nginx), an application router, an API gateway, or — most commonly in PHP projects — the new framework itself, delegating requests for unmigrated paths to the old application. One property is essential: switching a feature is a configuration change, not a big deployment.
The monolith variant — Branch by Abstraction
Traffic cannot always be intercepted at the HTTP level. In monoliths, where functions call each other inside one process, the sibling pattern applies: Branch by Abstraction, also described by Fowler.
- The idea: between the call sites of the old implementation and the code that uses them, you insert an abstraction (an interface). Initially the old implementation sits behind the interface. You build the new implementation beside it, and the switch is a configuration or feature-flag change — without touching call sites. This allows replacing individual components inside an application without splitting it into services.
In practice projects mix both approaches: modules with their own HTTP entry point are taken over by the routing layer (Strangler Fig), while internal components are swapped through abstractions (Branch by Abstraction). The code-restructuring techniques themselves are covered in the legacy code refactoring guide.
Takeover order — what to migrate first
Order matters more than pace. A proven heuristic
- start with a module that has clear boundaries and real value — e.g. login, a client portal, one business process. The first module is meant to prove the process works, not to solve the system's hardest problem,
- leave the most entangled modules for later — they need their dependencies untangled first,
- never migrate two modules that share transactions in parallel — separate their boundaries first,
- migrate the system core last — by then the new system handles most of the traffic and the old one is left with a single responsibility.
Before the first takeover you need a dependency map and safety tests. Without a map you do not know what depends on what, and without tests you do not know whether the new module behaves like the old one. The starting point is covered in the legacy code audit, and the technique for testing old behavior in the article on characterization tests.
Pitfalls I see in practice
Strangler Fig is safe, but not free of pitfalls. The four most common
Shared database. Old and new systems write to the same database for a long time. This demands discipline: schema migrations must be compatible in both directions, and new code must not "incidentally" change structures the old code uses. Eventually each module should get its own schema or data service.
No interception layer from the start. If switching modules requires nginx changes every time, the process will drift. Design the routing layer once, with all future takeovers in mind.
Steps that are too big. Taking over "the entire orders module" instead of "placing an order with online payment" is a rewrite in disguise. A step should be small enough to roll back within an hour.
No monitoring. The new module needs logs, metrics and alerts from day one. Without them, the first problem reaches you from customers, not from a dashboard.
When Strangler Fig is not the right choice
The pattern makes sense where the system has clear modules and must run without interruption. There are situations where it is overkill:
- a small, simple system — cheaper to rewrite it whole with tests than to build an interception layer,
- a system with no production traffic — if the application serves no real users, there is nothing to "take over gradually,"
- a project whose goal is a one-step technology swap — e.g. a migration to a new platform where old and new cannot coexist in the same domain,
- a system whose modules have no boundaries — those must be carved out first (a project of its own), and only then migrated.
The "modular refactoring, Strangler Fig or rewrite" decision is best based on an audit and a cost comparison, not on technology fashion.
Strangler Fig in PHP practice
In the PHP ecosystem the pattern takes concrete forms. Laravel is an excellent "new system" that gradually takes over traffic: routing delegates unmigrated paths to the old application (e.g. through a shared session store or an internal redirect), and every new module is a normal framework implementation — with tests, migrations and CI/CD.
When old and new applications must run side by side, two infrastructure elements become critical: a shared session and the routing layer. Pipeline and zero-downtime deployment configuration is covered in the article on CI/CD and DevOps for Laravel, and the choice of the target PHP version in the PHP migration guide.
From pattern to plan
Strangler Fig is a tool, not a plan. A modernization plan starts with an audit and a dependency map, moves through safety tests and module sequencing, and ends with switching the old system off — and that switch-off is the moment modernization formally ends. The whole process is described in the step-by-step modernization guide.
Frequently asked questions
Does Strangler Fig require rewriting the entire system?
No. Taking over feature by feature means every migrated part is written anew (or moved), but the system as a whole is never "rewritten entirely" in one project. Some modules can even be switched off along the way — it turns out nobody needs them.
How long does Strangler Fig modernization take?
It depends on the number of modules and how entangled they are, but predictably — a single takeover takes days or weeks, and the whole process for a medium system spreads over quarters, with production running the entire time. Unlike a rewrite, progress is visible after every module.
How is Strangler Fig different from a rewrite from scratch?
A rewrite builds the new system in full and switches over in one moment — high risk and a long period without results. Strangler Fig switches feature by feature, every step is reversible, and old and new run in parallel. The full comparison of both paths is in the modernization guide.
Can the old and new systems share the same database?
They can, but it demands discipline: the schema must be compatible for both applications, and migrations planned in both directions. Eventually it is worth moving toward per-module data separation — a shared database is the most common source of problems during migration.