Integrations and platforms
Data and platform migration testing
Data and platform migration testing checks that balances, ledger history, open loan and billing positions, card tokens, and direct debit mandates move between core banking systems, ledgers, and payment providers without loss or change. Buyers receive a migration reconciliation test plan, a balance and transaction history comparison report, card token and mandate migration checks, and cutover and rollback rehearsal results.
What migration testing covers for financial data
A migration defect shows up on the first business day after cutover: a balance short by one lost posting, a renewal charged twice, or a collection rejected because its mandate reference changed. We test migrations between core banking systems, ledgers, card processors, billing, payroll, and cap table platforms.
Balances and ledger history
Comparisons run per account, currency, and business date:
- Closing balance. The target balance on the cutover date equals the source balance and the sum of migrated postings, so an opening balance journal that plugs a difference fails.
- Posting counts and control totals. Counts and sums per account, day, and transaction type match, catching a mapping filter that drops reversals or zero-amount fee waivers.
- Original dates. Value and booking dates survive, so reissued statements and recalculated interest for past periods return the source figures.
- Holds. Card authorisation holds and blocked amounts migrate as holds, and available balances match.
- Precision. A source storing four decimal places and a target storing two leave rounding residues, listed per account in the comparison report.
Ledger and reconciliation testing covers the same double-entry rules in daily operation.
Open positions and mid-period state
Migrations lose money in amounts that are not yet postings:
- Loans. Outstanding principal, accrued unpaid interest, next due date, days past due, and the remaining schedule migrate together for lending products. A target that restarts accrual from the last payment date charges interest again for days the source already accrued.
- Subscriptions and invoices. Billing cycle anchors, unused credit, open invoices, and dunning state migrate, so a mid-cycle customer is neither billed on cutover day nor skipped for a cycle.
- Payroll year-to-date figures. Year-to-date wages and taxes per employee reconcile before the first live pay run, as the payroll segment page explains.
- Equity records. Share counts per class, option grants, exercise prices, and vesting start dates reconcile per holder; a shifted vesting start date changes vested shares on every later date.
Card tokens, stored credentials, and mandates
A new processor or vault changes where account data is stored and transmitted. PCI DSS v4.0.1 (June 2024) lists changes in the flow or storage of account data among the activities that must be considered and evaluated to determine whether a change is a significant change. Upon completion of a significant change, requirement 6.5.2 requires all applicable PCI DSS requirements to be confirmed in place on all new or changed systems and networks. Requirement 3.2.1 retention policies cover all locations of stored account data, including migration export files and source tables. Tests check:
- Vault token mapping. Each source token maps to exactly one target token with the same last four digits and expiry date, and no clear-text PAN remains in mapping files, logs, or staging tables.
- Stored credential identifiers. Visa Acceptance developer documentation (checked 2026-09-16) says to store and submit the original or network transaction identifier of each billing agreement for merchant-initiated card-on-file transactions, so each migrated agreement keeps its own identifier.
- Network tokens. EMVCo (checked 2026-09-16) describes an EMV Payment Token as constrained in how it can be used, for example to a specific merchant, device, or payment scenario. Tests record whether the target platform can use each network token or must provision a new one.
- SEPA Direct Debit mandates. Under PT-02.02 of the SDD Core Rulebook 2025 version 1.1 (issued 5 October 2025), a creditor must send amended mandate information to its PSP as part of the next collection, where the amendment concerns a PSP, such as a unique mandate reference changed by restructuring or a Creditor Identifier changed by a merger, acquisition, spin-off, or organisational change. Tests check that amendment on the first collection after cutover, and that each mandate keeps its latest collection date, because section 4.2 requires a creditor to cancel a mandate under which it has presented no collection for 36 months, counted from the latest collection presented, even if rejected, returned, or refunded.
In-flight payments at cutover
- An authorisation approved on the source and captured after cutover releases its hold once on the target.
- A transfer sent before the freeze and returned after it credits the right account once and links to the original payment.
- A webhook or bank file that reaches the old endpoint after cutover is replayed on the target once.
- A standing order due on cutover day runs on exactly one system.
Personal data
GDPR Article 5(1)(d) requires personal data to be accurate, so a transaction history attached to the wrong customer is an accuracy defect. Article 4(12) defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Tests check that consent states, erasure flags, and retention holds migrate with each customer record; the GDPR testing requirements page lists related articles.
Related
Segments
Standards
Guides
Deliverables
Migration reconciliation test plan
A plan that maps each migrated entity, such as account, posting, hold, loan, subscription, card token, and mandate, to its comparison key, control totals, accepted differences, and sign-off owner, used by the migration lead.
Balance and transaction history comparison report
A per-account and per-currency comparison of source and target balances, posting counts, control totals, holds, and accrued amounts on the cutover date, listing every difference with its source records for finance and engineering review.
Card token and mandate migration checks
Checks that each migrated card token maps to exactly one target token with the same last four digits and expiry date, each recurring agreement keeps its transaction identifier, and each direct debit mandate keeps its reference and dates.
Cutover and rollback rehearsal results
A record of each rehearsal with the duration of every step against the freeze window, the go or no-go checks, the handling of in-flight payments, and a completed rollback to the source system.
How migration testing fits your cutover plan
- While the mapping is built. The migration reconciliation test plan fixes a comparison key, control totals, and an owner for each entity. Mapping changes go through the same review as code.
- On every migration script change. The comparison runs in CI against a synthetic source dataset with seeded edge cases: closed accounts with residual balances, reversed postings, loans in arrears, expired cards, amended mandates, and payments pending at the freeze. A script that changes a control total fails the pipeline.
- Mock migrations. Where a mock run needs production volume and distribution, the data is masked inside your environment first, as our security procedures describe. Each mock run produces a new balance and transaction history comparison report, compared with the report from the previous run.
- Rehearsals. Each cutover and rollback rehearsal runs the planned sequence with its timings: freeze, final extract, load, comparison, token and mandate checks, go or no-go, and a rollback that returns the source system to service with no lost transaction. For a processor move, the switch payment processor scenario sets out the wider sequence.
- Cutover. The comparison reads migrated production data inside your environment, under a written scope agreed before the work starts, and no data leaves it.
- After cutover. Checks run on the first end-of-day reconciliation, the first renewal and collection runs, and the first statement cycle on the target.
Suites, data generators, and comparison queries live in your repository. The evidence set for each migration holds the test plan, every comparison report, the token and mandate check results, and the rehearsal results, stored with the change record. That set is input to your PCI DSS significant change review and scope confirmation under requirement 12.5.2.
Your team owns the field mapping, accepted differences, the go or no-go decision, production access, and customer notices, including the notice to debtors that PT-02.02 requires from a new creditor when the creditor's identity changes because of a merger or acquisition.
Sample deliverable
Sample, synthetic data
| ID | Scenario | Expected ledger entries | Amount (XTS) | Expected reconciliation result |
|---|---|---|---|---|
| REC-01 | Processor settlement file repeats the settlement line for one capture | Dr Processor receivable / Cr Merchant payable, posted once | 120.00 | Break: the second settlement line has no matching capture and is flagged as a duplicate |
| REC-02 | Partial refund on a capture that settled the day before | Dr Merchant payable / Cr Processor receivable | 45.50 | Match: the refund line matches the refund entry and the original capture stays settled |
| REC-03 | FX rounding difference between the capture amount and the settled amount | Dr FX rounding expense / Cr Processor receivable | 0.01 | Match with a rounding entry when the difference is inside the configured tolerance |
| REC-04 | Processor fee line missing from the settlement file | Dr Processing fee expense / Cr Processor receivable | 2.90 | Break: net settlement is lower than gross captures and a missing fee exception opens |
| REC-05 | Chargeback reversed after the merchant wins representment | Dr Processor receivable / Cr Chargeback liability | 80.00 | Match: the reversal line clears the open chargeback entry |
| REC-06 | Refund request retried after a timeout, with the same idempotency key | Dr Merchant payable / Cr Processor receivable, posted once | 30.00 | Break: the settlement file has two refund lines for one refund entry, and the second line is flagged as a duplicate refund |
| REC-07 | Partner bank credits the payout one business day after the expected value date | Dr Partner bank cash / Cr Processor receivable | 1,000.00 | Match on the payout reference, with the value date difference logged as a timing item |
Amounts use XTS, the ISO 4217 code reserved for testing. Account names are generic ledger accounts.
Questions
What is data migration testing?
How to test data migration?
How to write test cases for data migration?
Scope your migration testing
Send your source and target systems, the entities you migrate, and the planned cutover window, and we return a test scope with the comparisons and rehearsal steps per entity.
Scope your testing