Cloud-Native Core Banking Migration: The 2026 Playbook

A cloud native core banking migration is not really a technology project. It is a multi-year programme to move every customer, every balance and every overnight batch off a ledger that has been running, in some cases, since before the engineers maintaining it were born — and to do it without a single customer noticing. The banks getting this right in 2026 have arrived at a quiet consensus on the how: stand up the new core alongside the old, prove it on a narrow segment, and move customers across in cohorts. Greenfield-and-migrate has beaten the big-bang cutover, and the gap is widening. This is the playbook for the transformation lead who has already won the budget argument and now has to deliver.

The why of cloud core banking is settled. We have written separately on the economics and the regulatory tailwinds driving the wave. This piece assumes you are past that debate. The hard part was never the business case. It is the execution — and execution is where most core migrations have historically gone to die, taking careers and reputations with them.

What is a cloud-native core banking migration?

A cloud-native core banking migration is the replacement of a bank's system of record — the ledger that holds account balances, posts transactions, calculates interest and runs the end-of-day batch — with a platform built to run natively on public cloud infrastructure. The distinction matters. Lifting a 1990s mainframe core into a virtual machine on AWS is not a cloud-native migration; it is a relocation. A genuine cloud-native core is API-first, microservices-based, horizontally scalable and configured rather than hard-coded. Thought Machine's Vault, Mambu, 10x Banking and Tuum were all designed this way from the first commit, not retrofitted toward it.

The reason this is the hardest programme in banking is the nature of the asset being moved. The core ledger is the one system where a bug does not mean a degraded experience — it means money is wrong. Balances must reconcile to the penny across the cutover boundary. Decades of accreted business logic, much of it undocumented, has to be either reproduced or deliberately retired, and someone has to decide which. And it all has to happen while the existing bank keeps running, because you cannot ask customers to stop banking for six months while you re-plumb the foundations. A retailer can close for a refit. A bank that holds a customer's salary cannot.

That combination — irreversible correctness, hidden complexity, zero downtime — is what separates a core migration from every other piece of transformation work a bank attempts. Channel rebuilds, mobile-app rewrites, even payments modernisation are recoverable if they wobble. The ledger is not. Get it wrong in front of customers and the failure is immediate, visible and regulated.

The three migration patterns, and why two of them lose

There are essentially three ways to replace a core. The first is the big-bang cutover: build the new system, run it in parallel for a while, then flip every customer across in a single weekend. The appeal is obvious. One date, one decommissioning, no awkward period of running two cores at once. The problem is equally obvious in hindsight. The blast radius is the entire bank. TSB's 2018 migration onto Sabadell's Proteo platform is the cautionary tale every UK transformation lead can recite — a weekend cutover that left a large share of the bank's customers unable to reach their accounts online and triggered a remediation that ran for years. The big-bang asks you to be perfect on a single irreversible date. Banks are not perfect on single irreversible dates.

The strangler-fig pattern is borrowed from application modernisation, and on paper it looks like the grown-up answer. You wrap the old core behind a routing layer and progressively divert individual capabilities — savings, then term deposits, then unsecured lending — to the new platform, strangling the legacy core function by function until nothing routes to it. It is elegant in theory and brutal in practice for a ledger. Splitting a single customer's relationship across two systems of record creates reconciliation seams everywhere, and the routing-and-synchronisation middleware you build to manage it becomes a second piece of critical infrastructure you now have to maintain forever. Strangler-fig works beautifully for the channels and the middle tier. For the ledger itself it tends to produce a permanent, expensive halfway house that nobody can quite afford to finish.

Greenfield-and-migrate is the third pattern, and the one that has quietly won. Stand up a clean new core on the cloud-native platform, get it regulated and production-ready as a real bank in its own right, then move customers across in deliberate cohorts. Each customer lives wholly on one core or the other, never split. The blast radius of any given migration event is one cohort, not the whole book. That single property — partitioned, sequenceable risk — is why it wins, and why the most experienced transformation leads now reach for it by default rather than treating it as the cautious option.

Why greenfield-and-migrate beat the big-bang

Reversibility is the decisive advantage. In a cohort migration, if something looks wrong after you move ten thousand customers, you have moved ten thousand customers — not nine million. You can pause, diagnose, and if necessary roll a cohort back before the next wave. The big-bang offers no such off-ramp; once the weekend flip is done, your only path is forward through whatever has broken, under maximum customer and regulatory scrutiny. Risk that can be partitioned and sequenced is risk you can actually manage. Risk concentrated into one irreversible event is risk you can only pray about.

The pattern also lets the new core earn trust incrementally. The standard move is to launch the greenfield platform first as a new product or a new brand — a savings proposition, a digital sub-brand — so it carries real customers and real money before you point the back book at it. JPMorgan did exactly this with Chase UK on Thought Machine's Vault, building a clean cloud-native retail bank that proves the platform at scale without betting the existing franchise on it. Goldman Sachs's Marcus consumer business and a long list of digital sub-brands followed the same logic. By the time the back-book cohorts start moving, the platform is not a science project. It is a production bank with a track record the regulator has already seen, staffed by people who have already run real incidents on it at three in the morning.

There is a cost to this approach, and it is honest to name it. You run two cores in parallel for an extended period — often years — and you pay for both, plus the synchronisation and reconciliation tooling that keeps balances consistent across the boundary during the migration window. Finance directors hate the double-run line item, and they are right to interrogate it. But the alternative cost — a botched big-bang, the remediation, the regulatory penalties, the customer attrition, the reputational damage that outlasts all of it — is both larger and far less predictable. Greenfield-and-migrate converts a catastrophic tail risk into a manageable, budgetable operating expense. That is a trade most boards take once it is framed honestly, because boards can plan around a known cost in a way they cannot plan around a low-probability disaster that ends careers.

The vendor field: who builds the new core

Four platforms dominate the cloud-native core conversation in 2026, and they are not interchangeable. Thought Machine's Vault sits at the high-configurability end. Its smart-contract model lets banks express product logic as code, which gives tier-one institutions the control they want — and demands the engineering maturity to use it. The Lloyds, Chase UK and Standard Chartered associations have made it the default choice for large, complex transformations where the bank intends to own deep product customisation and has the platform-engineering organisation to back that ambition. Vault rewards banks that treat their core as a software product. It punishes banks that hoped to buy their way out of building one.

Mambu takes the opposite philosophical stance: composable, SaaS-delivered, configuration over code. Its appeal is speed to market and a lower engineering burden, which has made it the workhorse for fintechs, lenders and tier-two banks who want a capable core without standing up a platform-engineering organisation to run it. The trade is control — you accept the platform's opinions in exchange for not having to hold so many of your own. For a great many institutions that is exactly the right bargain, and Mambu's spread across challenger banks and specialist lenders reflects it.

10x Banking, founded by former Barclays chief executive Antony Jenkins, pitches itself explicitly at the tier-one back-book migration problem — meta-core architecture, a strong data layer, and a deployment model aimed at incumbents rather than greenfield challengers. Its Westpac mandate in Australia is the reference point, and the pitch is unusually candid about who it is for: not the challenger standing up a clean book, but the incumbent that has to move millions of legacy customers off a mainframe without a TSB on its conscience. Tuum, the Estonian platform, has grown quickly across Europe with a modular core spanning accounts, lending, payments and cards, positioned for banks and fintechs that want to adopt modules independently rather than swallow a monolith.

Underneath all four sit the hyperscalers, and the vendor choice and the cloud choice are now coupled decisions rather than independent ones. Vault has a deep Google Cloud relationship, much of the market runs on AWS, and a meaningful contingent — especially banks already committed to Microsoft 365 and Azure across the enterprise — standardise on Azure. Your regulator will ask pointed questions about concentration risk and exit strategy from whichever hyperscaler you pick, and "we can move if we have to" needs to be a documented, tested capability rather than a sentence in a slide. The cloud decision is a board-level one, not an infrastructure footnote, and treating it as the latter is how programmes end up with an exit plan that exists only on paper.

The blockers nobody puts on the steering-committee slide

Data migration is the one that sinks programmes. A core that has been running for thirty years holds data that has been through multiple system migrations already, carries fields whose meaning is encoded in a retired employee's memory, and contains edge cases — dormant accounts, legal holds, accounts in dispute, products that were withdrawn in 1998 but still have live balances — that no current staff member knew existed. Mapping that ledger cleanly into a new data model is archaeology, not engineering. The realistic answer is that you will spend more of the programme on data profiling, cleansing and reconciliation than on anything else, and the teams that underestimate this are the teams that slip their dates and then slip them again.

The COBOL talent cliff makes the archaeology worse. The engineers who understand the old core's batch logic are retiring, and very few people under fifty are learning the mainframe stack. You are increasingly trying to reverse-engineer undocumented business rules from people who are no longer in the building, or who can be tempted back only on contractor day rates that make the business case wince. This is a genuine argument for moving now rather than later — the institutional knowledge you need to migrate safely is depreciating every year you wait. The longer the legacy core lives, the harder its eventual replacement becomes, which is the rare transformation problem that gets strictly worse with delay rather than merely more expensive.

Regulatory approval is the third blocker, and it is not a rubber stamp on a core migration. The PRA, the FCA and their international equivalents will want to see your migration plan, your rollback plan, your parallel-running evidence and your operational-resilience case before you move a single retail customer. This is where your RegTech stack and your operational-resilience tooling stop being a compliance cost and become migration enablers — the audit trail, the reconciliation evidence and the change-management records are exactly what the supervisor asks for. Parallel running, where you post every transaction to both the old and new cores and reconcile the outputs daily, is the single most persuasive piece of evidence you can hand a regulator. It is also expensive and slow. Budget for months of it, not weeks, and treat the first reconciliation breaks as the most valuable bugs you will ever find — because finding them in parallel run is the entire point of running in parallel.

A phased playbook a transformation lead can actually run

Start with foundations, not features. The first job is platform selection, hyperscaler selection and standing up the new core as a regulated, production-grade environment running absolutely no customers. The deliverable is a bank that works and holds nobody's money — boring, complete, and able to pass its own independent operational-resilience and security assurance before a single account touches it. Resist every temptation to begin customer migration early. A new core that is not yet trustworthy on its own merits is not ready to receive an account, and the pressure to skip this gate is precisely the pressure that produces the disasters.

The proving ground comes next: launch a real product on the new core. A new savings account, a digital-only sub-brand, a fresh lending proposition — something that carries genuine customers and genuine money but starts from zero, so there is no back-book risk. This is where you debug the operational reality that no test environment surfaces: reconciliation, statementing, interest accrual, the overnight batch, fraud and AML integration, the call-centre workflow when a real customer rings up confused. Use this stage to wire the new core into your real-time decisioning too; modern platforms are where AI underwriting and instant decisioning finally have a ledger fast enough to keep up. Everything you learn here, you learn cheaply, because the population is small and entirely new — nobody's thirty-year banking relationship is on the line while you find out your statement-generation logic rounds interest the wrong way.

Only then do you migrate the back book in cohorts, and the sequencing is a risk-management decision rather than an operational-convenience one. Move your simplest, lowest-risk customers first — single-product, dormant or low-activity accounts — and use them to build the migration factory: the extract, the transform, the load, the reconciliation, the cutover runbook, the rollback procedure. Each wave makes the factory more reliable, and the metric that matters is not speed but the falling rate of reconciliation breaks per cohort. Save the complex relationships — multi-product households, business banking, accounts with legal encumbrances — for last, when the machinery is proven and the team has run the drill fifty times. Run parallel posting throughout, reconcile every cohort to the penny before you call it done, and keep a rollback path live for each wave until the next one starts.

The stage programmes forget to plan and then never finish is decommissioning. The old core does not switch itself off the day the last customer leaves. There are regulatory data-retention obligations, downstream systems still reading from legacy interfaces, and reporting pipelines wired into the mainframe in ways nobody fully mapped. Decommissioning is a project in its own right, and the savings that justified the whole programme do not materialise until it is finished. A migration that leaves the old core running indefinitely has not reduced cost — it has doubled it. Plan the funeral before you plan the move, and put a named owner and a hard date on the switch-off, or it will quietly become the line item that never dies.

Cohort design is the decision that quietly decides everything

The single most consequential decision a transformation lead makes is not the vendor or the cloud or even the migration pattern. It is the cohort design — how you slice the customer book into waves whose risk you can actually reason about. Get the slicing right and every other problem becomes bounded and recoverable. Get it wrong and even greenfield-and-migrate degrades into a series of small disasters, each one eroding the regulator's patience and the board's nerve a little further.

Good cohort design treats customer complexity, not customer count, as the unit of risk. A wave of two hundred thousand single-product savers is a smaller risk than a wave of five thousand customers with overdrafts, standing orders, joint accounts and a complaint open with the ombudsman. The instinct to migrate by branch, by region or by account-number range is an operational convenience that ignores the only variable that matters — how badly a given customer breaks if the migration mishandles their edge case. Slice by risk profile, validate the factory on the boring cohorts, and you spend your hardest reconciliation problems on the smallest, most carefully watched waves rather than discovering them at scale.

The banks that will be live on cloud-native cores in 2028 are the ones treating cohort design as the central engineering problem in 2026, and staffing it accordingly — with the people who understand the old ledger's edge cases sitting next to the people building the new one, while both groups are still in the building. The window to do that is closing as the mainframe generation retires. The migration that looks merely difficult today becomes materially harder with every year the institutional memory walks out the door, and that, more than any vendor pitch, is the clock the transformation lead is really racing.