01Origin
Where does the name come from?
Martin Fowler described the pattern in 2004, after strangler figs he saw in Australian rainforests. The vine grows around a host tree, eventually replaces it, and the tree dies. Fowler's point was that rewriting a system in one go is risky, and growing a replacement around the old system is safer.
The idea is also called incremental modernization. Our method uses it as principle 3, 'Strangle, don't big-bang'.
02Mechanism
How does the facade work?
The facade is a layer in front of the old system that receives every request. It decides, per request, whether the old or the new implementation handles it. For a web application that is usually a reverse proxy, API gateway or routing rule. For messaging or batch work it can be an adapter or a routing component.
The facade does three jobs. It gives callers one stable interface, so they do not notice the change. It lets you switch a capability from old to new without changing the callers. And it lets you switch back, because the old path is still there until you remove it.
03Sequence
The steps, in order
- 01
Pick a capability
Choose a slice with clear boundaries and low coupling, such as one report, one endpoint or one queue.
- 02
Pin down behavior
Write tests around the slice in the old system so you know what 'same' means.
- 03
Insert the facade
Route all traffic through it, still sending everything to the old system. Confirm nothing changed.
- 04
Build the new slice
Implement the capability behind the facade and test it against the pinned behavior.
- 05
Shift traffic in steps
Send a small share to the new code, compare results, widen gradually.
- 06
Retire the old path
When no traffic uses it and the data is consistent, delete the old code for that slice. Then repeat from step one.
04Applied
A phased broker migration
American National, an insurer, moved from IBM MQ to RabbitMQ in phases, with the AceMQ engineering team refactoring the legacy code that depended on the old broker. The migration had no big-bang cutover. See the American National case study.
This is the same shape as the steps above, applied to a messaging layer instead of a web endpoint. Each phase moved a portion of the work, was reviewed before the next, and stayed reversible. The project was delivered by the AceMQ engineering team.
05Limits
When not to use it
In these cases consider a contained rewrite, a lift and shift first, or a different order. The assessment checks for these conditions.
- The system is small and a rewrite takes weeks. The facade costs more than it saves.
- There is no seam to intercept: no network boundary, API or interface where you can place the facade.
- A shared database that cannot be split. Old and new code writing the same tables creates data conflicts you must plan for.
- The old system will be switched off by a fixed date, such as a contract end, that leaves no time for phases.
- No tests and no way to compare old and new results. You cannot tell if a shifted slice behaves the same.
06Pitfalls
What goes wrong in practice
- The old system never gets retired, and you run both indefinitely. Put a retirement date on every slice.
- The facade becomes a new monolith of routing rules. Keep it thin.
- Slices chosen by org chart rather than by coupling, so each one drags dependencies with it.
- Data left out of the plan. Decide per slice which side owns the data and how it syncs.
07Next step
How Ace8 helps
Ace8 is the AI-assisted application modernization practice of AceMQ. Our 8 principles put 'Strangle, don't big-bang' third, and our assessment produces the phase plan: a list of capabilities, their interfaces and the traffic-shift steps. Start with the modernization assessment to find the first slice.