A core banking migration is the process of moving an institution's accounts, products, and transaction processing from a legacy or existing core onto a new platform, without disrupting live banking operations. Historically, this meant rebuilding the bank in parallel and attempting a single cutover, concentrating all the risk into one moment. Modern architectures allow institutions to decouple components and migrate in controlled stages instead.
That shift changes what "risk" actually means for a migration programme today.
The risk profile has shifted, not disappeared. As Mark Jenkinson, EMEA GTM UK Banking Lead at AWS, puts it: "The risk for many banks is no longer modernising, it's delaying. Organisations that remain tied to batch-based architectures and legacy infrastructure will increasingly struggle to compete with cloud-native banks that can move faster and innovate more easily."
Once the risk framing shifts, the next decision is which execution model actually fits your institution.
We reached an inflexion point where the cost of getting our existing systems to where we needed them to be was an order of magnitude beyond what we were willing to invest, especially given they were already over 40 years old.
Tim Eddy, Managing Director, Real-Time Treasury Platforms & Transformation at Westpac
Inside the playbook: the industry debate on whether "big bang" migration is making a comeback now that dependencies can be fully understood upfront, and what that means for institutions weighing their approach.
Watch now: How to execute a core banking migration
There's no single best approach. The right model depends on your organisation's complexity, risk appetite, and strategic priorities, weighed across four options: big bang (fast, concentrated risk), parallel run (continuity-first, distributed risk), phased (the most common approach in large institutions), and greenfield build (for new digital propositions). In practice, most institutions run some form of coexistence between old and new systems as the default, not the exception.
Whichever approach is chosen, the same underlying risk shows up in a different place: not in the systems, but in the data that moves between them.
Inside the playbook: a direct comparison of all four approaches against speed, risk profile, and operational complexity.
Read more: Core banking migration strategies: choosing the right path
Years of customisation leave edge cases buried in the data, and they rarely surface until mapping and testing are already underway.
Most migration issues don't come from what you plan for, they come from what you didn't know was there. Years of customisation create edge cases that only surface when you start to map and test properly.
Andrew Ng, Head of Payments and Embedded Finance at Tungsten
Trust in the new system is built at the validate-and-test stage, not at go-live, and migration doesn't end at cutover.
That same discovery and testing work is exactly where AI is starting to change the pace of migration programmes.
Inside the playbook: the six-stage data migration lifecycle (discover, understand, clean and simplify, map and transform, validate and test, synchronise and operate) and where institutions most commonly underestimate the effort required.
Read more: The legacy system data migration problem banks still underestimate
AI can classify and profile data at scale, identify duplicated or inconsistently used fields, and surface hidden dependencies and embedded business logic, work that previously took months and can now be completed in days. Andrew Ng says: "The real shift with AI is not just speed, it's visibility. When you can properly map the current state, you can test with confidence. And once you can test with confidence, you fundamentally change the risk profile of migration." It doesn't remove the need for governance and control, it raises the standard both need to meet.
Inside the playbook: where AI is already being used in live migration programmes today, and the governance guardrails that keep it safe at scale.
Watch now: how AI changes core banking migration
A practical guide to successfully migrating to a 4th-generation core banking system. Fill in your work email below and receive the report directly in your inbox.
Moving an institution's accounts, products, and transaction processing off a legacy or existing core onto a new platform, without disrupting live operations. Modern architectures let institutions decouple components and migrate in controlled stages instead of a single high-risk cutover.
There isn't one universal answer. The right model is chosen from four approaches, big bang, parallel run, phased, or greenfield build, based on your organisation's complexity, risk appetite, and strategic priorities. Phased or coexistence-led approaches are the most common in large institutions.
Data, not systems. Migration issues rarely come from what's planned for, they come from what wasn't known was there: years of customisation create edge cases that only surface once mapping and testing begin in earnest.
A six-stage lifecycle: discover, understand, clean and simplify, map and transform, validate and test, then synchronise and operate. Most institutions underestimate the discovery stage, which is why hidden dependencies and edge cases tend to surface late rather than early.
Rarely for technical reasons. The most common failure points are poor data quality, underestimated dependencies, weak alignment between business and technology teams, and insufficient governance. Executive alignment and disciplined scope control consistently separate the programmes that succeed.