Core Banking Renewal — The Migration Everyone Postponed Meets the Decade That Won’t Wait
We are fluent in building the new. We are far less fluent in decommissioning the old — because decommissioning is an act of institutional nerve, not engineering.
The Postponement That Worked — Until It Didn’t
When the operational resilience deadline passed in March, it confirmed what many chief technology officers across the UK banking sector already knew but had not yet said plainly to their boards: the platforms on which their institutions depend — some dating to the late 1980s, maintained by engineers now approaching retirement — are the single largest concentration of operational risk they carry. The mapping exercises demanded by the regulators did not create this reality; they illuminated it.
Across the Channel, the picture is no more comfortable. The Digital Operational Resilience Act, now in force, requires a level of ICT risk management and third-party oversight that legacy architectures were never designed to support. European banks face the same uncomfortable arithmetic: the systems that process current accounts, calculate interest, hold the ledger, and settle payments are running on technology stacks whose original designers have long since left the industry.
The postponement was not irrational. For twenty years, the calculus was defensible: the risk of replacing a functioning core was existential — a botched migration could bring down a bank — while the cost of keeping it was merely expensive. The old platform worked. It processed transactions, it settled overnight, it produced regulatory reports. Its limitations were accommodated by decades of workaround: middleware layers, tactical integrations, shadow systems maintained by teams who understood the quirks. The cost was hidden in operational overhead, and the overhead was tolerable.
That calculus has now been overtaken by three converging forces, and no amount of further accommodation will restore it.
Three Forces That Closed the Window
The first is competitive. Cloud-native entrants to the UK and European markets — the digital banks, the payments firms, the embedded-finance providers — operate from a fundamentally different cost base. Their core banking is a set of services that can be deployed, scaled, and modified independently. Their cost-to-serve a current account is a fraction of what an incumbent carries, not because they are cleverer but because their technology was designed in the era of elastic infrastructure and real-time processing. The incumbents’ cost disadvantage is structural, not operational, and no efficiency programme applied to the existing stack will close it.
The second is regulatory. The operational resilience framework in the UK and the Digital Operational Resilience Act in the EU both demand that firms demonstrate — not merely assert — their ability to remain within impact tolerances during severe disruption. For institutions whose core platforms are monolithic, tightly coupled, and documented in the institutional memory of a shrinking number of specialists, this is not a compliance exercise that can be satisfied with better disaster-recovery testing. It is an architectural question. The regulators are not yet mandating replacement, but they are mandating a standard of resilience that legacy architectures struggle to evidence.
The third is capability. The current wave of machine-learning adoption in financial services — from credit decisioning to anti-money-laundering to customer interaction — requires data availability, event-driven integration, and real-time processing that batch-oriented mainframe architectures cannot provide without extensive and fragile intermediation. A bank that wants to deploy advanced analytics against its transaction data cannot do so effectively when that data is locked inside an overnight batch cycle and accessible only through screen-scraping or bespoke extract routines. The new capabilities do not attach to the old platforms.
Each force alone might be manageable. Together, they constitute a structural shift that makes continued deferral a strategy of diminishing viability.
The Pattern Debate Is Seductive — and Secondary
The industry’s response has been to debate migration patterns with an intensity that, while understandable, misplaces the emphasis. Three broad approaches dominate the conversation:
- Big-bang replacement — the old platform is switched off and the new one switched on over a carefully planned weekend or migration window.
- Progressive hollowing — products and functions migrate incrementally to a new platform while the old one is gradually retired, service by service.
- Greenfield beside legacy — a new bank or division is stood up on modern technology alongside the legacy institution, with customers migrated over time.
Each has produced conspicuous failures, and the failures have been instructive. Big-bang migrations have delivered catastrophic outages when the new platform encountered conditions the test environment did not replicate. Progressive hollowing has created prolonged periods of dual running, with the cost and complexity of maintaining two platforms simultaneously eroding the business case that justified the migration. Greenfield builds have launched successfully but then failed to attract sufficient migration from the legacy book, leaving the institution running two banks at the combined cost of both.
The pattern chosen is less decisive than the way it is executed. Institutions that failed with big-bang would likely have failed with progressive hollowing — because the failures were rooted not in the architectural approach but in the organisational disciplines surrounding it.
None of these patterns is inherently superior, and none is inherently doomed. The honest assessment is that each suits different institutional circumstances — big-bang where the product set is relatively contained and the testing discipline is exceptional, progressive hollowing where the product portfolio is complex and the coexistence engineering is strong, greenfield where the existing franchise can tolerate running two platforms while the new one builds scale. The choice of pattern is a legitimate technical and strategic decision. But it is not the decision that determines whether the programme completes.
The Three Disciplines That Distinguish Survivors
What separates the institutions that have navigated core renewal from those that have not is the presence of three disciplines, none of which is technical in the narrow sense.
Migration as the product
The first is treating the migration itself as the product — not as a side-effect of building the new platform, and not as an infrastructure project that runs in the background while the business continues as before. In every failed migration I have observed, the migration workstream was subordinate: a technical delivery team handed a target architecture and a deadline, while the real attention and investment went to the new platform’s features and capabilities. The migration was the unglamorous work — data cleansing, integration mapping, reconciliation logic, cutover rehearsal — and it was consistently under-resourced and under-led.
In the institutions that succeeded, the migration was the primary delivery. It had its own product owner, its own roadmap, its own definition of done. The new platform’s feature set was constrained by what the migration could absorb, not the other way around. This is counterintuitive — the whole point is the new platform — but it reflects a truth that recurs across complex transformation programmes: the value of a new core is zero until the old one is gone, and the old one does not leave unless the migration is treated as the most important thing the programme does.
Coexistence designed for years, not months
The second discipline is designing coexistence to endure — not as a temporary state to be tolerated, but as a deliberately engineered operating model. Every migration, regardless of pattern, involves a period in which old and new platforms operate simultaneously. In the failed programmes, this coexistence was treated as a transitional phase to be shortened: the architecture was expedient, the reconciliation was manual, the customer experience was inconsistent, and the operational cost was accepted as temporary overhead.
The survivors designed their coexistence layer with the assumption that it would run for years — because it will. Even the most aggressive migration timelines for a retail bank with millions of accounts stretch across two to four years once the reality of product complexity, regulatory approval, and customer communication is absorbed. An institution that builds its coexistence architecture to last eighteen months and then discovers it needs thirty-six is in serious difficulty: the tactical integrations degrade, the dual-running costs compound, and the programme loses credibility with the board.
Designing for endurance means investing in automated reconciliation between old and new ledgers, building a routing layer that can direct any product or customer cohort to either platform without manual intervention, and maintaining a single operational view that spans both. It means accepting higher upfront cost in exchange for a coexistence layer that does not become the programme’s greatest vulnerability.
The courage to decommission
The third discipline is the most difficult: the willingness to decommission the old platform. This is where the majority of stalled programmes are stuck — not in building the new, but in switching off the old. The reasons are understandable: residual products that were never migrated, regulatory reporting that still runs from the legacy ledger, operational processes that depend on the old system’s idiosyncrasies, and — most powerfully — the institutional fear that something critical has been overlooked.
A new core running beside an undying old one is not transformation; it is cost duplication with a modernisation narrative.
We are fluent in building the new. We are far less fluent in decommissioning the old — because decommissioning is an act of institutional nerve, not engineering. It requires someone to accept the residual risk that the new platform will handle the edge cases the old one absorbed silently, and it requires the organisation to commit to a date beyond which the old platform will not be available, regardless of the remaining uncertainties.
The programmes that have completed this journey set their decommissioning date early — not as an aspiration but as a constraint that shaped every decision the programme made. Products that could not be migrated were retired rather than accommodated. Processes that depended on legacy idiosyncrasies were re-engineered rather than replicated. The decommissioning date was the forcing function, and without it, the programme would still be running.
The Decade Will Not Wait
The strongest objection to acting now is the one that has always carried weight: the risk of failure is enormous, the precedents are mixed, and the existing platform still works. This objection deserves to be taken seriously, because it is not wrong — it is merely incomplete. The risk of failure is real. But the risk of inaction is no longer hypothetical. It is visible in the cost-to-income ratios that diverge year on year between incumbents and digital entrants, in the regulatory findings that identify legacy technology as a systemic vulnerability, and in the capability gap that widens each quarter as data-intensive applications reshape what customers and regulators expect a bank to do.
The choice is not whether to renew the core. It is whether to do so with the disciplines that give the programme a credible chance of completion — or to begin another initiative that stalls at the coexistence phase, accumulates cost, and is quietly shelved when the next leadership team arrives.
The pattern is a technical choice. The disciplines are an organisational commitment. And it is the commitment, not the architecture, that determines whether the migration completes.