Cloud-Native Core Banking Migration: The 2026 Playbook

A cloud-native core-banking migration is a multi-year programme to move customer records, balances and processing from an existing ledger to a new platform while maintaining service and controls. The right approach depends on the bank's products, legacy estate, regulatory obligations and risk tolerance. This guide explains common patterns and the questions a transformation lead should test against its own programme.

What is being migrated?

The core ledger records balances, posts transactions, calculates interest and supports end-of-day processing. Replacing it is more than moving software to a cloud host: a bank must understand data, product rules, interfaces, operating procedures and control evidence. A cloud-native platform may offer APIs, modular services and configurable products, but those characteristics do not remove the need to prove correctness and resilience for the particular bank.

The highest-risk work is often not the new platform itself. It is the treatment of historic data, edge-case accounts, product rules and downstream dependencies. A credible plan identifies what will be moved, archived, retired or rebuilt, and assigns owners for reconciliation and customer outcomes.

Three migration patterns

Big-bang cutover moves the full population at a defined point. It can shorten the period of dual running, but concentrates change and operational risk. The FCA and PRA's enforcement action on TSB's 2018 migration illustrates the consequences when a major migration does not maintain operational resilience; it should not be used to imply that every single-event migration will fail.

Strangler-style modernisation can progressively move channels or discrete capabilities while a legacy core remains the ledger. This may suit some architecture components, but a bank needs clear ownership, data and reconciliation controls wherever systems coexist.

Greenfield-and-migrate establishes a new platform or product first and can subsequently move customers in cohorts. Keeping a customer relationship on one system of record at a time may simplify some boundaries, while cohorting can support decision gates between waves. It also creates a period of dual running, integration work and ongoing reconciliation. It is an option to assess, not a universal industry default.

What public examples do, and do not, show

10x Banking's Chase UK case study^[1] documents a new UK retail platform and ledger infrastructure supporting Chase's market entry. It is evidence of a greenfield platform example, not evidence that an existing back book was migrated or that one migration method has prevailed across the sector.

Thought Machine's 2018 Lloyds announcement^[2] describes a strategic partnership, testing and an intended development and deployment phase. It does not by itself establish a completed Lloyds back-book migration or make Vault a default choice for large transformations. Similarly, Westpac's 2022 announcement^[3] concerns a multi-year institutional transaction-banking platform using 10x technology, not migration of millions of retail legacy customers.

Vendor materials can explain product positioning, but a partnership or case study is not a substitute for a bank's due diligence. The evaluation should cover functional fit, product configuration, integration, security, resilience, data portability, commercial terms, support model and exit arrangements.

Controls before the first cohort

A migration plan should define its data inventory and target model, reconcile balances and transactions, test interfaces and operational processes, and set explicit entry and exit criteria for each wave. It should also define how the bank will handle customer communication, complaints, fraud operations, statements, interest, regulatory reporting and service continuity.

Parallel running can provide useful evidence where the old and new systems produce comparable results, but the design, duration and scope should follow the bank's products and risks. Rollback must also be designed rather than assumed: post-cutover customer activity can make a simple reversal impractical. Clear decision rights, incident management and customer-remediation plans matter as much as the technical migration runbook.

Sequencing and decommissioning

Cohorts can be selected by product, customer complexity, data quality and operational risk. A bank may start with a bounded population to test its migration factory, then reassess before expanding. There is no universal safe cohort size: the relevant question is whether the bank can explain the population, controls and contingency plan for that wave.

Decommissioning needs its own plan. Legacy data-retention obligations, reporting dependencies and downstream interfaces can remain after the final customer moves. Cost savings should not be assumed until the bank has identified those dependencies, completed the necessary controls and formally retired the old environment.

A decision framework, not a vendor prescription

Cloud-native core banking can be a useful route to modernisation, but the migration pattern and vendor choice are bank-specific decisions. Public examples help illustrate possible approaches; they do not prove a universal winner. A sound programme turns that distinction into evidence: documented data quality, tested controls, measured service performance and governance that can pause a wave when conditions are not met.

Questions for the programme board

Before approving a wave, the board can ask whether source and target populations reconcile, whether critical customer journeys have been tested, whether third parties and downstream systems are ready, and whether incident and customer-remediation owners are named. It can also ask what evidence would stop the wave. A timetable is useful, but it is not a control: the decision to proceed should follow measured readiness rather than a desire to protect a planned date. These questions help turn a technology migration into an accountable operational programme.

Sources & methodology. This analysis uses the FCA/PRA's TSB enforcement notice^[4], the publicly described Chase UK platform^[1], the Lloyds/Thought Machine announcement^[2], and the Westpac institutional-platform announcement^[3]. Each source is used only for the facts it states. Migration patterns are decision frameworks, not evidence that a particular method or vendor will suit every bank. CloudFintech is an AI-assisted publication edited under the standards at editorial standards.

Methodology: CloudFintech constructed a hypothetical programme and allocated costs across seven workstreams. Change the assumptions in the CSV; these values are neither a market benchmark nor a vendor quotation.

Primary sources: FCA and PRA final notices on the TSB migration; Regulation (EU) 2022/2554 (DORA)

Download underlying dataset