TL;DR
- Every strangler fig migration is also a data migration, usually planned by a different team than the one that owns the code. Most explanations of the pattern treat data sync as an implementation detail instead of a co-equal migration plan.
- AI’s real contribution to this pattern is two specific, mechanical phases. It changes how legacy comprehension gets done before anything moves, and how reconciliation gets done once it does.
- Reconciliation already has a name in the software industry. Comparing a legacy system’s output against a new system’s output before fully cutting over is an established technique. It is rarely applied with the same rigor to the data underneath the code.
- The facade and routing mechanics everyone already writes about are the well-covered part of this pattern. The code and data seam underneath the facade is where a migration stalls. The routing logic itself is rarely the problem.
- A phased migration is only as safe as its least-planned seam. Comprehension and reconciliation belong in the plan as first-class phases, scheduled with the same discipline as the routing layer on both sides of that seam.
How Does a Facade Route Traffic in a Strangler Fig Migration?
The strangler fig approach replaces a legacy application one piece at a time. A facade routes requests to the old system or the new one, and that balance shifts gradually until nothing calls the original.
Martin Fowler coined the term in a post titled “Strangler Fig Application,” named after the vine that grows around a host tree and gradually takes over rather than cutting it down first [1].
Every credible explanation of the pattern agrees on the same basic mechanics. A facade or proxy intercepts requests. New services take over specific pieces of functionality. The facade’s routing shifts further toward the new system with each iteration [2].
This routing-based, incremental replacement is one specific execution of a broader incremental modernization strategy that most enterprises now default to over a big-bang rewrite.
The pattern depends on two things holding true for the length of the migration. Requests to the legacy system have to be interceptable, and its source has to be available to modify.
Azure’s own architecture guidance names exactly when those assumptions break down. That includes systems too small to justify the overhead and legacy systems whose requests can’t be intercepted at all [2].
None of this is contested ground. Every credible existing guide to the pattern gets the facade mechanics right. What the facade diagram leaves out is what happens to the data underneath it.
Why Is a Strangler Fig Migration Also a Data Migration?
A strangler fig migration is a data migration as much as it is a code migration. The facade and routing layer decides which requests reach the legacy system versus the new one.
The data layer underneath decides whether the answers those requests get back are correct while the cutover is happening. Skipping the data side of the plan does not make it optional; the risk simply moves to the point where the two systems’ data quietly disagrees, and nobody notices until it does.
The team that owns the facade and routing logic is usually not the team that owns the data layer, and the two rarely share one migration plan.
While both the legacy application and the new services are live, they typically need to read and write against a version of the same underlying data. The business logic that owns that data hasn’t fully moved yet, which is exactly why the overlap exists.
That overlap is the mechanical reason a data seam exists on every strangler fig migration that touches a shared database.
There is a small, well-established set of mechanisms for keeping two data stores in sync during that overlap.
| Mechanism | How It Works | Main Risk |
| Dual-write | The application writes to the legacy store and the new store at the same time | Writes silently diverge if one side fails and the failure isn’t caught |
| Change data capture (CDC) | Changes stream from the legacy database’s transaction log into the new store continuously | Requires the legacy database to expose a usable change log; schema drift breaks it quietly |
| Backfill / batch ETL | A one-time bulk copy, followed by incremental deltas | Reads during the backfill window can return stale data unless it’s paired with dual-write or CDC |
| System-of-record cutover | The authoritative store flips from legacy to new once parity is confirmed | This step depends on the seam having been verified, rather than assumed to have caught up |
Getting one of these four mechanisms right is necessary, but it says nothing on its own about the two questions that matter most. Was the business logic moving across that seam ever fully understood? Do the two sides of the seam agree once the migration is live in production? Those are the two phases the rest of this piece covers.
Start a $0 Modernization Assessment
+moreHow Does AI Change Legacy Comprehension in a Strangler Fig Migration?
Legacy comprehension means reconstructing the business rules that live in a system. For a strangler fig migration, those rules live in both the code and the schema underneath it, usually without much documentation on either side.
Legacyleap’s own writing on incremental modernization makes the same point about code. The strangler fig approach explains how to migrate a component. It leaves out which one to start with, and that same gap exists on the data side of the seam.
Comprehension done manually today means reading through the application code, interviewing whoever on staff still remembers how a given module behaves, and inspecting the schema table by table to guess which columns still matter.
What that process is looking for is specific:
- Which fields in the legacy schema still drive live business rules, versus which ones are dead weight
- Which stored procedures or batch jobs quietly enforce a constraint the application layer assumes is handled elsewhere
- Which columns get read by more than one consumer that nobody wrote down
Reading the codebase and the schema as one connected system, rather than as two separate documentation exercises, is exactly the kind of AI-assisted legacy system comprehension that changes what this phase can produce.
Instead of a code map and a schema diagram maintained separately, the output is a single map of which code paths touch which tables and columns. It also shows where a business rule is enforced in application code versus enforced, or silently violated, at the data layer.
Skip this phase and the failure mode is specific and recognizable. A migration proceeds on the assumption that the schema is self-documenting, and months in, a field or stored procedure nobody flagged turns out to still be driving live behavior on the legacy side.
What Does Reconciliation Verify Between Legacy and New Systems?
Reconciliation means continuously comparing the outputs, side effects, and state of the legacy and new systems while both are running. It is not a single check performed once at cutover.
The industry already has names for parts of this on the code side. A legacy mimic lets the new system interact with the legacy system without it ever noticing the difference. Dark launching calls a new feature in production without using its results, just to gauge performance under real load [3].
A more direct version also compares outputs. A team routes the same request to both the old and new code paths, keeps the legacy answer as the one the user sees, and flags any difference before anyone depends on it.
GitHub built and open-sourced a library for exactly this workflow, originally used to refactor critical parts of its own codebase without breaking production behavior [4]. It has since been ported into more than a dozen other languages, a reasonable sign the underlying idea is sound engineering practice rather than a one-off trick.
Every one of those techniques compares code behavior. Comparing data behavior is a separate, harder problem. Does the same record from the legacy schema and the new one agree, and can that be checked continuously?
That comparison has to account for row counts, referential integrity across restructured tables, and timing windows where dual-write lag creates a temporary gap that can look like a real discrepancy when the two systems are simply catching up.
Reading the whole codebase and schema together changes what a mismatch tells you. A count that doesn’t match becomes a specific business rule or field that caused two systems to disagree. That is what an engineer needs to know to fix it, rather than just to notice it.
| Legacy Comprehension | Reconciliation | |
| What it answers | What this code and schema do, and where they disagree with each other | Whether the legacy and new systems keep agreeing at every point in the migration, from the first parallel run through cutover |
| Manual approach today | Reading code, interviewing remaining staff, inspecting the schema table by table | A parity check run once before cutover, if it runs at all |
| What changes when code and schema are read together | Business rules enforced in code and rules enforced, or silently broken, in the data layer get mapped as one system | A mismatch gets explained by the specific rule or field that caused it, rather than flagged only as a count that doesn’t match |
| Failure mode if skipped | A field or stored procedure nobody flagged turns out to still drive live behavior | The two systems disagree in production before anyone notices, usually at the worst possible moment |
Why Do Strangler Fig Modernization Projects Stall at the Code and Data Seam?
Some failure modes in strangler fig modernization get written about constantly. Strangling at the UI layer first is one. A bounded context that keeps pulling in adjacent domains week over week is another. Both are real, and both are the well-covered part of this pattern by now.
The seam that rarely gets named as its own failure category is code and data falling out of sync. In practice that means one of a few specific things:
- A dual-write that silently diverges between the legacy and new stores
- A backfill window whose stale reads get treated as ground truth
- A reconciliation check that runs once, at cutover, instead of continuously while both systems are live
Data migration research bears this out more directly than any strangler-fig-specific source does. A 2026 ISG survey of 200 senior decision-makers at large enterprises found that nearly 60% of SAP migration projects, which carry a substantial data migration component, ran over budget or fell behind schedule [5].
Bloor Research’s own data-migration-specific survey found a comparable pattern years earlier. 38.3% of projects either overran schedule or were aborted outright, at an average overrun cost of $268,000 per project [6].
Neither figure describes strangler fig migrations specifically, but together they corroborate the pattern described here. The data side of a phased migration carries real, measured risk of its own, and it’s the same execution gap legacy data platform modernization work runs into even without a code migration attached to it.
Find the Seam Before It Stalls the Migration
A $0 Modernization Assessment identifies where undocumented business logic and data dependencies are most likely to stall a strangler fig migration, mapped before the project is scoped rather than discovered after it stalls.
How Does Legacyleap Modernize Code and Data Together?
Legacyleap is a Gen AI-powered legacy application modernization platform built on multi-agent orchestration. It is built around the exact gap this piece has described, where code and data get treated as one migration instead of two.
The Assessment Agent produces a dependency map spanning the application code and the data layer as a single system.
The Documentation Agent reconstructs business logic and schema-level meaning as one connected picture. This is the comprehension phase described above, done across both sides of the seam rather than as two separate efforts.
The Modernization Agent then executes the facade-side and data-side changes as diff-based, human-reviewed pull requests, with roughly 70% of the transformation work automated and engineers reviewing the rest.
The QA Agent runs continuous parity validation between the legacy and modernized systems. This is the reconciliation phase described above, made a standing, automated part of the migration instead of a one-time manual check squeezed in before cutover.
All of it runs entirely inside the customer’s own environment, with no source code leaving their infrastructure.
What Makes a Strangler Fig Migration Succeed?
The facade and routing mechanics of the strangler fig approach are close to a solved problem. Every credible guide to the pattern already gets them right, and there is little left to add there.
What is not solved, for most teams attempting this pattern, is the seam between the code migration and the data migration underneath it. Legacy comprehension and reconciliation are the two phases that seam depends on.
Both deserve the same planning rigor as the routing layer, scheduled on both sides of the seam from the start of the project.
Map the Code Seam and the Data Seam Together
A $0 Modernization Assessment maps a legacy application’s code dependencies and data flows together before a strangler fig migration starts, at no cost and entirely inside your own environment.
FAQs
Look for a piece with a clear boundary and a low blast radius if something goes wrong, rather than the piece causing the most pain today. A comprehension pass across both code and data is what makes that boundary visible instead of guessed at.
It applies, with one adjustment. A mobile client’s compiled code can’t be intercepted by a facade the way a backend service can, so the routing decision moves to the API layer instead, with the client calling the old or new endpoint based on a feature flag or a phased app store rollout.
No. Blue-green deployment switches all traffic between two complete, already-finished environments at once. A strangler fig migration runs old and new side by side for an extended period while individual pieces move over gradually.
Individual pieces can, since the facade can route a specific function back to the legacy system without touching anything else. That only works if the data those pieces touch was already kept in sync in both directions, planned into the migration from the start.
No. It’s commonly used for monolith-to-microservices migrations, but the pattern itself only describes how to route and cut over incrementally. The target architecture on the other side of the facade can be microservices, a different monolith, or anything else.
When the facade has nothing left to route to the legacy system, and the reconciliation checks that were comparing the two systems have nothing left to compare. Removing the facade before both of those are true just hides an unfinished migration instead of finishing it.
References
[1] Martin Fowler. StranglerFigApplication
[2] Microsoft Azure Architecture Center. Strangler Fig pattern
[3] Martin Fowler. Patterns of Legacy Displacement
[4] GitHub. scientist
[5] ISG research, reported in The Register. Most SAP migrations bust budgets and project timelines, research finds
[6] Bloor Research data migration study (2011), cited in Curiosity Software. The Research Is Clear: Too Many Migration Projects Fail
