How to execute a core banking migration: data, dependencies, and the mindset shift

Summary

• Data migration is almost always the most underestimated workstream. Legacy stacks rarely have a single source of truth. Deposits, lending, and product logic often sit in separate systems with different data models.

• Dependency mapping is not just a pre-migration task. Many integrations are not fully visible until migration is underway. Treating discovery as a one-time exercise is one of the most common causes of scope overruns.

• GenAI has materially changed the unknowns equation. What once took six months to map can now be done in under eight weeks.

• The best migrations ask the right business question first. Not "what system do we want to replace?" but "what business model do we want to emerge with?"

• Culture is the deciding factor. Institutions that succeed have shifted from treating technology change as a once-every-five-years event to treating continuous evolution as the operating model

There is a persistent belief in banking that core migration is a career-ending risk. It is understandable: the industry has accumulated enough failed transformations to justify caution. But that belief is increasingly out of date, and so are most of the published guides on core banking migration best practices.

 

In a recent webinar hosted by 10x Banking, part of a series on how to approach core migration, three practitioners with direct experience of live programmes shared what has actually changed, what remains genuinely hard, and what separates programmes that succeed from those that stall.

 

 

Their answers cover terrain that most frameworks skip: the data problem, the dependency mapping challenge, and the cultural question that sits underneath both.

 

The shift is partly about tooling. Artificial intelligence now allows organisations to reverse-engineer legacy code and infrastructure at a pace that was not previously possible. 

 

Andrew Ng, Head of Payments and Embedded Finance at Tungsten Automation, described mapping one of Tungsten's own legacy platforms in under eight weeks using modern AI capability. 10x also partners with organisations like Tweezr, enabling clients to gain visibility into legacy environments with deterministic AI.

 

That matters because the risk in core migration has always been rooted not in what banks know, but in what they do not. Incomplete integration maps and undiscovered data exceptions have historically turned well-run programmes into problems at cutover. Modern AI removes much of that uncertainty before commitment.

 

But tooling is only part of it. The other shift is in how the industry approaches migration itself. The "very important weekend" model, where a bank ends Friday on its legacy system and starts Monday on a new one, has been replaced by controlled approaches that distribute risk over time. Coexistence, parallel run, phased migration: these are now tried and tested playbooks, not theoretical alternatives.

 

 

 

For a detailed breakdown of the four migration approaches and the decision factors for each, see our article on core banking migration strategies: choosing the right path to a 4th-generation platform.

 

When practitioners are asked what most commonly causes core migration programmes to fall behind, data emerges consistently. Not technical debt in the abstract – the specific challenge of understanding where data actually lives and what it means.

 

"There isn't typically one single source of truth within these organisations," said Lewis Ide, SVP APAC at 10x. Legacy stacks tend to hold deposit data in one system, lending data in another, product logic somewhere else again. Different databases, different data models, different contextual rules governing how each is used. When you try to bring these together, the fit is rarely clean.

Before migration begins, a bank needs clear answers to three questions about its data:

 

That third question is frequently overlooked. "There's typically a huge amount of legacy back book products that get migrated across because they've always been there," said Lewis. Core banking modernisation creates a moment to ask what products the bank wants to offer going forward, not just to replicate what existed.

 

The regulatory dimension adds another layer. Retention requirements (often seven years for transactional data) influence how historical records are handled in the target system. Data that needs to be referenced rather than actively used may be managed differently. These decisions require business and compliance input well before migration begins – they cannot be treated as a downstream handoff.

 

If data complexity is the most underestimated workstream, dependency mapping is the one most likely to be treated as a box to tick rather than a continuous discipline.

 

A core banking system connects to payments infrastructure, channels, KYC, AML, finance systems, the general ledger, data warehouses, analytics platforms, and a range of third-party integrations. Over time, many of those connections have been built without systematic documentation. People leave. Architecture decisions are made without updating records. The result is a web that is almost never fully visible until migration is underway.

 

"Many of these dependencies are not fully visible until the migration actually begins," noted Simon Farmilo, Banking Partnerships Director at GFT Technologies. "Because no one has a complete picture. The documentation is rarely current."

 

 

The practical implication: treat dependency mapping as a continuous process throughout the programme, not a one-time exercise before it begins. Proofs of concept during coexistence are a reliable way to surface edge cases, testing how surrounding systems respond in a controlled environment before they become cutover problems at scale.

 

There is also a harder question worth asking: does each dependency still serve a purpose? Migration creates an opportunity to retire integrations that exist only because of historical inertia. The institutions that come out best are often the ones that use the disruption to eliminate complexity, not just transfer it to new infrastructure.

 

One of the clearest points of consensus across the panel: core banking modernisation is not a technology project that happens to affect the business. It is a business transformation that requires technology to execute.

 

Andrew made the point directly. If the business is not engaged early – with specific clarity on the target product set and the customer experience the organisation is trying to create – the most likely outcome is a technically successful migration that recreates a legacy business model on modern infrastructure. "Large scale technology modernisation is treated as just a technology project, which is fundamentally not a very good idea," he said.

 

Data mapping, dependency management, and product rationalisation all require business input. They cannot be delegated entirely to the technology team. The questions that need business answers are specific:

Getting those answers early shapes every downstream decision. Leaving them until execution has begun means migrating the wrong things at speed.

 

When each panellist was asked for their top factors in successful core banking modernisation, the answers were different in form but consistent in substance.

The common thread: the factors that determine success are largely organisational and cultural, not technical. Technology has improved. The harder constraint is whether the institution is built for continuous change.

 

This pattern is visible in how organisations like West Brom Building Society and Chase UK have approached modernisation – with programme governance and cultural clarity, not just technical selection.

 

The discussion this article draws on covers the full texture of each of these points, including how panellists have navigated them in live programmes. Watch the recording to hear the unedited practitioner perspectives on approach selection, data readiness, and the factors that decide outcomes.

 

 

FAQs

What is core banking modernisation?

Core banking modernisation is the process of replacing or upgrading a bank's core banking system – the technology infrastructure that processes accounts, transactions, products, and customer records – with a modern, cloud-native platform. It encompasses data migration, integration management, dependency discovery, and organisational change, and is typically treated as a multi-year business transformation programme rather than a technology upgrade.

How long does a core banking migration take?

Timeline varies significantly by approach and institutional complexity. Big bang replacements can be completed over a compressed window for simpler environments. Phased migrations at large, complex institutions typically run over several years. While institutions who hollow out the core and are intentional about what they take forward can migrate far faster. Greenfield builds allow new propositions to launch quickly, with full migration of legacy portfolios occurring in parallel over time.

What makes data migration in core banking so complex?

Legacy banking stacks almost never have a single source of truth. Deposits, lending, and product data typically sit in separate systems with different data models and business rules. Before migration, banks must understand where all data lives, what it means in each context, what regulatory retention requirements apply, and what they actually want to carry forward versus retire.

What is the difference between phased migration and a parallel run?

In a phased migration, the bank migrates defined segments of its product or customer base sequentially. In a parallel run, the legacy and new systems operate simultaneously with synchronised data, allowing the new platform to be validated and proven at scale before the legacy system is decommissioned. Both approaches distribute risk over time; the right choice depends on continuity requirements, operational capacity, and regulatory context.

How is AI changing core banking migration?

AI tooling has materially reduced the unknown-unknowns that have historically made migration so risky. Tasks such as reverse-engineering legacy code and mapping integration dependencies, which once took months, can now be completed in weeks. This improves a bank's ability to understand its own estate before committing to cutover. It does not eliminate migration risk, but it changes the information available to manage it.

What is a 4th-generation core banking platform?

A 4th-generation core banking platform is a cloud-native, event-driven, API-first architecture built on microservices. Unlike legacy mainframe or first- and second-generation platforms, it supports real-time data processing, multi-tenancy, and continuous product development without requiring changes to underlying infrastructure. It is designed to enable banks to build, iterate, and scale financial products without rebuilding commodity code. The 10x Banking Platform is a 4th-generation core banking platform.

How should we approach business and technology alignment during migration?

Engage the business before technical planning begins. The target product set, customer experience ambitions, and data rationalisation decisions all require business input that cannot be delegated to the technology team. Without that alignment upfront, there is a material risk of migrating the wrong things – or building a modern infrastructure that runs a legacy business model.