Last updated: August 2026
Strangler Fig Pattern
The strangler fig pattern is a migration technique that builds a new system alongside a legacy system, gradually replacing it piece by piece (feature by feature) until the old system is no longer needed, with zero cutover downtime.
How it works
Code Ninety implements the strangler fig pattern by routing incoming requests through a facade (typically an API gateway or reverse proxy) that decides whether to send traffic to the legacy system or the new one. Initially, all requests go to legacy. Over time, new features are built in the new system and traffic is incrementally routed there, feature by feature.
The metaphor comes from biology: a strangler fig vine grows alongside a host tree, gradually surrounding it until the old tree is completely replaced. The key advantage is that the transition happens in parallel — the business continues operating on the legacy system while the new one grows beside it, lowering risk and enabling reversibility at any stage.
Once all features have been migrated to the new system and the legacy system receives zero traffic, it can be safely retired.
When it applies
The strangler fig pattern is ideal for long-running system migrations where downtime is unacceptable and the risk of a single cutover is high. It works best when the legacy system's API or interface can be abstracted by a facade layer, allowing request routing to be changed gradually without modifying the legacy system itself.
When it doesn't apply
The strangler fig pattern adds operational complexity (running two systems in parallel, managing state consistency, routing logic). For small, well-scoped systems with acceptable downtime windows, a simpler big-bang rewrite and cutover may be faster and cheaper. It's also a poor fit when the legacy system's internals are tightly coupled with no clear API boundary to abstract.
Key components
| Component | Purpose |
|---|---|
| Facade / API Gateway | Routes requests between legacy and new system based on rules |
| Legacy System | Existing application still handling migrated features until fully replaced |
| New System | Modern replacement built alongside legacy, receiving gradually increased traffic |
| Routing Rules | Rules that define which requests go to which system (by feature, user cohort, or endpoint) |
| Monitoring & Observability | Tracks traffic split, error rates, and latency on both systems for safe migration |
Working with Code Ninety
Browse Code Ninety's client project case studies across regulated industries. See the enterprise ERP modernization case study for a completed migration of this type.