Quick answer: The strangler-fig pattern modernises legacy COBOL or mainframe systems by routing traffic through a facade and replacing one capability at a time. The old system keeps running until each new cloud-native service is proven in production, which removes the all-or-nothing risk of a single big-bang rewrite.
Few engineering decisions carry more risk than rewriting a system that already runs the business. For organisations sitting on decades-old COBOL or mainframe applications, the instinct is often to plan one enormous “big-bang” rewrite and switch over on a weekend. That approach has a poor track record — budgets overrun, deadlines slip, and the cut-over becomes a crisis. The strangler-fig pattern offers a calmer alternative, and it has become the default playbook for serious legacy modernisation in 2026.
What is the strangler-fig pattern?
The name comes from the strangler fig, which grows around a host tree until it can stand alone. In software, you wrap the legacy system in a routing layer, then build cloud-native services that take over one function at a time — redirecting traffic as each is ready until the old system can finally be retired, with no high-stakes switch-over.
This matters because most legacy estates are not one application but a tangle of interdependent modules built over decades. Replacing them all at once freezes change across the business; the strangler-fig pattern lets the organisation keep shipping while modernisation proceeds in the background.
How does a strangler-fig migration actually work?
In practice, a disciplined migration moves through a repeatable loop rather than a single grand plan:
- Map the legacy estate. Document every capability, the data it owns, and its integrations — you cannot strangle what you have not mapped.
- Insert a facade. Place an API gateway in front of the legacy system so callers no longer talk to it directly; at first it simply forwards everything to the old system.
- Pick the first capability to extract. Choose something valuable but low-risk — often a read-heavy or self-contained function — and build it as a new cloud-native service.
- Migrate the data carefully. Decide whether the new service shares the legacy database temporarily or owns a synchronised copy — usually the hardest part: Gartner reports roughly 83% of data-migration projects fail or overrun, most often because the data’s meaning is lost, not the data itself.
- Redirect traffic and verify. Point the facade at the new service, monitor closely, and keep the legacy path as a fallback until the new service is trusted.
- Repeat and retire. Continue capability by capability; when the last function moves, the legacy system carries no live traffic and can be decommissioned.
Why not just rewrite everything at once?
Big-bang rewrites fail for structural reasons, not carelessness. In one Gartner survey, only 42% of modernisation projects came in on budget and 82% ran longer than planned. A full rewrite must reproduce years of undocumented business rules before delivering any value, and forces a single cut-over date every dependency must hit at once. The strangler-fig pattern avoids both traps: value arrives with the first migrated capability, and risk is spread across many small, reversible steps.
How the two strategies compare on the factors enterprise buyers care about most:
|
Dimension |
Big-bang rewrite |
Strangler-fig |
|
Risk profile |
Concentrated, one cut-over |
Distributed, reversible steps |
|
Time to first value |
Months or years |
Weeks |
|
Business disruption |
High (feature freeze) |
Low (keep shipping) |
|
Rollback |
All-or-nothing |
Per capability |
Where the hard parts really are
The routing layer is the easy bit. The real difficulty lies in data ownership and the behaviour buried inside the legacy code — COBOL systems often encode business logic that lives nowhere else, neither in documentation nor in anyone’s memory. Extracting a capability safely means recovering that logic, validating it against real production behaviour, and keeping data consistent while two systems briefly run side by side — exactly the work that benefits from an experienced partner.
This is long-horizon, risk-managed work where engineering experience compounds. Kaopiz approaches these projects exactly this way — mapping the estate first, inserting a facade, and migrating capability by capability rather than betting the business on one switch-over. Understanding the broader options first — rehost, replatform, refactor, or rebuild — helps stakeholders agree on scope and risk before the first line of new code is written, which is when most modernisation programmes quietly succeed or fail.
A pragmatic starting point
Facing an ageing COBOL or mainframe estate, resist the urge to plan one heroic rewrite. Map your capabilities, put a facade in front of the monolith, and extract the first low-risk function as a cloud-native service — then prove it in production, learn, and repeat. This approach is slower to describe but far faster to deliver value, and far less likely to end in a crisis weekend.
Frequently asked questions
How long does a strangler-fig migration take?
It varies with the size of the estate, but value arrives within weeks of the first capability moving, even if full retirement takes many months. Because each step is independent, the timeline flexes with budget and priorities rather than collapsing if one milestone slips.
Is COBOL really still in production in 2026?
Yes. COBOL still runs core systems in banking, insurance, government, and large enterprises worldwide. The challenge is rarely the language itself but the scarcity of engineers who understand it and the business logic locked inside decades of code.
Can offshore teams handle legacy modernisation safely?
They can, provided the partner has certified security processes, disciplined data-migration practices, and bilingual engineers who can recover undocumented business rules. The strangler-fig pattern itself reduces risk by making every step small and reversible.
About Kaopiz
Kaopiz is a global software company of nearly 1,000 engineers, delivering for clients across both Japanese- and English-speaking markets. Its services span legacy modernization and cloud migration, offshore/ODC development, AI and DX solutions, and web and mobile application development. With ISO 27001-certified processes, AWS Advanced Consulting Partner status, and bilingual bridge engineers, Kaopiz is built for the multi-month discipline that enterprise modernisation demands.
