How to Migrate Core Banking Data Without Losing a Single Record
In most technology projects, a small error rate is acceptable. A failed API call gets retried. A corrupted record gets reprocessed. The system recovers, and the business moves on.
Core banking data migration does not work that way.
When you are migrating data that underpins customer accounts, transaction histories, loan balances, and regulatory records, there is no acceptable error rate. A missing record is a missing customer account. A corrupted transaction history is a compliance failure. A balance discrepancy discovered post-cutover is an operational crisis that can take weeks to resolve and carries legal and regulatory consequences that extend well beyond the technical team.
This is not a theoretical concern. It is the reality that every technical team faces when they take on a core banking migration, and the gap between teams that navigate it successfully and teams that do not is almost entirely explained by the quality of their preparation rather than the sophistication of their tooling.
Here is what that preparation actually looks like.
Start With Data Discovery, Not Data Movement
The most expensive mistake in core banking migration is starting the technical work before the data is fully understood. This sounds obvious. It is consistently underestimated.
Core banking systems accumulate data over decades. The data model that exists in production today reflects years of decisions made by people who are no longer at the organisation, under constraints that no longer apply, for use cases that have since changed. The result is a data landscape that is significantly more complex than any documentation suggests.
Before a single record moves, the technical team needs to have answered a set of questions that most project plans do not formally schedule time for. What entities exist in the source system and what are their relationships? Which fields are actively used and which are legacy artefacts that exist for historical reasons but carry no current business meaning? Where are the referential integrity constraints, explicit and implicit? What are the known data quality issues, the duplicate records, the orphaned references, the fields that were supposed to be mandatory but are not? And where do the business rules that govern data relationships live, in the database constraints, in application logic, or in the heads of people who have been working with the system for twenty years?
The answer to this last question is particularly important because business rules that exist only in application logic or institutional knowledge are invisible to automated migration tooling and will not be enforced in the target system unless they are explicitly identified and rebuilt.
The discovery phase should produce a data dictionary that documents every entity, every field, every relationship, and every known quality issue. It should also produce a data quality assessment that quantifies the scope of remediation required before migration begins. That remediation, cleaning and standardising the source data, is almost always more work than the migration itself, and it is almost always underbudgeted when it is included in the plan at all.
Design the Migration Architecture Before Choosing the Tools
Core banking migration architecture decisions made early in the project have consequences that persist throughout the delivery. The two most consequential are the approach to cutover and the approach to validation.
For cutover, the choice is between a big bang migration, where everything moves in a single cutover window, and a phased migration, where data and functionality move in stages over an extended period. Big bang migrations are simpler to design but carry concentrated risk. The entire migration succeeds or fails in a single window, and the pressure of that window tends to compress testing and validation in ways that create post-cutover problems. Phased migrations distribute the risk but require maintaining a coexistence state between old and new systems for an extended period, which introduces synchronisation complexity that needs to be carefully designed and managed.
For most core banking migrations, a phased approach with a carefully designed synchronisation layer is the right choice. The synchronisation layer maintains consistency between the source and target systems during the transition period, ensuring that transactions processed in either environment are reflected in both. Building this layer correctly is technically demanding but it is what makes a zero-downtime migration achievable.
For the CDC component of the migration, the choice of tooling matters significantly in financial services environments. Qlik Replicate has become a standard in this space for good reasons. Its ability to capture changes at the database level, handle Type-1 and Type-2 slowly changing dimension logic, manage schema drift without manual intervention, and maintain strict ordering guarantees makes it appropriate for environments where data integrity is a compliance requirement.
The alternative, building custom CDC logic, is viable but introduces maintenance risk and requires ongoing investment to handle edge cases that purpose-built CDC tooling handles out of the box.
Build the Validation Framework Before You Need It
In a core banking migration, the validation framework is not a quality assurance activity that happens at the end. It is a continuous process that runs throughout the migration and determines whether the cutover can proceed.
The framework needs to operate at three levels. Record-level validation confirms that every record in the source system is present in the target system and that key fields match. Aggregate validation confirms that totals reconcile between the two environments, that account balances sum correctly, that transaction counts match, that the population-level picture is consistent. And business rule validation confirms that the relationships and constraints that govern how data should behave are being correctly enforced in the target environment.
For a migration of any meaningful scale, manual validation is not feasible. The validation framework needs to be automated, running continuously against both environments and surfacing discrepancies in real time rather than as a batch process at the end of a test cycle. The tooling investment in the validation framework should be treated as a first-class component of the migration project, not as an afterthought.
The six proof of concept validation tests are worth designing and passing before the full migration begins. These tests should cover the scenarios that are most likely to produce discrepancies: high-volume tables, records with complex relationships, records that have been modified multiple times during the migration window, and records that test the boundary conditions of the business rules being enforced. If the system cannot pass these tests in the POC environment, it will not pass them in production.
Plan the Cutover as Carefully as the Migration
The cutover window is the highest-risk phase of any core banking migration, and it deserves more detailed planning than most project plans allocate to it.
The cutover plan should be a step-by-step runbook that specifies every action that needs to occur, in sequence, with the person responsible for each action, the expected duration, the success criteria, and the rollback procedure if the success criteria are not met. This runbook should be rehearsed in a staging environment at least twice before the production cutover, with the full team executing it under conditions that replicate the production timeline as closely as possible.
The go-live criteria need to be defined in advance and agreed upon by all stakeholders, technical and business. What specific validation checks need to pass before the old system is decommissioned? What is the process for escalating a discrepancy discovered during the cutover window? And critically, what is the rollback threshold: the specific condition under which the cutover is abandoned and operations revert to the source system? Defining this threshold in advance, rather than making it a judgment call in the moment, is one of the most important risk management decisions in the entire project.
At Contivos, our data migration practice has delivered core banking and financial data migrations across systems supporting over a trillion dollars in assets, including a migration of 280 plus CDC pipeline tasks from Informatica to Qlik Replicate on Snowflake that validated over 10 million rows with zero errors. The approach described in this article reflects what we have learned from those engagements about what separates migrations that go well from the ones that do not.
If your team is planning a core banking data migration and wants to pressure-test your approach against the challenges described here, visit contivos.com to start that conversation.
Comments