Platform migration: matching totals is not reconciliation

Consider an invented migration containing two euro accounts. Account A has €120 in the source and €100 in the target. Account B has €80 in the source and €100 in the target. Both systems contain two accounts and total €200; the target also totals €200. Yet each customer’s balance is wrong by €20. Equal row counts and equal aggregate balances have passed while ownership of the money has failed. This counterexample is arithmetic, not evidence that a named platform has made such an error.

AWS Database Migration Service documents a stronger technical comparison: when data validation is enabled, it compares corresponding source and target rows and reports mismatches. It also reports states such as pending, suspended and failed validation, and notes that constantly changing source records may not be comparable. Those distinctions matter because completing a transfer and validating its contents are separate observations. The documentation describes AWS DMS capabilities; it does not establish that any particular gaming-platform migration uses or passes them.

Our recommended acceptance pack begins with a mapping from source account identity to target account identity and a defined reconciliation point. Compare amounts by account and currency before aggregating. For a change of schema, write down the approved transformation: for example, which source buckets become cash, bonus or reserved balances. A row-level comparison still needs an explanation of intentional transformations. Investigate differences as owned exceptions; do not adjust a balancing account to make the headline total agree.

Then test meaning beyond the amount. A matching balance can still be incorrectly spendable if an account restriction, pending withdrawal or reserved wager was omitted. Select controlled examples that cover those states and verify the intended action in the target journey. Preserve the relationship between the account, transaction history and unresolved obligation. Record which system remains authoritative for an open bet or payment that completes after the migration boundary, and show how the result reaches the new account exactly once.

A static rehearsal and a cutover with incoming events answer different questions. Record the snapshot or checkpoint, the final change boundary and evidence that the relevant updates have been applied. Separate a genuine discrepancy from an expected lag without allowing “still syncing” to become an indefinite explanation. Agree which unresolved differences block release and who can accept an explicitly documented exception. Retain the validation configuration and excluded populations so that “zero mismatches” cannot be mistaken for “every record was checked”.

Finally, rehearse the return path. If the target has already accepted transactions, restoring an older source snapshot can lose valid new activity. Decide how those events would be preserved, replayed or otherwise reconciled under the approved recovery plan. The decision record should connect technical evidence, finance reconciliation and customer-impact checks, with owners for each. A credible completion statement names the tested population, point in time, remaining exceptions and release decision. It does not ask a single green total to stand in for all four.