What is traditional bank merger migration testing?

Traditional bank merger migration testing is the verification that customer, account, transaction and related operational data transfers accurately from one bank's systems into the other bank's target systems. It checks that migrated records retain their meaning and relationships, financial balances remain correct, and the combined bank can continue processing customer and back-office workflows after migration.

What traditional bank merger migration testing covers

A merger migration can involve moving data between core banking platforms, customer relationship management systems, payment services, card platforms and reporting systems. Testing starts with agreed source-to-target mappings: which source fields populate target fields, how formats or codes change, and how records with no direct equivalent are handled.

Coverage commonly includes customer identities and relationships, account ownership and status, product terms, balances, transaction history, payment instructions, mandates, limits, fees, interest settings and links to supporting systems. The exact scope depends on the merger's migration design and business rules. For example, teams need to know whether closed accounts and older transaction history move into the target system or remain available through an archive.

Tests check data quality at several levels. Field-level checks detect truncation, incorrect formats or lost values. Referential integrity checks confirm that accounts still point to the right customers and that standing orders or mandates retain their associated accounts. Business-rule checks verify that target values behave as intended, including product codes, account statuses and date conventions.

Financial reconciliation is a central part of the work. Teams compare source and target record counts, control totals and account-level balances, then trace any differences to an agreed rule or a defect. Account totals should also reconcile with relevant subledger and general ledger (GL) control totals. A matching row count alone cannot show that amounts, relationships or transaction histories are correct.

Dependencies and failure risks

Reliable testing depends on approved mappings, representative test data, stable source and target environments, and clear rules for exceptions. If the target configuration changes after a test run, previously verified results may no longer apply. Environment drift, incomplete reference data and changes to interest or fee rules can all affect migration outcomes.

Common defects include duplicate customer records, missing transaction history, incorrect account status, altered payment instructions, rounding differences and broken links between accounts and mandates. Migration can also preserve data accurately while leaving a workflow unusable, such as a transferred standing order that cannot be amended in the target channel. This is why migration checks need to connect to integration and end-to-end workflow testing.

Use controlled, approved data in test environments. Where production-derived data is necessary, apply the bank's data protection and access controls. Keep test inputs, mapping versions, reconciliation results, exceptions and retest outcomes traceable so teams can reproduce discrepancies.

Practical example

Suppose an account has a ledger balance of £1,250.00 and a pending card authorisation of £80.00. Under the agreed target rules, the migrated account should retain the ledger balance, pending authorisation and resulting available balance of £1,170.00. A migration test checks each value and the account's customer link, then confirms that the target system handles the pending authorisation correctly in a subsequent balance enquiry or transaction.

If the target shows the correct ledger balance but omits the authorisation, the record-level balance check alone may pass while the available balance is wrong. The test should report the missing item, identify whether the mapping or migration process caused it, and confirm the corrected result in a rerun.

How to verify migration outcomes

Run migration tests against representative data sets and repeat them after relevant mapping or configuration changes. Include normal records and exceptions such as joint accounts, dormant accounts, blocked payments and records with legacy codes. For each run, compare source and target data using defined tolerances and explain every accepted difference.

Migration testing also needs rehearsals of the planned cutover sequence. Verify extraction and load completion, reconciliation sign-off, dependent system readiness and the handling of failed or incomplete loads. A rollback or recovery path should be tested where the migration design provides one. Post-migration checks then confirm that selected accounts and workflows behave correctly in the live target environment.

Traditional bank merger migration testing focuses on transferred data and its behaviour in the receiving systems. Bank merger system integration testing examines how the combined systems interact across the wider estate, while banking migration cutover testing concentrates on the transition process and its controls.