Legacy Core Coexistence — Strangler-Fig Pattern in Banking [2026]

Martin Fowler's strangler-fig pattern was named after the tropical vine that grows around an existing tree until the tree is no longer needed. It is the pattern that core banking modernization should have been using for a decade, and finally can — because the two missing pieces have arrived.

This article is for CIOs, Heads of Architecture and program directors actually running a coexistence program in 2026. It is the engineering view of what was set up commercially in Progressive Modernization beats Core Replacement.

What the pattern actually is

In a banking context, strangler-fig means three concrete things:

The new platform handles new traffic from day one. Every new account, every new product, every new origination goes onto the modern core.
The legacy core continues to serve its existing book, untouched, until each cohort is migrated.
An integration layer keeps the two systems consistent at the customer, ledger and reporting boundary — for as long as both are live.

The pattern dies in the third item. Most coexistence programs fail because the integration layer is built as a bolt-on, ages badly, and ends up being more expensive than the cores it bridges. Done well, the integration layer is the most engineered part of the program — not the least.

The two pieces that finally make this viable

For a decade, the architectural case for strangler-fig was clear and the economic case was not. Two shifts changed that:

Headless, API-first cores. The new platform is a set of composable APIs, not a monolithic application. It can accept traffic for some products today without owning the customer record or the ledger of record. That alone is what makes incremental migration economically possible — the old system can stay the system of record while the new system does new work.
Agentic AI orchestration. Reconciliation, exception handling, customer communication during migration and post-migration audit are exactly the workload an agent control plane absorbs efficiently. The "running two cores" cost line was historically dominated by the people needed to reconcile them. Agents collapse that line.

This is why we say strangler-fig is finally viable in 2026 — not because the pattern is new, but because the economics finally support it.

The five layers you need

A working coexistence architecture, from the customer down, has five layers. They look different by tier, but the layers themselves are universal.

Layer 1 — Unified customer surface. The customer never knows there are two cores. Mobile, web, branch and partner-embedded surfaces talk to one front door. Routing decisions happen below the customer's view.

Layer 2 — Intent and routing. A thin layer (often a Customer Agent plus deterministic rules) that decides, for each transaction, which core owns it. New originations route to the modern core. Existing-book actions route to the legacy core. Edge cases are explicit, named, and logged.

Layer 3 — Translation and consistency. The integration layer that translates between the two cores' account models, product codes, transaction types and currency representations. This is where most coexistence programs underinvest and pay for it later.

Layer 4 — The two cores themselves. Legacy core (untouched, runs the existing book). Modern core (runs new traffic, accepts migrated cohorts on a schedule).

Layer 5 — The reconciliation and audit plane. A continuously-running comparison between the two cores' positions for any customer or book that is split across them. This is the layer that proves to your regulator that nothing has fallen between the cracks.

Layers 3 and 5 are what differentiate a working coexistence from a failing one. Both are workloads agentic AI is especially good at — they're high-volume, structured, audit-heavy, and tolerant of being driven by software.

The reconciliation tax — and how agents change it

The single biggest objection to coexistence is operating cost: "we'd be running two cores, paying for two licences and two teams." Most of that cost, looked at honestly, is reconciliation — the people whose job is to make sure account balances, transaction histories and customer records read consistently across both books.

In a manual setup, this is a substantial standing team. The team owns:

Daily balance reconciliations between the two cores
Exception investigations when balances diverge
Customer-record harmonization (same customer, two records, two product portfolios)
Reporting consolidation (regulatory and management reports that must aggregate both books)

An agentic Operations layer absorbs the bulk of this work. Not because it is creative, but because reconciliation is exactly the kind of structured, repetitive, audit-trail-heavy work agents do well. Investigations that used to take a person 20 minutes are resolved in seconds; the genuinely ambiguous cases — which are a small minority — escalate to a human with a complete case file.

This is the lever that changes the economics. The "two cores cost twice as much" framing is replaced by "two cores cost roughly the same as one new core plus an agentic ops layer, for the duration of the migration." On a multi-year horizon, that is a very different cash-flow shape.

Migrating a cohort — what good looks like

A cohort migration is the unit of work. It looks like this:

1. Selection. Choose a cohort with clean data: by product, by segment, by acquisition channel, by geography. Avoid the temptation to mix dimensions ("all SMEs in Italy with deposit and loan products" is two dimensions; pick one).

2. Data lift and harmonization. Extract the cohort's data from the legacy core. Reconcile it against the modern core's data model. Resolve ambiguities — and where ambiguities can't be resolved by software, hand them to a named human reviewer with a deadline.

3. Shadow run. For a defined window — usually 30 to 60 days — transactions for the cohort run on the legacy core (system of record) but are replayed on the modern core. Outputs are compared. Any divergence is investigated and resolved.

4. Flip. On a defined date, the modern core becomes the system of record for the cohort. The legacy core stops processing new transactions for that book but retains the historical record.

5. Run-off. The legacy core's portion of the cohort's history is preserved (for the legal retention window — typically 7-10 years depending on jurisdiction). Reads continue against the legacy core for historical queries until the data is fully migrated. Most institutions migrate historical data after the flip, on a slower schedule, to avoid coupling the cutover risk to a data project.

The flip itself is small. The shadow run is what proves the modern core can do the cohort's work. Programs that skip the shadow run are running unplanned outage risk against their existing book.

Governance during coexistence

The regulator-facing question during coexistence is: who is accountable for the customer experience and the audit trail at any given moment?

The clean answer is: one core is the system of record for any given customer at any given time. The Customer can't be partly on one core and partly on another. The integration layer's job is to make this look seamless to the customer, but never to fuzz it for the regulator.

The complete answer includes:

A documented data-ownership map: every customer record, every account, every product line is owned by one of the two cores at any given moment.
A continuous reconciliation report that demonstrates this is true — not just policy.
An incident playbook that names which core, which team and which agent is on point for any given failure mode.
Internal audit visibility into both cores and the integration layer.

This governance posture is what differentiates a coexistence program a regulator can sign off on, from a coexistence program that creates supervisory questions during inspection.

The end-state — and how you know you've reached it

The end state of a strangler-fig modernization is not "the legacy core is turned off." That is a side-effect. The actual end state is:

100% of new originations on the modern core
100% of customer-facing surfaces talking to the modern core
The legacy core serving historical reads only, on a wind-down schedule
The reconciliation plane reporting zero structural divergence

Once those four are true, switching the legacy core off is an operations decision, not a transformation decision. We've seen institutions sit in this state for 12+ months before turning the legacy core off — and that's fine. The transformation finished when the customer experience finished. The decommissioning is administrative.

Where CoreFi sits in this pattern

CoreFi is built to be the modern core in a strangler-fig coexistence. The platform exposes the API surface to be installed alongside a legacy core, is built around an Operations Agent and audit plane designed to absorb the reconciliation tax, and supports the cohort-by-cohort migration cadence described above. The Compliance Agent maintains the regulator-facing artefact set throughout the coexistence — designed to align with DORA's operational resilience expectations, with final positioning depending on your jurisdiction and licence.

We don't sell a destination. We sell the modern half of a coexistence that ends on your schedule.

See the dedicated pattern page: CoreFi Migration & Coexistence.