The Strangler Fig Pattern
The strangler fig pattern is an incremental modernization strategy: you place a routing facade in front of a legacy system, then move functionality to a new system one capability at a time, until the legacy core can be safely switched off. Like the strangler fig tree that grows around its host, the new system gradually takes over — while the business keeps running the whole time.
Why Big-Bang Rewrites Fail
Full rewrites carry a brutal risk profile:
Value Delay
Value arrives only at the end — often two years and several reorganizations later.
Moving Targets
The legacy system doesn't stand still. Every feature added during the rewrite must be built twice.
Hidden Rules
Hidden business rules live only in old code. A rewrite rediscovers them in production, as incidents.
The Cut-over Cliff
Cut-over is a cliff. One weekend, one switch, one company-wide bet.
How the Pattern Works
The strangler fig pattern inverts these risks: value ships from month two, features are built once, and there is never a cliff — only small, reversible steps. Three components make it run:
The Facade (Routing)
An API gateway or reverse proxy sits in front of everything. Clients never talk to legacy directly. Routing rules decide whether a request goes to legacy or new.
Capability Slices
You modernize by business capability (invoicing, pricing) — not by technical layer. Each slice is independently valuable and reversible.
Data Synchronization
During transition, the new service owns its data and changes are synchronized via change data capture or events so legacy keeps functioning.
Reference Architecture
The Playbook We Use
Seams and Safety (2–4 weeks)
Install the facade with 100% traffic still going to legacy. Add observability to learn real usage: which endpoints, which volumes, which capabilities are actually alive.
First Slice (4–8 weeks)
Pick a high-pain but low-entanglement capability. Build the new service, run it in shadow mode (both systems process, results compared), then dial traffic over.
Rhythm (Ongoing)
One slice per iteration. Each slice funds the next through delivered value: faster feature delivery, retired licenses, reduced incident load.
Retirement
When routing shows 0% legacy traffic for a capability, its code is deleted. The monolith shrinks until switch-off is a non-event.
Frequently Asked Questions
How long does strangler migration take compared to a rewrite?
Total duration is often similar — but value arrives from month two instead of year two, and risk per step is a fraction of a big-bang cut-over.
Does this lead to microservices automatically?
No, and it shouldn't. We extract services only where team autonomy or scaling justifies it; several slices can land in a single well-structured modern application ('modular monolith').
What is the most common mistake?
Slicing by technical layer ('migrate the database first') instead of business capability. Layer-slicing creates long periods with no user-visible value — the political death of the program.
Modernize Without Betting the Company
Our architects have executed strangler migrations for enterprise clients where downtime was not an option. Book a modernization strategy session — we will identify your first slice and give you a risk-managed migration plan.
Book Strategy Session