PAM migration acceptance: accounts, balances and unfinished transactions

Migration rehearsal acceptance matrix

Agree the expected state and permitted actions before running each sandbox test. Successful row comparison does not establish application correctness.

Define the object being accepted

Write a migration contract for the data before selecting a transfer mechanism. Identify the source and destination account keys, currencies, cash and bonus definitions, reserved funds, restriction states, timestamps and unresolved transaction references. State which fields can be transformed and which must match exactly. Define missing values explicitly: a blank restriction or unknown verification state must not become an affirmative permission merely because the destination requires a value. Keep the mapping version with the rehearsal evidence so a later schema change cannot inherit an earlier sign-off.

Choose a common comparison checkpoint

Source and destination totals taken at different times can disagree even when the transfer is correct. Our proposed rehearsal records a snapshot or replication checkpoint, the event boundary represented by each extract and the treatment of writes still in flight. Compare a consistent population by account, currency and relevant balance type. Investigate missing accounts, duplicated keys and offsetting differences separately. Do not cancel an excess in one player account against a shortage in another, or convert currencies simply to make one headline total agree.

Understand what the validation tool actually checked

AWS DMS documents row-level comparisons between corresponding source and target records when validation is enabled, with separate states for mismatches, pending or suspended records and errors. Continuously changing records can prevent comparison. Its settings also govern validation behaviour, and validation-only tasks do not migrate data. These are properties of that service, not a guarantee about a PAM export. Ask for the actual configuration, supported data types, exclusions and unresolved states. A green task status must be interpreted against the population and fields it covered.

AWS DMS — Validating data

AWS DMS — Data validation task settings

Make unfinished obligations a separate test population

Select synthetic examples of an authorised but unsettled payment, a pending withdrawal, a reserved wager, an open game round and a bonus with remaining conditions. Preserve the references needed to finish each under the agreed operating rules. After import, drive each example through its next legitimate event and inspect the resulting balance and history. A row can match perfectly while the destination no longer knows which service is allowed to complete it. Record the owning system and the customer-support route for every unresolved type.

Test replay and order at the system boundary

During rehearsal, deliver a synthetic completion event twice, and deliver another after its corresponding reversal or cancellation using a supported test sequence. The required result comes from the integration contract: repeated receipt must not create a second economic effect, and corrections must retain a reconstructable history. Also test a delayed restriction update and an account mapping failure. Keep event identifiers, timestamps, observed responses and resulting records together. Do not accept a screenshot of an unchanged total as proof that the correct account and transaction were processed.

Specify the point at which rollback stops being simple

A destination that has accepted new customer activity may contain obligations absent from the old system. Document who can stop writes, who owns the authoritative ledger at each phase and how new activity is reconciled if the cutover is abandoned. Rehearse the decision with synthetic data before scheduling production work. Record rollback entry conditions and a named decision owner, including what happens when the agreed window closes. A database restore alone is not a complete plan for activity already acknowledged to customers or external payment services.

Close exceptions with evidence and a scope

Use the acceptance matrix as the cover of a reproducible evidence pack. Attach the mapping version, checkpoint, population counts, field differences, behaviour-test results and unresolved exceptions. Assign every exception a decision owner and retest requirement. A sign-off should name the tested release, market configuration and known exclusions; it should not quietly approve future configuration changes. Before moving beyond rehearsal, confirm the applicable operational, contractual and regulatory responsibilities with the relevant owners. The reusable supplier worksheet provides fields for the claim, test, observation and remaining decision.