The Dual-Core Playbook: Running Legacy and Modern Cores Without Losing Control

Most UK banks and building societies will run a legacy and a modern core in parallel at some point in the next decade. The risk is not the complexity itself, it is treating parallel running as a phase rather than an architected state, and letting vendor dependency and fragmentation harden while attention is elsewhere.

1. 01

   Define the end state before you switch on the second core

   A dual-core period is only defensible if the target state is written down. Which products, segments and journeys sit on the modern core in year one, year three and year five, and what has to be decommissioned by when. Without that, parallel running becomes permanent by default and cost quietly doubles.

2. 02

   Draw the boundary of authority, not just the boundary of data

   The hardest question in a dual-core estate is not where the data lives, it is which core is the system of record for a given customer, product or ledger entry at a given moment. Fix the authority boundary per domain, publish it, and enforce it in the integration layer. Ambiguity here is the single largest source of reconciliation risk.

3. 03

   Cap vendor dependency by design, not by hope

   Every new capability added to the modern core deepens the switching cost. Keep customer, product and pricing data in an independent domain model, keep the integration and event layer vendor-neutral, and insist on documented, tested exit paths. Vendor lock-in is not a contract clause, it is an architecture choice made one commit at a time.

4. 04

   Run one operating model across both cores

   Two cores can be tolerated. Two operations teams, two incident processes and two change calendars cannot. Unify observability, incident response, release governance and third-party risk from day one, so the organisation experiences one platform even while the technology is transitional.

5. 05

   Set the sunset trigger before you go live

   The legacy core will only be retired if the conditions for retirement are written down in advance. Volume thresholds, product coverage, cost per transaction, regulatory reporting parity. Agree the triggers with finance, risk and the board before dual running begins, and review them on a fixed cadence. This is what turns a dual-core programme into a migration rather than a state.