Strangler Fig
matureSummary
Incrementally replace a legacy system by routing subsets of its traffic to a new implementation while the legacy system remains live, eliminating the need for a high-risk big-bang migration.
Problem
Legacy systems cannot be replaced safely with a single cutover migration due to the risk of unknown dependencies, data migration complexity, and the inability to validate the new system at production scale before go-live.
Description
Named after the strangler fig tree that grows around a host tree until the host is fully replaced, this pattern applies to legacy system migration. Rather than rewriting the entire system and switching over at once (a big-bang migration with high risk and long development cycles), the strangler fig introduces a facade layer: typically an API gateway or reverse proxy: that intercepts all incoming traffic.
Individual features or endpoints are migrated one at a time to the new system. The facade routes migrated features to the new implementation and unmigrated features to the legacy system. The migration proceeds feature-by-feature until the legacy system handles zero traffic, at which point it is decommissioned.
The facade is the operational centrepiece. It must support dynamic routing rules that can be updated without redeployment: typically configuration-file- driven or via a control plane API. Traffic percentages enable gradual migration: start routing 1% of traffic for a feature to the new system, validate, increase to 10%, 50%, 100%. Canary routing enables A/B comparison of old and new implementations.
The hardest operational challenge is data. The legacy system and the new system typically use different data models. During the transition period, both systems may need to read and write the same data. Options: (1) the new system reads and writes from the legacy database (tight coupling, but no data sync); (2) a data sync layer keeps legacy and new databases in sync bidirectionally (complex, conflict-prone); (3) the new system gets its own database and a migration window is used to transfer data incrementally.
Dual writes: where both the legacy and new system write to their respective stores simultaneously: require careful ordering and conflict resolution to prevent divergence. This is the primary source of production incidents during strangler fig migrations.
Tradeoffs
Incremental, reversible migrations reduce cutover risk dramatically
Side-by-side comparison of legacy and new responses enables validation
Two systems in production simultaneously doubles operational surface during transition
Dual writes and data sync are the primary source of inconsistency risk
Feature-by-feature migration is slow; extended transitions carry their own risk
When to use
Legacy system is too complex or risky to rewrite in a single migration
Strangler fig spreads risk across incremental migrations; each migration is independently reversible, unlike a big-bang cutover
New system can be built alongside legacy without shared database coupling
If both systems share a database, coordination is simpler; if they use separate data stores, a sync layer is required and must be designed upfront
Traffic can be routed at the feature or endpoint level
The facade must have sufficient routing granularity to route individual endpoints; monolithic systems without feature-level routing boundaries require additional decomposition before migration can begin
Team can operate two systems in production simultaneously
The transition period requires operational support for both legacy and new systems; team capacity and tooling must support parallel operation
When not to use
Legacy system is so tightly coupled that individual features cannot be extracted
A big ball of mud with no feature boundaries requires decomposition before strangler fig can be applied; the facade cannot route to what is not separate
Migration must be completed under an externally mandated deadline
Strangler fig is a slow migration; if a deadline requires full replacement within weeks, the incremental approach may not be fast enough
Data model differences between legacy and new system cannot be bridged
If data synchronisation between legacy and new stores is impossible or produces unresolvable conflicts, dual-system operation is not viable
Operational Requirements
Implement the facade as a dynamic routing layer with per-endpoint traffic percentages
Static routing rules require redeployment for each migration step; dynamic rules enable gradual traffic shifting and instant rollback
Define and monitor data consistency invariants between legacy and new stores
Dual writes or sync layers will produce inconsistencies; define what consistency looks like and alert when invariants are violated
Set a target date for legacy decommission and track migrated-vs-total endpoints
Without a decommission target, strangler fig migrations stall; dashboard of migrated percentage creates accountability
Test rollback of individual feature migrations without affecting others
Each feature migration must be independently reversible; a rollback of one feature must not require rolling back others already validated
Characteristics
Technologies
Canonical
Alternatives
Relationships
Evolves to
Complements
Basis
Well-documented migration pattern; data synchronisation during transition is the primary operational risk and is frequently underestimated
Related Architecture Knowledge
Outbound: this entity affects
Strangler Fig migration progressively extracts services from a monolith; each extracted service is the natural point at which a dedicated database is introduced, evolving the shared monolith database toward a database-per-service topology as the migration progresses.
Tradeoffs
- ·Dual-write migration window is operationally complex: must reconcile divergence before final cutover
- ·Database extraction is the hardest part of strangler fig: shared tables with join dependencies require careful ordering
- ·Each extracted service needs its own connection pool, backup, and monitoring: operational complexity grows linearly
Inbound: affects this entity
Strangler fig incrementally replaces legacy system components with new implementations; blue-green deployment provides zero-downtime switching between old and new components as each strangler fig increment is completed.
Full relationship →