Modernize without disruption: the strangler pattern replaces legacy systems step by step—unlocking AI value early while reducing transformation risk.
The previous two articles framed a choice: modularize the core you have or replace it entirely. In practice, most banks will not make a clean binary decision. They will do both — modularizing what they can, replacing what they must — over a period of years while the bank continues to operate every day.
The architectural pattern that makes this possible has a name. It is called the strangler fig pattern. The strangler fig is a tropical tree that germinates in the canopy of a host tree, sends roots downward, and gradually replaces the host’s structural function until the original tree is no longer needed. The host does not fall. It is slowly, methodically succeeded. There is something honest about the metaphor: legacy systems do not die in dramatic collapses. They die slowly, invisibly, until one day you notice the original structure is gone and something better has taken its place.
In software architecture, the pattern works the same way. New services wrap legacy capabilities, routing traffic progressively from old to new until the legacy system can be decommissioned. Martin Fowler documented the pattern two decades ago. Banks are just now understanding why it matters more than ever.
AI has made the strangler pattern mandatory rather than optional. Banks cannot stop running while they rebuild. But they also cannot wait to start deploying intelligence. The strangler pattern resolves this tension by allowing banks to build AI-ready capabilities one domain at a time while the legacy core continues to operate.
Why the Strangler Pattern Works for AI
The strangler pattern was designed to solve migration problems. It works for AI because AI-ready modernization is fundamentally a migration problem — migrating from an architecture that cannot support intelligence to one that can, without disrupting the operations that keep the bank alive.
What makes the pattern specifically effective for AI is the requirement that each new service must be built with AI-ready principles from day one. When a bank wraps the legacy payments capability with a new payments domain service, that service must publish events. It must expose clean APIs. It must adopt the enterprise data ontology discussed in earlier articles. It must be observable, auditable, and independently deployable.
Each strangled capability becomes immediately available to the AI layer. The bank does not have to wait for the entire transformation to complete before deploying intelligence. The first domain that gets strangled — often payments or customer onboarding — becomes the first domain where AI agents can operate. The second domain extends the AI surface. By the fifth or sixth domain, the bank has enough AI-ready architecture to support meaningful orchestration across multiple domains.
This incremental expansion of AI capability is the strangler pattern’s most important property. It turns a multi-year transformation into a series of quarterly deliverables, each one expanding what the bank’s intelligence layer can see and do.
The Fatal Mistake: Strangling Legacy With More Legacy
Banks that use the strangler pattern to replace legacy components with new components that are equally opaque to AI have wasted the opportunity. This happens more often than it should.
A bank wraps its legacy loan origination system with a new service. The new service handles the same functions — application intake, credit decisioning, document generation — but it was built as a standalone application with its own proprietary data model, no event publishing, and APIs that were designed for a specific front-end rather than for general consumption. The legacy system has been replaced, but the architecture has not improved. The AI layer still cannot observe loan origination events, still cannot query the domain through clean APIs, and still cannot reconcile loan data with the enterprise ontology.
The pattern is not about decomposition for its own sake. It is about creating, one domain at a time, an architecture that intelligence can operate on. Every new service that replaces a legacy capability is an opportunity to build correctly. Banks that treat these as simple replacement projects rather than architectural modernization projects will find themselves strangling old problems with new ones.
Execution: Where to Start
Domain selection matters more than most banks realize. The first capability to strangle should be one that delivers immediate AI value while carrying manageable migration risk.
Payments processing is often a strong first candidate because it generates high-volume event streams that fraud detection and behavioral analytics AI models can consume immediately. The AI value is visible within weeks of go-live — the fraud team sees transactions in real time for the first time, and the ROI case writes itself.
Customer onboarding is another strong candidate because it touches identity, KYC, and relationship establishment — all domains where AI-powered automation delivers measurable efficiency gains and where the regulatory burden of manual processing is heaviest.
What makes a domain a good first candidate? Three criteria: high AI value, manageable data migration complexity, and limited coupling to other domains. A domain deeply entangled with the core — where extracting it triggers cascading dependencies across the monolith — is not a first move. It is a third or fourth move, after the team has built confidence and the surrounding architecture has matured.
What happens when a bank starts with the wrong domain? We have seen it. An institution chose treasury as its first strangler target because of executive sponsorship. Treasury was deeply coupled to the general ledger, the lending platform, and three downstream regulatory reporting systems. The migration took eighteen months instead of six. It consumed the transformation budget for the year. And it produced no AI-ready capability because the team spent the entire effort managing data dependencies rather than building event publishing and API discipline. The second domain migration, which should have been underway, had not started. The program lost momentum and the executive sponsor moved on.
Start where the value is high and the complexity is low. Build muscle memory. Then take on harder domains with a team that knows what good looks like.
Each domain migration should follow a consistent template: define the domain boundary, adopt the enterprise ontology, build the API surface, implement event publishing, route traffic progressively from legacy to new, validate AI consumption at each stage, and decommission the legacy capability only when the new service has proven itself in production.
A practical execution roadmap for AI-ready core banking transformation, start small, build APIs, route progressively and validate AI at every step.
The Bridge Between Modularization and Replacement
The strangler pattern is how the modularization strategy from the previous articles actually gets executed. It is also the bridge that avoids the binary choice between full replacement and staying stuck. Banks that cannot justify full core replacement today can begin strangling legacy capabilities tomorrow. Each strangled domain reduces the bank’s dependency on the legacy core. When enough domains have been strangled, the remaining core functionality may be small enough that replacement becomes a manageable project rather than a terrifying one.
For banks where replacement is ultimately necessary — where the diagnostic signals from the previous article are present — the strangler pattern is the de-risking mechanism. It ensures that by the time the core cutover happens, the bank has already migrated the majority of its operational capability to new, AI-ready services. The core replacement becomes the last step, not the first.
This is the only approach that works at scale. We have watched banks attempt big-bang replacement without prior strangling — full core conversion in a single program, every domain at once, compressed timeline driven by contract deadlines rather than architectural readiness. The failure rate speaks for itself. Banks that strangle without ever addressing the core take on permanent technical debt. The strangler pattern, executed with AI-ready principles, is the discipline that resolves both.
Banks that strangle without ever addressing the core take on permanent technical debt. Banks that attempt big-bang replacement without prior strangling take on catastrophic risk.
A phased approach to core banking transformation, modularize first, replace strategically and transition to AI-ready services with reduced risk.
What Comes Next
Modularization, replacement, and the strangler pattern all depend on one foundational capability: the integration layer. APIs have been part of banking technology for over a decade, but the stakes have fundamentally changed. When the consumers were mobile apps and partner portals, undisciplined API design was a technical inconvenience. When the consumers are autonomous AI agents making real-time decisions affecting customers, risk exposure, and regulatory compliance, undisciplined API design is an operational risk. The next article examines what API discipline looks like when the consumers are machines, not people.
Where to Start
If your bank is planning a transformation — whether modularization, replacement, or a phased combination — domain sequencing is the decision that determines whether the program delivers early AI value or burns budget on complexity before it produces results.
Core System Partners’ Transformation Readiness Scorecard includes a domain prioritization assessment that maps each banking capability against AI value, migration complexity, and coupling risk — giving leadership teams a clear sequencing recommendation in under an hour.
The strangler pattern works. What kills it is the mistake described in this article — strangling legacy with more legacy instead of with modern, AI-ready components. If your modularization plan still depends on your existing middleware, it is worth a second look.
If your institution is ready to move from awareness to action, visit coresystempartners.com/contact to start the conversation.
Next article in the series: APIs Are Now the Nervous System of Intelligence
Return to: Why AI makes modern core banking architecture non-negotiable
#CoreBankingTransformation #CoreBankingArchitecture
