The pattern in four stages
| Stage | What happens | What users notice |
|---|---|---|
| 1. Put a front door in place | A routing layer sits in front of the old system; everything still goes to the old system | Nothing |
| 2. Move one piece | One function is rebuilt, proven against the old behaviour, and requests for it are routed to the new version | That piece behaves the same — or better |
| 3. Repeat | Piece by piece, more requests go to the new system | Improvements arrive one at a time |
| 4. Switch off the old system | Nothing depends on it any more; the routing layer can be removed | Nothing — there is no cut-over day |
This follows the stages in Microsoft’s Azure Architecture Center (updated 18 September 2026), which describes a façade that “routes these requests either to the legacy application or to the new services”, so that “customers continue to use the same interface and are unaware that a migration is in progress.”
Where the name comes from, and why it lowers risk
Martin Fowler named the approach after strangler figs — vines that germinate in a tree, draw nutrients from it, and eventually root and stand on their own. His case against replacing a system in one go is simple: “Replacing a serious IT system takes a long time, and the users can’t wait for new features”, and “replacements seem easy to specify, but often it’s hard to figure out the details of existing behavior.” Moving piece by piece instead “make[s] both investment and returns occur gradually and visibly” (martinfowler.com, updated 22 August 2024).
Both checked 5 October 2026.
When it is the wrong choice
Microsoft’s guidance is direct about the limits. The pattern might not be suitable when:
- Requests to the old system cannot be intercepted
- You cannot access the old system’s source code
- The system is small, and replacing it whole is simple
- You need to retire the original solution quickly
It also warns that the routing layer must not become a single point of failure or a bottleneck, and that data both systems use needs a plan for while they coexist.
What it means for how you pay
Because value arrives piece by piece, payment can follow it: each module accepted, then paid for. You can stop after any piece with something that works, rather than a half-finished rewrite. The temporary cost — running old and new side by side — is the price of never betting the business on one day.
What to ask a vendor who proposes it
- What is the first piece to move, and why that one?
- How will each piece be proven to behave like the old one before it switches?
- What happens to the data both systems use while they run side by side?
- What does each piece cost, and can we stop after any of them?
- How do we know nothing was lost? Ask for a traceability matrix that maps every old behaviour to where it now lives.
How Pricient quotes a modernization
Nothing here is big-bang. Modules move one at a time, parity is proven for each before it switches over, and the old system keeps running the parts that have not moved. Modernization starts with a Legacy System Specification Assessment. It produces a written specification, a risk register, a keep-vs-replace cost comparison and a staged replacement plan, and its fee is credited in full against the first build stage if it starts within 90 days of the report. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins. Tell us what you are running and you get a fixed quote for the assessment.