What is core banking data migration testing?

Core banking data migration testing verifies that customer, account, transaction and ledger data move from a source platform to a target platform accurately and remain usable. It checks that records are complete, relationships and financial values are preserved, and any intended transformations follow approved rules. The aim is to detect data loss, corruption or inconsistent balances before migrated data supports live banking operations.

What core banking data migration testing covers

Testing starts with agreed migration scope and source-to-target mappings. These describe which records move, how fields are converted, and how exceptions such as invalid or unsupported values are handled. Preconditions include an identified source data snapshot, target configuration, reference data, and approved rules for any changes to product or account structures.

Checks commonly cover:

• Completeness: Compare source and target record counts by entity and relevant categories, such as account status or product. Check primary keys, foreign keys and relationships between customers, accounts and transactions. Identify missing, duplicated or orphaned records.
• Field mapping and conversion: Verify that values land in the correct target fields and follow conversion rules. Examples include date formats, currency codes, status values, product codes and numeric precision.
• Financial integrity: Reconcile balances and transaction totals at appropriate levels, such as account, product, branch or ledger. Confirm that debits and credits remain balanced and that holds, pending items and accrued amounts are represented correctly.
• Operational usability: Confirm that target services can retrieve migrated records and apply the expected rules. This can include viewing account history, calculating available balances or processing a transaction against a migrated account.
• Exception handling: Check that rejected, defaulted or transformed records are reported with traceable reasons and can be investigated or corrected through an agreed process.

Data protection and access controls also matter because migration test environments can contain sensitive customer information. Testers should work with approved data and access arrangements, and ensure that logs and evidence do not expose information unnecessarily.

How to verify migration results

Use reconciliation for broad coverage, then inspect individual records and run targeted tests for higher-risk cases. Reconciliation should compare like with like: the same source snapshot, product scope, currency, business date and treatment of pending transactions. Any permitted differences need defined rules and evidence, rather than an unexplained tolerance.

A useful test set includes normal records and edge cases, such as closed or dormant accounts, accounts with holds, joint customers, high-precision amounts and records with long transaction histories. Where a migration runs in batches, verify that restart or rerun behaviour does not omit or duplicate data. Confirm that failed records are identifiable and that their treatment does not leave related data inconsistent.

A count match alone does not prove data integrity. Matching totals can conceal incorrect field mappings or one missing record offset by a duplicate. Combine aggregate reconciliations with record-level comparisons and checks of relationships and target behaviour. Sampling can help investigate records in depth, while automated comparisons can cover large populations where the data and controls support them.

Practical example

Suppose a current account has a ledger balance of £1,000 and a pending debit of £120, so its available balance is £880. After migration, compare the account and transaction records with the agreed source snapshot. Confirm that the ledger balance remains £1,000, the pending debit appears once, and the available balance remains £880 under the target system's rules. Then check that the customer-account relationship is intact and that the account's transaction history can be retrieved. A missing pending debit could leave the ledger balance apparently correct while overstating the amount available to the customer.

Migration testing and functional testing

Core banking data migration testing focuses on the accuracy and usability of converted data. Functional testing checks whether system behaviour follows requirements. The activities overlap when testers use migrated accounts in target workflows, such as posting a payment or calculating interest. That overlap helps reveal defects that data comparisons alone cannot find, while data reconciliation can identify conversion errors that a small set of functional scenarios may miss.

Related concepts include Core banking replacement testing, Banking migration cutover testing and Banking test data management.