Every company with a ten-year-old core system eventually has the same meeting. Someone proposes a rewrite. Someone else remembers the last rewrite. Nothing gets decided for another year.
The pattern most architects reach for instead is older than most of the systems it is used on, and it has recently picked up an assistant: AI coding agents that are good at some parts of the job and unreliable at others. This guide covers how the pattern works, what the major cloud vendors say about when not to use it, and a realistic split of work between agents and engineers.
What the strangler fig pattern is
Martin Fowler named the idea after strangler figs he saw in Queensland rainforests in 2001: vines that sprout on a host tree, grow around it, and eventually stand on their own. Applied to software, you stop trying to replace the whole system at once. You build new functionality beside the old system, then move behaviour across a slice at a time. Fowler's argument for it is about risk: investment and failure are spread over many small steps, and the business gets value as each piece ships rather than at the end of a long project. He is also clear that it does not make modernization easy.
Both AWS and Microsoft document the same mechanics. A proxy or facade sits in front of the old system. Clients keep calling the same interface. Behind it, you route each request either to the legacy application or to a new service, and shift routes one at a time. Microsoft's description has four phases: introduce the facade, migrate incrementally, decommission the legacy system, and finally remove the facade so clients talk to the new system directly. AWS frames it as transform, coexist, eliminate, and stresses keeping the monolith available for rollback.
When it fits, and when it does not
Microsoft's architecture guidance lists conditions where the pattern is a poor choice, and they are worth reading before you commit:
- You cannot intercept requests to the back end, so there is nowhere to put the facade.
- You cannot modify the legacy source code. You need that access to switch off migrated features and redirect internal calls.
- The system is small and a full replacement is simple.
- The old system has to be decommissioned quickly.
AWS adds that the proxy layer can become a single point of failure or a performance bottleneck if it is poorly designed, and that each migrated service needs a rollback plan.
A fifth condition comes from experience rather than documentation: the legacy system and the new one usually share a database for a long stretch of the migration. Microsoft flags shared data stores as a consideration. If your plan quietly assumes clean data boundaries from day one, it is a rewrite with extra steps.
How to pick the first slice
The first slice decides whether the organisation believes in the approach. Good first candidates tend to share three traits:
- A narrow, well-understood interface. A pricing calculator, a document generator, a notification service.
- Real business pain. A report that takes minutes to run, a feature the old stack cannot support, an integration partners keep asking for.
- Easy to compare. You can run old and new side by side on the same inputs and diff the outputs.
Avoid starting with the most tangled core module just because it is the most painful. Pick something that proves the routing, deployment and rollback machinery with limited blast radius, then take on harder slices with that machinery already working.
The part that is easy to underestimate: knowing what the old system does
Legacy systems encode years of business rules that nobody wrote down. Before you move a slice, you need an executable description of its current behaviour, including the odd parts. The standard technique is the characterization test: a test that records what the code actually does today, bugs included, so you notice when the replacement behaves differently. Michael Feathers popularised it in Working Effectively with Legacy Code.
A practical sequence for each slice:
- Capture real inputs and outputs for the slice, from logs or by replaying production traffic in a safe environment, with personal data removed.
- Turn those into characterization tests.
- Build the replacement until the tests pass.
- Run both implementations in parallel behind the facade, serve users from the old one, and compare results. Log every difference.
- Shift a small share of traffic, then more, with a one-step rollback.
- Delete the old code path only after a full business cycle has passed without surprises. Month-end and year-end jobs are where hidden rules live.
Where AI coding agents help
Used with discipline, agents speed up the tedious parts of this sequence. They are strongest on work that is bounded, checkable and repetitive.
Reading and documenting code. GitHub's October 2025 write-up on legacy modernization describes using Copilot to reverse-engineer code into documentation, then adding structural context, then using coordinated agents to map dependencies, extract logic and generate tests. The same article is careful to say human validation is needed at checkpoints and that domain experts should review the analysis. It is also a vendor post, so read its claims as direction rather than proof.
Generating characterization tests at volume. Writing hundreds of tests that pin down current behaviour is exactly the kind of work that was never done because it was boring. An agent can draft them; an engineer reviews a sample and the cases that matter.
Mechanical upgrades. The best public evidence is Amazon's. In a August 2024 LinkedIn post, Andy Jassy said an internal Amazon Q Developer tool cut the average Java upgrade per application from about fifty developer-days to a few hours, that the team had upgraded more than half of Amazon's production Java systems to Java 17 in under six months, that he estimated about 4,500 developer-years saved, and that 79 percent of the auto-generated code reviews shipped without further changes. These are the company's own figures about its own codebase, and a version upgrade is a much narrower task than re-architecting a system, so do not read them as a forecast for your project.
Draft translations of isolated modules, such as one COBOL program to Java, as a starting point for an engineer, not as a deliverable.
Where agents still need a human owner
Intent. Code shows what a rule does, not why it exists. An agent can faithfully port a discount rule that finance retired in 2019, or delete a check that exists because of a regulatory incident. Someone who knows the business has to confirm which behaviours are required.
Subtle correctness. Translations that look right can differ in ways tests with small samples miss: numeric precision (decimal arithmetic turned into floating point), date and time zone handling, rounding, text collation, integer overflow. Money and compliance code deserve extra review and property-based or differential testing against the old system.
Accountability. An agent cannot be on call, sign an audit attestation or explain a change to a regulator. Every slice needs a named engineer who understands what shipped.
Scale of autonomy. Letting many agents change a large codebase at once, without a checkable result after each step, is how teams end up with a pile of plausible code and nothing that runs. Keep each agent task small and give it a test to pass.
A workable division of labour
| Task | Agent role | Human role |
|---|---|---|
| Map modules and dependencies | Draft the map and documentation | Correct it, mark what is dead code |
| Characterization tests | Generate in bulk | Review samples and edge cases |
| Boundary design for the slice | Suggest options | Decide, own the interface contract |
| Port the slice | Draft implementation | Review, rewrite what is wrong |
| Parallel run and diff | Summarise differences | Decide which differences are bugs |
| Cutover and rollback | None | Own the decision and the on-call |
Planning and cost
Be sceptical of any estimate that treats modernization as a single line item. A better frame is a series of slices, each with its own scope, test coverage and rollback plan, so you can stop or reprioritise after any of them. Budget separately for the facade and routing layer, the parallel-run infrastructure, and the data migration, because those are the pieces that rarely appear in a first estimate. If a vendor promises a one-click conversion, ask to see the verification method: what was compared, on what data, and who signed off.
A starting checklist
- Can we put a proxy in front of the system and intercept calls?
- Can we change the legacy code where we need to redirect or disable features?
- Do we know who owns the business rules for the first slice?
- Do we have, or can we capture, real inputs and outputs for it?
- Is there a one-step rollback for every cutover?
- Who is on call for the new service on day one?
If three or more of these are a no, fix them first. They are cheaper to solve before the migration begins.
Frequently asked questions
Is a full rewrite ever the right answer? Sometimes, for small systems or when the old one must be switched off quickly. Microsoft's guidance lists both as cases where the strangler fig pattern is a poor fit.
Do we need microservices to use this pattern? No. The pattern is about routing and gradual replacement. The new components can be modules in a new application, services, or serverless functions, whichever your team can run well.
Can AI agents migrate a legacy system on their own? Not safely with today's tools. They can speed up documentation, test generation and mechanical conversion, but intent, correctness checks and accountability still need engineers. GitHub's own guidance on the topic says the same about human validation.
How long does this take? It depends on the size of the system and the number of slices, which is why a slice-by-slice plan with early wins is more honest than a single end date.
Where to go from here
If you have a system that is expensive to change and nobody wants to rewrite it, our custom software development team can map the first slices and set up the facade, test harness and parallel run. If you are still deciding whether to modernize, build new or buy, our consulting service can review the options, and our guide to custom software vs SaaS covers the buy-or-build question. When you are ready to talk it through, book a call.
Sources
- Martin Fowler: Strangler Fig Application
- AWS Prescriptive Guidance: Strangler fig pattern
- Microsoft Azure Architecture Center: Strangler Fig pattern
- GitHub Blog: How GitHub Copilot and AI agents are saving legacy systems (14 October 2025)
- Simon Willison: quoting Andy Jassy on Amazon Q Developer Java upgrades (24 August 2024)
- Michael Feathers, Working Effectively with Legacy Code (Prentice Hall, 2004)
