Strangler Fig Migration Paths for Monolithic Banking Cores
Replacing a Core One Capability at a Time Without a Distributed Mess
The strangler fig pattern is now the default answer to core replacement, and for good reason: big-bang core migrations have a long history of consuming years and being cancelled. Routing traffic through a façade, building new capability behind it, and retiring the old path incrementally is genuinely lower risk and it is also the approach that most often ends in a permanent hybrid.
The hybrid happens because the pattern has three parts and organisations reliably fund the first two. A strangler fig core banking migration that finishes depends far more on seam selection and retirement discipline than on the quality of the new platform.
What does the pattern actually require?
A façade, a new implementation, and genuine retirement of the old path. All three.
The façade routes requests so callers do not know which system serves them. The new implementation takes over capability by capability. And the old path is switched off and removed once the new one is proven. Skip the third and you have two cores, two operational models, two sets of change effort, and a higher cost base than you started with, which is the outcome a surprising number of institutions are living with.
Why is retirement the part that fails?
Because it delivers no new capability, so it loses every prioritisation argument.
Migrating a capability produces something demonstrable. Decommissioning the old path produces a saving that arrives later and a risk that arrives now, so it slips, and the legacy system stays alive because a handful of edge cases still route to it. Fix that structurally: define retirement criteria and a target date when each route is created, report routes not yet retired as a standing metric, and fund decommissioning inside the same business case as the build. The GAO's June 2019 review of critical federal legacy systems found that of ten agencies, only two had modernisation plans containing good-practice elements including a disposition strategy for the legacy system, and three had no documented plan at all. Disposition is exactly the part that goes missing.
How many routes in your façade were meant to be temporary and are now three years old?
How do you choose the seams?
Along capability boundaries with clear data ownership, or by whole product line.
| Seam | Works when | Risk |
|---|---|---|
| By capability, such as payments or notifications | The capability owns its data | Requires clean data boundaries |
| By product line | Products have separable data and rules | Shared customer data still needs a decision |
| By customer segment | Segments are cleanly identifiable and stable | Migration of a customer between segments |
| By geography or legal entity | Entities are already separate | Group-level reporting spans both |
| By channel | Almost never | Both systems end up owning the same accounts |
| By new versus existing business | Strong starting point | Back book eventually still has to move |
Which seam is usually right for a core?
Capability first for peripheral functions, then product line for the ledger itself.
Start by extracting capabilities that own their data and are called by the core rather than intertwined with it: notifications, document generation, limits, fee calculation, screening. Those prove the façade, the deployment model, and the operational pattern with modest risk. The ledger itself is harder and usually moves by product line, because a product's accounts and postings can be made the responsibility of one system. Decomposition patterns and their pitfalls are covered in this guide to microservices migration for monolithic platforms.
Why is splitting by channel a trap?
Because a channel is a caller, not a boundary, so both systems end up owning the same records.
Routing the mobile app to the new platform while branch and telephony stay on the old one sounds like a clean phased rollout and means both systems now write to the same accounts. That is dual authority over shared data, and it produces exactly the reconciliation and ordering problems the pattern was supposed to avoid. Channels should be indifferent to which system serves them, which is what the façade is for, rather than being the axis of the split.
Who owns the data during the transition?
One system per record, always, with the other reading a replica.
| Model | Description | Verdict |
|---|---|---|
| Legacy remains system of record | New platform reads a replica, writes back through the old | Safe, limits new-platform capability |
| New platform becomes system of record per migrated set | Legacy reads a replica | The target pattern |
| Dual write from the application | Both systems written by the caller | Avoid, no atomicity |
| Bidirectional synchronisation | Both write, changes propagate both ways | Avoid, ordering and conflict resolution are intractable |
| One-way change data capture | Owner writes, follower receives changes | Good, with lag understood |
Why is dual write the most common serious mistake?
Because there is no transaction spanning both systems, so partial failure leaves silent divergence.
The application writes to the legacy core, then writes to the new platform, and something fails in between. Now two systems disagree about a balance and neither is authoritative. At scale this happens daily, it is discovered during reconciliation or by a customer, and there is no principled way to resolve it because both writes were equally intended. Use single ownership with one-way propagation, accept the lag, and design consumers to tolerate it. Where a genuine cross-system guarantee is unavoidable, make one system authoritative and treat the other as derived.
How should the façade work?
Routing on a stable key, gradual traffic shift, and a rollback path that does not require a deployment.
Route on something stable such as account, product, or customer identifier rather than on request type, so a given record is always served by the same system and ordering is preserved. Shift traffic gradually with configuration rather than code, keep a tested route back to the legacy path, and log which system served every request so investigation is possible. The façade should be thin: routing, protocol translation, and observability only. Business logic in the façade is how the migration acquires a third system nobody planned, and it is the reason some of these programmes end with the façade as the most complex component in the estate. The gateway discipline is the same as in this guide to using microservices without creating complexity.
How do you avoid building a distributed monolith?
By watching for chatty coupling, shared data, and coordinated deployments.
| Warning sign | What it means |
|---|---|
| Synchronous call chains across three or more services | Latency and failure coupling worse than the monolith |
| Both systems reading and writing the same tables | No real boundary, just added network hops |
| Deployments that must be coordinated | The split is nominal |
| A single business change touching both systems routinely | The seam is in the wrong place |
| New platform calling legacy for every request | You have added a layer, not migrated anything |
| Shared libraries carrying domain logic | Coupling reintroduced through code |
If several of those appear, stop and revisit the seam rather than continuing. A wrongly placed seam does not improve with more services behind it, and the cost of moving it grows with every capability added. This is the failure mode that gives the pattern a bad name, and it is a design error rather than an inherent flaw.
Does a routine product change currently require touching both systems?
How do you keep the legacy system alive but not evolving?
With a formal change position on the legacy estate and an exception process that senior people own.
Every change made to the legacy system after migration starts is work that will be discarded and behaviour the new platform must then replicate. Set the position explicitly: regulatory and defect changes only, everything else goes to the new platform or waits, with exceptions approved at a level that makes them uncomfortable. Without that, the legacy system keeps growing, the new platform keeps chasing, and the migration never converges. This is a governance decision rather than a technical one and it is frequently the single most important control in the programme.
How do you sequence capabilities?
Peripheral capabilities first, then new business, then the back book by product.
| Stage | Scope | Purpose |
|---|---|---|
| Peripheral capability extraction | Notifications, documents, fee calculation, screening | Prove façade, deployment, operations |
| Read-only serving | New platform serves queries from replicated data | Prove data model and performance |
| New business origination | New accounts created on the new platform | Real production without touching existing customers |
| Back book by product | Migrate existing accounts product by product | The bulk of the work, with parallel validation |
| Batch and periodic processing | Accrual, statements, reporting per migrated product | Frequently the hardest part |
| Retirement | Legacy programs and data switched off | The value realisation phase |
Why start with new business rather than migrating the back book?
Because it proves the platform under real conditions without risking existing customers.
New accounts on the new platform give you genuine production traffic, real operational experience, and a growing population whose behaviour you can compare against the legacy population, all without a data migration. It also creates useful pressure: once new business runs on the new platform, the legacy system's future is visibly finite, which helps the organisational side. The trap is stopping there, since a bank running new business on a modern platform and its back book on the legacy one has two of everything indefinitely, which is why the migration sequence for existing accounts must be scheduled and funded up front.
How do you prove correctness through the transition?
By comparing both systems continuously on the same inputs until differences are explained.
Every migrated capability should run against production-shaped traffic with outputs compared to the legacy path before the legacy path is retired, and every migrated product should have its balances and postings reconciled continuously during coexistence. That comparison harness is a first-class deliverable rather than a testing activity, and its design is the subject of parallel runs and dual-ledger validation. Where the underlying logic is also being translated rather than reimplemented, the equivalence discipline in COBOL to Java modernisation applies alongside.
How long does it take, and what kills momentum?
Three to seven years for a full core, with momentum lost to unretired routes and unfunded decommissioning.
Be honest about the duration in the business case, because a programme sold as two years and delivering in five loses sponsorship somewhere in year three, usually just as the hard products come up. Protect momentum by delivering visible value continuously rather than at the end, reporting retirement rather than only build, and keeping the batch and periodic processing work in scope from the beginning, since it is frequently harder than the online path and gets discovered late. Continuous processing work interacts directly here, as covered in eliminating the overnight batch window, and the wider replacement strategy considerations are in this guide to core system replacement.
Which metrics matter?
Routes retired, share of volume on the new platform, legacy change volume, coordinated deployments, and comparison differences.
Report routes retired alongside routes created, since the gap is the honest state of the migration. Track the share of transactions and accounts served by the new platform per product. Measure legacy change volume, which should be falling toward zero and is the best indicator of whether the change position is holding. Count deployments requiring coordination across both systems, as any nonzero number suggests a seam problem. Report comparison differences and unexplained differences during coexistence. And keep the operating cost of running both estates visible, because that number is what makes retirement urgent to people outside engineering. The Basel Committee's Principles for operational resilience, published in March 2021, also make coexistence a resilience question, since two systems serving one critical service doubles the dependency surface until one is retired.
The strangler fig pattern works, and it works when the seams follow data ownership and the old paths actually get switched off. Institutions that route by channel, dual write, or treat decommissioning as a later phase end up with the cost of both architectures and the agility of neither, which is a worse position than the monolith they set out to replace.
Frequently Asked Questions
What does the strangler fig pattern require?
Three things: a façade routing traffic, a new implementation taking over capability by capability, and actual retirement of the old path. The third is the one programmes skip.
Which seam should a core migration follow?
Capability with clear data ownership, such as payments, or a whole product line. Seams that leave two systems sharing authority over the same records create permanent complexity.
Why is splitting by channel a trap?
Because channels are not seams. Routing mobile to the new system and branch to the old leaves both systems owning the same accounts, which means dual authority over the same data.
Who should own the data during transition?
One system per record, always, with the other reading a replica. Shared write authority is the decision that turns a migration into a permanent reconciliation problem.
Why is dual write the most common serious mistake?
Because there is no atomicity across two systems, so partial failure leaves divergence with no arbiter, and the divergence is discovered later during reconciliation or a complaint.
How do you stop the façade becoming permanent?
Set retirement criteria and dates per route when the route is created, report routes not yet retired, and fund decommissioning in the same business case as the build.
What are the signs of a distributed monolith?
Chatty synchronous calls between services, shared database tables, deployments that must be coordinated, and a change that requires touching both systems.
Where should the migration start?
With new business on the new platform rather than migrating the back book, because it proves the platform under real conditions without touching existing customers.
