What is the strangler fig pattern?
The strangler fig pattern is a way to replace a legacy system gradually instead of all at once. A shared interface, usually a layer of APIs, is placed in front of the old system. New features are built behind that interface, and existing functions are moved to new systems one at a time, until the legacy system handles nothing and can be switched off. Software author Martin Fowler named the approach in 2004 after the strangler fig, which grows around a host tree until it stands on its own. Microsoft and AWS both document it as a standard modernisation pattern.
Why are big-bang replacements so risky?
- All the risk lands on one weekend. Every dependency, data issue and training gap shows up at once.
- Value arrives last. Nothing new reaches customers until the whole replacement is finished.
- Rollback is hard. Once data has moved and users have switched, going back is expensive.
- The target moves. The business keeps changing while the replacement is built, so it is out of date at launch.
How wrap-then-replace works in practice
- Map what you have. Every function, interface and data flow of the legacy system, and who depends on each.
- Put a front door in place. Secure, documented APIs for the functions other systems need, with authentication, validation, rate limits and logging.
- Move consumers to the front door. New and existing applications call the APIs, not the old system directly.
- Replace one function at a time. Each function moves behind the same API to a new system, runs in parallel, is reconciled, then cuts over.
- Retire the old system. When nothing calls it any more, archive the data you must keep and switch it off.
Where it works, and where it does not
| Works well | Think twice |
|---|---|
| Mainframe and IBM i cores with clear transactions | Small systems you could replace in a single sprint |
| SAP ECC, keeping the core clean during an S/4HANA move | Systems where the data model itself is the problem |
| Legacy databases feeding many reports and applications | Systems that cannot handle extra calls, even with caching |
| Organisations that need new channels before the replacement is done | Short-lived systems due for retirement within months |
The wrapper is a front door. Secure it like one.
A wrapper concentrates access to your most important system, which makes it a target. Done properly, it is more secure than the access it replaces:
- Every caller authenticated, ideally through your identity provider
- Least privilege: each consumer sees only the operations and fields it needs
- Inputs validated against a schema before they reach the legacy system
- Rate limits and quotas to protect the old system from new traffic
- Every call logged for audit and troubleshooting
- The legacy system never exposed directly to the internet
The same front door is also a safer way to let AI assistants and agents use legacy data, with governed, scoped access instead of database logins.
Wrap the system you cannot replace yet. Replace it behind the wrapper when you are ready.
How we help
We build secure API wrappers around mainframes, IBM i, SAP and legacy databases as fixed-price 30-day sprints from A$50,000, then replace what sits behind them one sprint at a time.