Strangler Fig Migration Pattern
Term 50 of 68 in the ERPStack technical glossary
What is Strangler Fig Migration Pattern?
The Strangler Fig Pattern is a software migration strategy that incrementally replaces a legacy monolithic system by gradually routing specific business functions to a new modern service, allowing a zero-downtime transition without a risky big-bang rewrite.
Strangler Fig Migration Pattern at a glance
- Mechanism
- 1 routing facade sends each path to either the legacy system or the replacement
- Unit of migration
- 1 bounded capability at a time, each independently reversible
- Risk profile
- Rollback affects 1 module rather than the 100% cutover a big-bang release requires
- Ends when
- 0 traffic reaches the legacy system, which is then decommissioned rather than abandoned
- Built with
- A Next.js 16 routing facade in front of the legacy system, new modules on PostgreSQL 18 with Drizzle ORM 0.45, environments defined in Terraform, routes switched through GitHub Actions
- Numbers that matter
- Day 1 routes 100% to the legacy system; the last step routes 0; each slice reverses in minutes rather than over 18 months
- Compare with
- A big-bang cutover from SAP S/4HANA, Oracle NetSuite or Epicor ERP in 1 weekend
- Commonly paired with
- Feature flags, Cloud Migration onto AWS or Microsoft Azure, Terraform environments, GitHub Actions route switching, Docker and Kubernetes workloads, PostgreSQL 18 replication and Sentry monitoring
- What the facade fronts
- A Next.js 16 routing layer over the legacy system, new modules on PostgreSQL 18 through Drizzle ORM 0.45, Docker and Kubernetes workloads, environments in Terraform, routes switched by GitHub Actions.
- Typical starting estates
- A Monolithic Architecture built on SAP, Oracle NetSuite, Epicor ERP or Sage X3 in manufacturing, logistics or finance — replaced 1 capability at a time.
How Strangler Fig Migration Pattern works in production
The ERPStack approach to Strangler Fig Migration Pattern
We execute Strangler Fig migrations using Next.js API routes as the façade gateway. We use Debezium CDC (Change Data Capture) for continuous data replication from the legacy database to PostgreSQL, ensuring zero data loss during the transition window.
Frequently asked questions about Strangler Fig Migration Pattern
How does the Strangler Fig Migration Pattern actually work?
You put a facade in front of the legacy system and route by capability. On day 1 the Migration Pattern sends 100% of traffic to the old system. As each capability is rebuilt, its route is switched to the new implementation while everything else is untouched. The legacy system shrinks until nothing reaches it, at which point it can be decommissioned with evidence rather than hope.
Why is this safer than a big-bang cutover?
Because the blast radius of a mistake is 1 module. A big-bang replacement concentrates all risk into a single night, with a rollback plan nobody has rehearsed. The Migration Pattern makes each step small enough to reverse in minutes by flipping a route back, and it delivers value continuously instead of after 18 months of parallel development with no user feedback.
What is the hardest part of a strangler migration?
Data, not routing. During the Migration Pattern both systems may need to read and write overlapping records, so you must decide for each entity which side is authoritative and how changes propagate. Options are a shared database during transition, synchronisation through events, or a strict split where 1 side owns each entity outright. Getting this wrong produces divergence that is expensive to reconcile.
How long should a strangler migration take?
As long as it takes to move capabilities, but the pattern fails when it stalls. A Migration Pattern rollout that stops halfway leaves 2 systems to maintain, 2 sets of on-call knowledge and a permanent integration layer. The discipline that prevents this is finishing and decommissioning each slice before starting the next, so partial completion is never a comfortable resting state.