The strangler fig pattern modernizes a legacy system gradually. A facade routes requests to the old system or to new services, and functionality moves over one slice at a time until the old system can be retired. For security, it means two codebases and two attack surfaces coexist for a long time.
The pattern in plain terms
Martin Fowler named the approach after strangler figs, vines that grow around a host tree and eventually stand on their own. In software, you build new pieces beside the legacy code and move behavior across in small steps instead of rewriting everything at once.
Microsoft's architecture guidance describes the same shape. A facade, which is a proxy, sits between clients and both systems. At first it sends most traffic to the legacy system. Over time it sends more to the new one. When nothing depends on the legacy system any more, you decommission it and remove the facade.
What changes for security
The pattern lowers delivery risk. It does not lower security risk by itself. Three things happen at once.
First, you now have two dependency sets. The legacy application keeps its old libraries, often unpatched for years. The new services bring fresh ones. A vulnerability scan that only covers the new code will miss most of your exposure.
Second, there is a new component, the facade, that every request passes through. It needs authentication, logging and patching like any other internet facing piece.
Third, the transition has a long tail. Azure's guidance notes the original system can continue to exist for an extended period. Plan for the legacy side to stay in scope for audits, scans and incident response well past the first extracted service.
A short security checklist for each phase
| Phase | What to do |
|---|---|
| Before extraction | Inventory legacy dependencies and record owners |
| Facade introduced | Apply authentication, rate limits and access logs at the facade |
| Each slice moved | Scan the new service, rescan the legacy app, compare |
| Traffic fully shifted | Disable the old route, then remove the code |
| Decommission | Confirm no data stores, credentials or DNS entries remain |
Where teams get caught out
The most common gap is assuming that "legacy" means "being retired, so not worth scanning". A component that will be gone in eighteen months can still be exploited in month three. Ranking the legacy findings by whether the vulnerable code is actually reachable, and by whether the component is internet facing, gives you a defensible order of work.
The second gap is the seam itself. Fowler's description talks about identifying seams where a system can be split. Seams are also where trust assumptions change. Code inside a monolith may call another module without authentication because it is in the same process. Once that call crosses a network, it needs identity and authorization. See our earlier guide on monolith to microservices security migration for that side of the work.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a dependency inventory lists every component with its version. That is the baseline you want for the legacy app before the first slice moves.
Safeguard can produce that inventory from your repositories with SBOM and dependency scanning, and reachability analysis helps you rank what is worth fixing in code that is on its way out. A free scan is at gold.safeguard.sh/scan.
Quick check
Is the strangler fig pattern safer than a big bang rewrite?
It reduces delivery risk because each step is small and reversible. Security exposure is a separate question, since the old and new systems run side by side and both need scanning and patching.
Does the facade need to be secured?
Yes. Every request passes through it, so it needs authentication, logging and regular updates, and it should not become a single point of failure.
Sources
Last reviewed: 19 October 2026.
