The strangler fig pattern: modernising legacy systems without the big bang
Replacing a legacy system all at once is rarely the right move. The strangler fig pattern lets you incrementally replace functionality while keeping the business running.
The big bang that never lands
Every few years, a business reaches a tipping point with a legacy system. The maintenance cost has become absurd. The system is blocking new features. The people who built it have left. The decision is made: we will replace it.
The plan is always the same. Build the new system in parallel. Run both for a period. Cut over on a date. The date slips. Then slips again. The new system is never quite ready. The old system keeps accumulating patches. Eventually the project is quietly cancelled and the legacy system runs for another decade.
How the strangler fig works
The strangler fig pattern takes a different approach. Instead of building a replacement and cutting over, you route traffic through a facade layer that sits in front of the legacy system. Piece by piece, you re-implement functionality behind the facade and redirect traffic to the new implementation - without the legacy system or its users knowing anything has changed.
The name comes from a tropical plant that grows around a host tree, gradually taking over until the original tree is gone. The legacy system is the host. Your new implementation is the fig. When the last piece of functionality has been replaced, you remove the legacy system. The facade was always there - it just gradually redirected more and more traffic.
Why it works in practice
The strangler fig works because it keeps the business running throughout the migration. There is no big cutover date. There is no 'the new system needs to be complete before we go live.' Each piece of re-implemented functionality can be deployed and validated independently. If something breaks, the facade can route traffic back to the legacy system while the issue is investigated.
It also forces discipline. Because you are routing real traffic through the new implementation from day one, you discover integration issues, performance problems, and edge cases early - when they are cheap to fix - rather than on cutover day.
When to use it
The strangler fig works best when the legacy system has a well-defined interface - an API, a database schema, a message queue. If your legacy system is a tangled monolith with no clear seams, you may need to do some decomposition work before the pattern can be applied.
It also requires a team willing to operate two systems in parallel for an extended period. That is overhead, and it needs to be planned for. But it is far less overhead than a failed big bang replacement.
The alternative is worse
The cost of a failed big bang replacement is not just the project budget. It is the opportunity cost of everything else your team could not build during that time, the organisational credibility lost when the project fails, and the technical debt that accumulates while the legacy system runs for another decade.
The strangler fig is not glamorous. It is not a rewrite. But it is how legacy modernisation actually succeeds.