Explore the Full Cluster
What is Strangler Fig Migration Pattern?
Zero-downtime strategy for replacing legacy monolithic software.
Implementation partner for the messy middle. You tried the new AI tools. Now finish properly — we turn experiments into reliable, owned operational systems. Book a free call →
Definition
An architectural pattern where a new, modern application (Next.js/Postgres) is built around the edges of a legacy system. Workflows are incrementally rerouted to the new system until the old system can be safely strangled and decommissioned.
How It Works in Practice
The Strangler Fig pattern borrows its name from the tropical fig tree that grows around a host tree, eventually replacing it entirely. In software architecture, the pattern works identically. You deploy a new application alongside the legacy system and use a routing proxy (typically an edge middleware or API gateway) to selectively route traffic between them. Start by identifying the least risky, highest-value workflow in the legacy system. Build that workflow in the new stack (Next.js, PostgreSQL, Vercel). Route all traffic for that specific workflow to the new system while everything else continues hitting the legacy application. Once validated in production, move to the next workflow. Repeat until the legacy system handles zero traffic and can be decommissioned. The critical architectural component is the routing proxy, which must support request-level routing rules: "all /inventory/* requests go to the new system, everything else goes to legacy." Feature flags further refine this: you can route 5% of inventory traffic to the new system initially, monitoring for errors before scaling to 100%. The pattern is particularly powerful when combined with an anti-corruption layer, a translation service that converts between the legacy system's data format and the new system's schema, preventing legacy data models from contaminating the new architecture.
Real-World Example
A 20-year-old manufacturing ERP built on ASP.NET with a SQL Server backend was strangled over 9 months. The first workflow migrated was inventory receiving (week 1-4), followed by purchase orders (week 5-8), then production scheduling (week 9-16). By month 6, 70% of daily operations ran on the new Next.js/PostgreSQL stack. By month 9, the legacy SQL Server was decommissioned entirely. The company avoided a $2.1M "big bang" rewrite and experienced zero downtime during the entire transition.
Key Benefits
Common Mistakes to Avoid
Attempting to migrate the database first instead of building an anti-corruption layer that allows both systems to coexist
Routing entire sections of the application in one cut-over instead of migrating individual workflows incrementally
Failing to implement parallel validation where both systems process the same request and results are compared for correctness
Not establishing clear decommission criteria, causing the "strangle" to stall with 80% migrated but the legacy system running indefinitely
Explore the Full Cluster
Need Help Implementing Strangler Fig Migration Pattern?
Slickrock.dev provides fractional AI Architects who design and build production systems using Strangler Fig Migration Pattern, without the overhead of full-time hires.
Book a Free 30-Min CallRelated Concepts
Stuck in the messy middle? We finish AI experiments and ship systems you own.
Book a free call first. If we're a fit, we'll scope a $999 Systems Triage or fixed-scope build — consulting credited toward delivery.
Already spoke with us and ready to start? $999 Systems Triage
Not ready for a call?
Download the Cost of Inaction report — ROI timeline for custom vs. SaaS.
Continue Your Evaluation
Move from research → comparison → action. Each step is designed to answer the next question in your buying journey.