Most legacy-system debates begin with two uncomfortable choices. Keep tolerating the system that blocks every new request, or replace the whole thing and accept the disruption.
The strangler fig pattern offers a more useful question: which part of the old system still earns its place?
Named after a plant that grows around a host tree, the pattern moves capability out of a legacy application in controlled pieces. New software handles more of the work over time. The old system becomes smaller until the business can retire it, or keep a limited part for a reason it can defend.
That last point matters. A wrapper is not a polite way to avoid a difficult replacement forever. It is a way to change the boundary of the system without gambling the operation on one large migration.
Change the boundary before changing the core
A dependable legacy system can still be a poor place to make new changes.
It may post invoices correctly every night, allocate stock according to rules the business trusts, or hold years of reconciled customer records. Yet launching a portal, connecting a new warehouse, or giving customers live status may require fragile file transfers, direct database access, or work that only one person understands.
The strangler fig pattern leaves the trusted behaviour alone at first. New software creates a controlled route around it.
Consider a warehouse system that accepts orders through a vendor-specific file and returns results in a nightly export. A new boundary could validate orders, translate customer and product codes, submit the file, reconcile the response and show a clear status to the customer. The warehouse application still allocates stock, but the new service owns the customer experience and the difficult handoffs around it.
AWS describes the pattern as incremental replacement through a routing or boundary layer. The useful part is not the architectural label. It is the ability to move one business capability at a time while the live operation keeps working.
Keep the part that still deserves trust
Age alone does not make a system disposable. The better test is whether the retained capability is dependable, understood and supportable.
If the old system produces trustworthy results, has a stable way to exchange data and can recover from failure, it may be sensible to keep it behind a cleaner interface. This is especially true when the urgent change sits at the edge: a new customer service, an integration, better reporting or a different staff experience.
The business also needs to understand the rules it is preserving. A system that appears stable because experienced employees quietly correct it every day is a weaker foundation than the incident log suggests.
This is where a small modernisation step can reveal more than a long replacement specification. The boundary records the inputs, outputs, exceptions and service levels the old capability handles in practice. That evidence helps the business decide what should move next and what may safely remain.
It also avoids paying to rebuild settled behaviour simply because it happens to live in an old application.
Know when the pattern is hiding the problem
Sometimes the core has stopped earning trust.
A wrapper cannot restore security support to an obsolete operating system. It cannot make unreliable records correct, recreate lost supplier knowledge or enforce permissions that the underlying platform cannot support. It can reduce exposure while a migration is prepared, but it cannot remove the reason for the migration.
The NCSC is direct about obsolete products: continued use cannot be made risk free, and stopping their use is the only fully effective mitigation. Isolation, restricted access and monitoring may buy time. That time needs an owner and an end date.
Operational weakness matters too. If every connection needs access to fragile internal tables, recovery depends on unavailable hardware, or routine changes cause failures elsewhere, another layer may increase the amount of software the business cannot safely change.
The strangler fig pattern works when each step reduces dependency. If the wrapper keeps accumulating exceptions while the same unsafe core remains untouched, it has become expensive camouflage.
Start with the change the business cannot make
The first slice should come from a real commercial constraint, not an architectural ambition.
Perhaps a new customer needs order status that the current system cannot expose. Perhaps an acquisition needs two product catalogues to behave like one. Perhaps the finance team cannot reconcile a new sales channel without another person copying data.
Choose one outcome and build the smallest boundary that can deliver it safely. Give the new service ownership, tests, monitoring and visible exception handling. Keep a fallback while a limited group uses it. The GOV.UK beta guidance makes the same practical point: expose a new route to real users in a controlled way and keep the existing service available until the replacement can be run with confidence.
Then look at what the first slice taught you. Did the legacy behaviour prove reliable? Did hidden rules surface? Did the new boundary remove manual work or merely move it? Is the next capability easier to extract?
Those answers turn modernisation from a theoretical programme into a sequence of business decisions.
They also give leaders something a big-bang replacement plan rarely offers: evidence from the live operation before the next investment decision is made.
If a legacy system is blocking a commercial change, book a modernisation conversation. We can identify what still deserves trust, where a strangler fig boundary could create room to move and when replacement is the safer answer.