Every few years a new technology promises to make legacy modernization easy. In 2026 that promise comes from AI coding agents that can read a million lines of COBOL, Java or .NET, extract the business rules and draft a new service in an afternoon. The capability is real. What has not changed is the hard part: a core system that processes orders, claims or payments cannot be switched off on a Friday and replaced by Monday. The risk in modernization was never just typing speed. It is behavior nobody wrote down, data that two systems must share, and users who cannot tolerate an outage.
That is why the strangler fig pattern, first described by Martin Fowler in 2004, is more relevant now, not less. AI makes each slice of work cheaper. The strangler fig gives you a way to deliver those slices safely, one capability at a time, with a rollback path at every step. This article explains how the pattern works in practice today, where AI agents genuinely help, where they introduce new risk, and how to plan a strangler program that actually reaches the finish line.
What the Strangler Fig Pattern Is, and Why It Still Wins
The name comes from fig vines Fowler saw in Queensland rainforests: they grow around a host tree until the host is gone and the fig stands on its own. Applied to software, you build a new system around the edges of the old one, route more and more traffic to the new parts, and retire the legacy system when nothing meaningful is left inside it. Fowler renamed his original article to “Strangler Fig Application” in 2019, and in 2024 Thoughtworks colleagues expanded the idea into a broader catalogue of legacy displacement patterns.
The alternative, a big-bang rewrite, fails for predictable reasons. Rewrites are almost always more complex than they look, they must reproduce years of accumulated behavior (including bugs that downstream systems now depend on), and they deliver no value until the very end. The strangler approach inverts that profile:
- Value arrives early. The first migrated capability can be in production within months, not years.
- Risk is sliced. Each cutover affects one capability, so a failure is contained and reversible.
- Learning compounds. Every slice teaches the team more about the legacy system, the data and the domain, which improves the next estimate.
- Scope shrinks. Features nobody uses are discovered and dropped rather than faithfully rebuilt.
- The business keeps running. Both systems operate side by side, so there is no single high-stakes weekend.
Microsoft’s Azure Architecture Center and AWS Prescriptive Guidance both document the pattern, and both are candid about the trade-off: you carry temporary complexity from running two systems and a routing layer. The bet is that this overhead is far cheaper than the risk of a failed rewrite. For most business-critical systems, it is.
The Core Mechanics: Facade, Anti-Corruption Layer and Data Sync
A strangler program has three moving parts. Getting them right matters more than the choice of target language or cloud.
1. The routing facade
A proxy or API gateway sits between clients and the legacy system. On day one it routes everything to the old system, which proves the facade adds no regression. Then, capability by capability, it starts sending specific routes, users or tenants to new services. Routing can be by URL path, by header, by customer segment or by percentage, which lets you run canaries and roll back with a configuration change rather than a deployment. Both Microsoft and AWS stress the same warning: the facade must not become a single point of failure or a performance bottleneck, so treat it as production infrastructure with its own redundancy, monitoring and change control.
2. The anti-corruption layer (ACL)
The legacy system will keep calling functionality that has moved. An anti-corruption layer translates those internal calls to the new service’s interface, so legacy callers do not need to change and, just as important, the new service’s model is not polluted by legacy concepts. The ACL is scaffolding. Plan its removal from the start, because an ACL that outlives the migration becomes another layer of legacy.
3. Data synchronization
Data is where most strangler programs stall. A new service usually needs its own data store, but the legacy system still reads the same records. The common sequence is an initial bulk load (ETL), followed by change data capture (CDC) from the database transaction log for ongoing sync, with consistency validated before each cutover. Microsoft’s guidance makes a sharp point here: rollback is straightforward until you delete legacy database objects, and expensive and risky afterward. Treat removal of legacy tables as a deliberate final step per domain, not a cleanup task.
AWS describes this synchronization as a tactical, eventually consistent measure. That is the right framing. Dual-write and sync agents are bridges, not destinations, and every one you build adds operational load until it is removed.
What AI Agents Change in 2026
The biggest shift since the pattern was written is in the cost of understanding and rewriting code. Through 2025 and 2026, hyperscalers and tool vendors turned agentic modernization into products. AWS Transform, for example, now positions itself as an agentic platform for modernizing legacy code, infrastructure and applications, including mainframes. A May 2026 AWS Migration and Modernization blog post describes a “reimagine” workflow in which AWS Transform reverse-engineers COBOL, PL/I and JCL to extract business rules with Given/When/Then acceptance criteria, data lineage and a data dictionary, then hands those artifacts to an agentic coding tool such as Claude Code to generate specifications, microservices, unit tests and infrastructure as code. Each generated rule keeps a link to its source rule ID, and human experts validate specifications before code is generated.
Mapped onto the strangler pattern, AI helps most in four places:
- Discovery and seam finding. Agents can map call graphs, data access and batch dependencies across a large codebase in days, which makes it far faster to find natural seams: modules with few dependencies or their own data.
- Business rule extraction. Turning undocumented logic into explicit, testable rules is traditionally the slowest part of any modernization. It is also the most valuable output, because it becomes the contract for the new service.
- Characterization tests. Agents can generate large suites of tests that pin down current behavior, including edge cases, so you can prove the new service matches the old one.
- Forward engineering. Once a specification is agreed, generating a service skeleton, data access code, API contracts and deployment templates is now quick and fairly reliable.
Notice that none of this removes the need for the strangler structure. It makes each slice cheaper, which means you can afford smaller slices, more tests and more frequent cutovers. That is a better strangler program, not a reason to attempt a big bang again.
The new risks AI introduces
Faster code generation also produces new failure modes that a modernization plan must address:
- Plausible but wrong translations. Generated code can compile, pass shallow tests and still differ from legacy behavior in rounding, date handling, character encoding or error paths.
- Spec drift. If the extracted rules are incomplete, the new service will faithfully implement the wrong thing at high speed.
- Review bottlenecks. Generation outpaces human review. Without strong test oracles, reviewers become the constraint and quality slips.
- Expert scarcity. In a March 2026 ITPro interview, AWS Transform VP Asa Kalavade stressed that COBOL experts remain essential to define transformations and validate output. AI shifts experts from writing code to judging it; it does not make them optional.
AI makes each slice of modernization cheaper. The strangler fig pattern is what makes each slice safe. Use the savings to cut thinner slices and test harder, not to attempt a bigger bang.
Choosing What to Strangle First
The order of extraction determines whether a program builds momentum or stalls. AWS’s guidance suggests looking for natural divisions such as components with few dependencies or their own data access, and weighing compliance needs, release cadence, scaling requirements and team cognitive load. In practice, a simple scoring grid works well. Rate each candidate capability on:
- Business value of change: Is this area slowing the business today because changes are slow, risky or impossible?
- Coupling: How many other modules call it, and how much shared data does it touch?
- Interceptability: Can requests to it be routed at the edge, or are they buried in internal calls and batch jobs?
- Data ownership: Can it own its data cleanly, or does it write to tables half the system reads?
- Knowledge risk: Are the people who understand it close to retirement or already gone?
- Operational risk: What happens to customers and revenue if it misbehaves for an hour?
The ideal first slice is valuable, loosely coupled, easy to intercept and low in operational risk. It proves the facade, the deployment pipeline, the observability stack and the data sync approach end to end. Resist the temptation to start with the most painful core module; that is the slice most likely to stall and drain confidence. Domain-driven design and event storming workshops help here, because decomposing before you understand the domain puts service boundaries in the wrong places, and wrong boundaries are expensive to move.
A Step-by-Step Strangler Playbook
The following sequence reflects how mature teams run strangler programs today, with AI tooling folded in where it adds real leverage.
- Baseline the legacy system. Capture current performance (for example P90 and P95 latency), error rates, batch windows and business KPIs. You cannot prove parity or improvement without a baseline.
- Run AI-assisted discovery. Use agents to inventory code, map dependencies and extract candidate business rules. Have domain experts review and correct the output. Treat the result as a living specification, not a one-off report.
- Define the target architecture and boundaries. Decide service boundaries with domain experts, choose the target platform, and agree conventions for APIs, events, identity and observability.
- Stand up the facade in pass-through mode. Route all traffic through it to the legacy system and verify that nothing changes. Add tracing so you can see every request path.
- Build characterization tests. Pin down current behavior for the first slice using recorded production traffic, generated test cases and expert-written scenarios.
- Build the first new service. Generate and hand-refine code against the agreed specification. Keep traceability from each rule to its tests.
- Set up data sync. Bulk load, then CDC. Add reconciliation jobs that compare records across systems and alert on drift.
- Shadow, then canary. Send mirrored traffic to the new service and compare responses without affecting users. Then shift a small percentage of real traffic, watch the metrics, and expand.
- Cut over and keep the rollback path. Route the capability fully to the new service but keep legacy code and data available until a defined stability period passes.
- Decommission deliberately. Remove the ACL paths, the sync jobs and finally the legacy objects for that domain. Record what was retired so the system really shrinks.
- Repeat with thinner slices. Each round should be faster as the platform, tests and team knowledge mature.
Two practices make the difference between a program that finishes and one that leaves you running two systems indefinitely. First, measure retirement, not just migration: lines of legacy code removed, tables dropped, batch jobs switched off. Second, design new services so they can be strangled in turn. Fowler’s warning that today’s new code is tomorrow’s legacy applies to AI-generated code as much as anything else.
When the Strangler Fig Is the Wrong Choice
The pattern is not universal. Microsoft and AWS both list conditions where it does not fit, and experience adds a few more. Consider a different approach if:
- Requests cannot be intercepted and there is no other integration point, such as the database, that you can hook into.
- You have no access to the legacy source code and no way to redirect internal calls.
- The system is small and a direct replacement is simple and low risk.
- You must exit quickly, for example because a data center lease or a hard licensing deadline ends in months. A rehost or replatform first, followed by incremental modernization in the cloud, may be safer.
- The problem is the product, not the code. If the business process itself is changing, buying a SaaS product and migrating data may beat rebuilding anything.
Licensing changes, such as the VMware pricing shifts many organizations faced after 2024, push some teams toward fast moves. A sensible hybrid is to rehost to stabilize costs, then apply the strangler pattern to the parts of the estate that actually need to change. Modernization is a portfolio decision, not a single choice for every system.
Worked Example: Strangling a Policy Administration Monolith
Consider a generic mid-sized insurer running a 20-year-old policy administration system: a Java monolith in front of a large relational database, with nightly batch jobs for renewals and billing. Product teams wait months for simple changes, and the engineers who built the rating engine have left.
The team starts with AI-assisted discovery. Over three weeks, agents map the codebase and extract a first draft of rating, endorsement and document-generation rules; underwriting experts correct and approve them. The scoring grid shows that document generation is loosely coupled, called through a small number of entry points and low in operational risk. It becomes slice one. Rating is high value but deeply coupled, so it is scheduled for later, after the data sync approach has been proven.
An API gateway goes in front of the monolith in pass-through mode. The team records a month of document requests, generates characterization tests from them and builds a new document service. In shadow mode, the new service produces documents in parallel and a comparison job flags differences; most turn out to be formatting edge cases, but two reveal undocumented regional rules that the extraction missed. Those rules are added to the specification, which is exactly the kind of discovery the strangler approach is designed to surface safely. After a canary period, document generation is cut over and the old module is removed.
Slices two and three, endorsements and customer notifications, go faster because the facade, pipelines and reconciliation tooling already exist. By the time the team tackles rating, it has a proven CDC pipeline, a growing rule catalogue and a track record that makes the business comfortable with the riskiest move. At every stage, customers keep getting policies, and the legacy system steadily shrinks.
Governance, Metrics and Team Shape
Strangler programs run for months or years, so they need governance that keeps them honest without slowing them down. Useful practices include:
- A visible migration map showing every capability, its status (legacy, shadow, canary, migrated, retired) and its owner.
- Parity and outcome metrics per slice: response-time percentiles against the baseline, defect rates, reconciliation drift and business KPIs.
- Change-freeze rules for capabilities in flight, so the legacy and new versions do not diverge while both are live.
- AI usage policy covering which code can be sent to which models, how generated code is reviewed and how traceability to rules is preserved.
- A decommissioning budget, because removing old code and infrastructure takes real effort and is the first thing cut when schedules slip.
On team shape, the most effective pattern is a stable cross-functional team that owns a domain end to end: legacy experts, engineers on the target stack, a data engineer for sync and reconciliation, a QA lead focused on test oracles, and a product owner who can make scope calls. AI tools change the mix, with fewer people typing boilerplate and more effort on specification, review and testing, but they do not remove the need for continuity. A strangler program is a marathon of accumulated knowledge, and rotating teams lose it.
Conclusion: Thinner Slices, Faster Feedback
The strangler fig pattern endures because it addresses the real risk in modernization: replacing behavior that nobody fully understands without disrupting the business. AI agents in 2026 make discovery, rule extraction, testing and code generation dramatically cheaper. The smart response is to use those gains inside the strangler discipline: smaller slices, stronger characterization tests, shadow traffic, and deliberate decommissioning. Teams that treat AI as a reason to attempt another big-bang rewrite are likely to rediscover why the pattern was invented.
Start with a baseline, a pass-through facade and one low-risk, loosely coupled capability. Prove the mechanics, measure retirement as seriously as delivery, and let each successful slice fund confidence for the next. That is how a legacy system is replaced without ever betting the business on a single cutover.
How Hanoi Technology Can Help
Hanoi Technology helps teams plan and run incremental, AI-assisted modernization programs, from discovery and facade design to data sync and decommissioning, as projects or dedicated teams.
Further Reading
- Original Strangler Fig Application – Martin Fowler
- Strangler Fig Pattern – Azure Architecture Center, Microsoft
- Strangler Fig Pattern – AWS Prescriptive Guidance
- Reimagining Mainframe Applications with AWS Transform and Claude Code – AWS
- COBOL Developers Will Always Be Needed Even as AI Takes the Lead on Modernization – ITPro