Challenger bank core platform migration testing verifies that customer, account, transaction and control data move from the existing core to the replacement platform accurately, and that dependent services continue to process banking journeys correctly. It combines migration-specific data checks with end-to-end and operational tests, covering rehearsal, cutover, reconciliation and recovery.
Plan challenger bank core platform migration testing
Start with an inventory of the data and processes in scope. This may include customer and account records, balances, transaction history, interest and fee settings, payment instructions, holds, account status, and identifiers used by mobile apps or partner services. Confirm which records migrate, which remain available in a separate archive, and how each source field maps to the target.
Before execution, agree the mapping rules, target configuration, extract format, migration sequence and exception handling. Prepare representative test data, including joint accounts, dormant or restricted accounts, negative balances where supported, pending transactions and customers with several products. Use approved, suitably protected data. Record the source snapshot time and any transactions processed after that point.
Define reconciliation rules for each data set. Compare record counts and control totals, then verify field-level mappings and financial values. Balance checks should use the bank's approved rules for currency precision, rounding, value dates and any conversion of product or status codes. Specify acceptable tolerances and who can approve each exception before testing starts.
Validate data and customer journeys
Run migration tests against controlled source snapshots. Check that required records arrive once, relationships remain intact, and identifiers still link accounts to customers, mandates and downstream services. Validate rejected, duplicated and unmapped records as carefully as successfully converted records. Every exception should have a reason, an owner and a defined resolution or acceptance route.
Reconcile financial data at more than one level. For example, compare account-level opening balances and transaction totals, then check that account balances agree with the relevant subledger and general ledger totals under the agreed accounting rules. Verify that migrated transaction history has the expected dates, descriptions, debit or credit direction and references. A matching total can conceal offsetting errors, so include record-level and sample-based checks.
Exercise customer journeys across channels and connected systems. A migrated current account should support sign-in, balance display, transaction search, payment creation, payment status updates and statement retrieval. Test APIs and event consumers that read account details, along with card, payment, fraud and customer-support integrations that apply to the bank's architecture. Check that permissions, account restrictions and audit history remain effective.
Include functional and regression tests for core banking rules, such as interest accrual, fees, holds, standing orders and scheduled payments. Test boundary dates around the migration point, including transactions received before and after the source snapshot. Verify that retries or replayed messages do not create duplicate postings, and that failed transactions leave account and ledger data consistent.
Rehearse cutover and recovery
Run at least one migration rehearsal using the planned extraction, transformation, loading and reconciliation process. Capture duration, resource use, error counts and manual interventions. A technically successful load may still miss the cutover window or depend on undocumented corrections, so test the operational runbook as well as the data outcome.
For cutover testing, verify the freeze or delta-capture approach, the order of dependent jobs, access controls and checks that must pass before customer traffic moves. Test the decision points for stopping the cutover. Establish how new transactions are handled if the bank needs to recover, including whether a rollback remains safe after target-side activity or external payment messages have occurred. In some situations, a controlled forward recovery may be safer; the recovery method must be agreed and tested for the specific design.
A parallel run can compare outputs from the old and new platforms for a defined period or data set. Set rules to prevent duplicate external effects, such as sending the same payment from both systems. Compare balances, postings, fees and scheduled processing, investigate differences, and retain evidence of their resolution.
Worked test case and exit evidence
Scenario: Migrate a current account with an opening balance, posted transactions, a pending card transaction and an active standing order.
- Capture the source account and record its snapshot time, balance, status and payment instruction.
- Run the migration and confirm the account, history and standing order appear once with their mapped identifiers and correct status.
- Reconcile the opening balance and transaction totals against approved rules. Confirm the pending card item is represented according to the target design.
- Execute the standing order in a controlled environment. Check the resulting debit, payment message, account balance and ledger postings.
- Replay the relevant migration or payment message where supported, then verify that no duplicate account, instruction or posting appears.
Exit evidence should include reconciliation results, resolved exceptions, journey and regression results, cutover rehearsal timings, recovery-test outcomes and approvals from accountable business and technology owners. Link failures to affected data mappings or workflows so that retesting covers the changed areas and their dependent processes.
Frequently asked questions
How should records with no direct target equivalent be tested?
Define an explicit conversion, archival or rejection rule for each record type before migration. Test representative examples, confirm that rejected records are reported with usable reasons, and obtain an authorised decision for any exception that remains unresolved.
What makes a migration rehearsal representative?
A representative rehearsal uses the planned extraction and transformation process, realistic data relationships and volumes, target configuration, job sequence and operational runbook. Include exception handling and reconciliation so the rehearsal exposes manual steps and timing constraints as well as load defects.
Should historical transactions always be loaded into the new core?
That depends on the bank's product, reporting and customer-access requirements. If history remains in an archive, test that authorised users can retrieve it, that searches return the expected records, and that references and dates remain consistent with the migrated account.