Legacy system data migration rarely fails because of the target platform. It fails because of what teams don't know about their own data: years of workarounds, fields repurposed, logic buried where no one thought to look. Cleansing, reconciliation and rigorous testing decide whether a migration is safe to trust on day one, not the architecture.
Summary
Migration is a data problem before it's a system problem. Most risk comes from data no one fully understands, not from the act of moving it.
Legacy data is rarely clean or centralised. It's spread across cores, warehouses and downstream systems, often duplicated and inconsistently owned.
Data breaks two ways in migration: translation issues (formats, field lengths) and conceptual ones (the same concept modelled differently in each system).
AI accelerates understanding, mapping structures and surfacing hidden dependencies, but it doesn't replace the discipline of cleansing, testing and reconciliation.
Migration success is defined by whether the data is trusted on day one.
In this article: What is data quality in core banking migration? · Why migration is a data problem, not a system problem · Why legacy data is never as clean as it looks · What to decide before migrating · The two ways migrated data breaks · Brownfield migration vs a neo-core pivot · Keeping data trustworthy in transition · AI's role · Testing and strategy · What defines success
Data quality in core banking migration means the migrated data is accurate, complete and consistent with the source system, and that its meaning is preserved when it lands in the new platform.
That distinction matters. A field can move without a single value being wrong and still be unusable, because the new system interprets it differently. In practice, this means testing for accuracy, completeness, consistency and referential integrity, and confirming the data still means the same thing in the target system as it did in the one being replaced.
Migration is often framed as a system problem: pick the right platform, plan the cutover, manage the timeline. In reality, it is a data problem.
The systems involved are usually well understood. Vendors document their architecture, and integration teams can map APIs and data models on both sides. What's far harder to pin down is what the existing data actually contains, why it looks the way it does, and what will happen if it's moved as-is. For a deeper look at the operational side of this shift, our companion piece on how to execute a core banking migration covers the dependency mapping and organisational alignment that data work depends on.
Legacy data reflects years of workarounds, exceptions and accumulated complexity, not a clean record of the business as it exists today. Products evolve, processes change, fields get repurposed and logic gets embedded in ways that aren't always visible from outside the system.
It's fragmented, too. Legacy estates typically spread the same information across multiple cores, data warehouses, data lakes and downstream reporting systems. That data is often duplicated, sometimes inconsistent between copies, and not always clearly owned by any one team.
As Ohad Kotler, CEO and co-founder of Tweezr, puts it in an interview on the legacy comprehension problem:
"If you think about how legacy systems are actually formed, it's a history, decades of knowledge built piece on piece on piece. Trying to unscrew or reverse engineer all of that, those sets of insights, the logic, the thinking that has gone into them: first of all, the people that have that know-how often are already gone, retired, or not even alive. Second, the level of documentation, the practices that were driving the documentation, did not even exist at the point in time where those systems were written, and definitely were not maintained over time."
Before data can be cleaned or migrated, it has to be located, understood, analysed and, in many cases, simplified. Legacy constructs that no longer serve a purpose shouldn't be carried forward by default. The goal isn't to replicate the past. It's to build a foundation for what comes next.
That decision isn't only technical. Before cleansing begins, the bank has to decide what kind of institution it wants to be on the other side of migration, not simply carry forward the back book because that's what existed before.
Lewis Ide, SVP of APAC at 10x Banking, explains in a webinar on migrating to a 4th-generation core banking system:
"This is an opportunity to actually reframe what are the products that we want to offer to the market. Are there different or better versions of those products that we want to launch? The opportunity is there to flip the narrative around it just being about migration. This is a business opportunity as well, to think about these products in a different lens."
Treated this way, decisions about what data to carry forward become product decisions, not just technical ones.
Migrated data tends to break in one of two ways, and they require different fixes.
The first is a translation problem. Source and target systems use different formats, field lengths and conventions: one system's "home address" is another's "residential address", and a field built for 30 characters won't hold what the legacy system had been storing in 60. These issues are mechanical and, once identified, straightforward to correct.
The second is deeper. Source and target systems can calculate or model the same concept in genuinely different ways: interest calculations are a common example. In these cases, data has to be reinterpreted, not just reformatted, before it means the same thing in the new system. Miss this and the migration introduces errors that don't reformat away.
Bad data doesn't get fixed by moving it into a better platform. It becomes garbage inside the new system too, and problems introduced at migration can surface months or years later, when they're far more expensive to trace back to their source.
Andrew Ng, Head of Payments and Embedded Finance at Tungsten Automation, has seen this play out directly:
"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."
Yes, though the underlying discipline is the same. A brownfield migration, moving off a monolithic legacy estate, typically carries more of the first kind of risk: decades of undocumented customisation, duplicated records and fields repurposed long ago. A neo-core pivot, leaving a first-generation neo-core system that has hit its limits, tends to carry less historical clutter but can still hide conceptual mismatches, particularly where the neo-core platform modelled products or calculations in ways the bank has since outgrown.
Neither archetype gets a shortcut on data work. Our guide to core banking migration strategies sets out how the right approach differs by starting point, but data readiness underpins all of them.
During transition, data becomes the point of control. Whether an institution runs old and new systems in parallel or migrates in phases, the challenge isn't just moving data once. It's keeping it consistent across both systems for as long as they coexist.
Synchronisation models, the mechanisms that keep records aligned across systems mid-migration, are how institutions maintain trust in their data as they move from old to new. Get this wrong and the bank ends up with two systems that disagree with each other, which is worse than having migrated nothing at all. We cover the mechanics of managing this transition in why a phased approach is key to a successful core banking migration.
The 10x Banking Platform's migration tooling is built around this need for control. Data loaded into the platform stays modifiable, updatable and deletable while in a near-live state, with rollback available to any point in time before a final go-live decision is made. Institutions can also go live by customer-defined batches rather than a single cutover, moving in stages instead of betting everything on one weekend.
AI is already accelerating the hardest part of legacy system data migration: understanding what the data actually is. It helps teams identify inconsistencies, map data structures and surface hidden dependencies earlier in the process than manual analysis allows.
What it doesn't do is remove the need for discipline. Ohad Kotler frames the underlying challenge this way:
"If you think about a system that has an amazing level of layers and abstractions and stories, you can think about it like a full city, and you're trying to take that city and place it into a new city without understanding the map, the streets, the buildings, why are they where they are, how do they operate, and then being able to imagine where they need to go. That becomes an amazingly difficult challenge."
AI narrows that challenge. It doesn't remove it. Our piece on the legacy comprehension problem goes deeper into how AI changes migration analysis specifically. It's worth reading alongside this one: AI helps here, but it doesn't remove the data-quality work described above.
10x Banking and Tweezr have a formal partnership to combine Tweezr's deterministic, AI-driven legacy system analysis with the 10x Banking Platform's migration tooling, connecting the understanding stage described above to the reconciliation and testing stage that follows.
Data migration testing verifies two separate things, and conflating them is a common source of false confidence. The first is that data has moved correctly: every record present, correctly formatted, correctly linked. The second is financial reconciliation: that balances, transaction counts and totals in the new system match the source system exactly, for every account, at every checkpoint.
A core banking data migration strategy needs to test for both, and needs to test continuously, not just once at cutover, rather than treating reconciliation as a final check before go-live.
Nikhil Sengupta, VP Commercial at 10x Banking, points to what's changed the risk profile here:
"Historically, migration exercises were seen as incredibly high risk. Now, with 4th-generation platforms, AI-enabled solutions, migrations can be undertaken in a scalable, testable and repeatable way, fundamentally reducing the risk associated with large-scale migration initiatives."
Migration success isn't defined by whether the systems went live on schedule. It's defined by whether the data is trusted on day one, by the operations team reconciling accounts, by the compliance team pulling reports, and by the customer checking their balance.
Most migration risk isn't in the act of moving data. It's in not fully understanding it before you do.
To go deeper into migration planning, decision frameworks, and real-world approaches download the full guide: How to migrate to a 4th-generation core banking platform.
Inside you'll:
Uncover the real trade-offs between approaches, the hidden dependencies to be aware of, and how AI is changing parts of migration.
Explore the questions your institution needs to answer every step of the way with checkpoints on approach, data and AI readiness, dependencies and delivery.
Learn from industry experts who share candid reflections from their real-world experience. Featuring AWS, Tungsten, Tweezr and Westpac.
Download the how to migrate to a 4th-gen core playbook
Should banks migrate all their legacy data, or only what they still need?
Only data the institution still needs: operational data that actively supports products and customers, compliance-required data held under a defined retention obligation, and archival data kept for record-keeping rather than active use. Migration is a chance to decide what kind of bank it wants to be, not to replicate the back book by default.
Why does poor data quality cause more migration failures than architecture decisions?
Because architecture is documented and understood before a project starts, while legacy data usually isn't. Undocumented customisation, repurposed fields and hidden business logic surface as errors only once mapping and testing begin.
What does data cleansing involve before a core banking cutover?
Locating and analysing all sources of the data, identifying duplication and inconsistent ownership, and simplifying or removing legacy constructs that no longer serve a purpose, rather than carrying them forward by default.
How do banks reconcile balances and transaction history during migration?
Through automated financial reconciliation that checks starting balances, transaction counts, control totals and periods in the new system against the equivalent records in the source system, at defined checkpoints throughout the migration.
What is the difference between data migration testing and financial reconciliation testing?
Data migration testing confirms records have moved correctly: present, correctly formatted and correctly linked. Financial reconciliation testing confirms the resulting balances and transaction totals match the source system exactly.
Who owns data quality during a core banking migration: the vendor or the bank?
Both, but the bank owns the underlying data and the business logic embedded in it. The vendor's migration tooling can supporting moving that data, but only the bank can confirm what a given field or calculation was actually meant to represent.