Do players lose their balance in a platform migration?

They must not, and proving they did not is the core deliverable of the workstream. Every wallet balance is reconciled at cutover: a snapshot on the source, a snapshot on the target, and a signed report explaining every difference down to zero. An operator that cannot produce that report has a player-funds problem and, in most regimes, a regulatory one — regardless of whether any balance was actually wrong.

Does KYC carry over to the new platform?

The evidence can move where data-protection and licensing rules allow it; whether the status carries is a compliance decision, not a technical one. Re-verifying an entire player base is a conversion catastrophe, so the usual posture is to preserve verified status where the regime permits and the evidence chain is intact, and to re-check only where the original verification would not meet current requirements. Decide this with the compliance owner before the mapping is built, not after.

What happens to active bonuses during migration?

One of three things, decided per bonus construct in advance: recreate the state on the target where the mechanics match, convert to an equivalent the target supports, or settle and close with clear player communication. The worst outcome is the accidental fourth: wagering progress silently reset, which players notice within the hour and support pays for over weeks. Bonus state is the most mechanically fiddly part of the whole migration — see bonus economics for why the liability side matters too.

How much game and transaction history should move?

Enough that the new platform can serve players, support and the regulator without calling the old one — which is usually recent history in full and the rest as archival read access. The driver is not storage cost but rehearsal time: full-history runs dominate the migration clock. Map the retention obligations per market first; the cut line is a compliance decision wearing an engineering costume.

What is identity mapping and why does it fail?

The table that says which source account becomes which target account. It fails on duplicates (one person, two accounts), collisions (two people, one email), and format mismatches the source platform tolerated for years. It must be built early, validated against real data, and frozen before cutover — because every downstream artefact, from balances to exclusion flags, joins through it. An exclusion flag that misses its target account is the single worst defect a migration can produce.

Player Data Migration in iGaming

What is actually in "player data"

Each layer has a different correctness standard, a different failure cost, and a different owner. Treating them as one dataset is the first mistake:

Layer	Correctness standard	Cost of getting it wrong
Identity	Exactly one target account per person, with every join intact	Every other layer inherits the error
Wallet balances	Exact, to the smallest unit, in every currency held	Player funds discrepancy — commercial and regulatory
KYC / verification state	Status preserved only where the evidence chain and the regime allow	Unlawful processing or a mass re-verification funnel
Responsible-gambling state	Exclusions, limits and flags applied before the first login is possible	The worst defect class a migration can produce
Bonus state	Liability and wagering progress carried per the decided rule	Silent resets — immediate player-visible breach of trust
History	Complete to the cut line, archival access beyond it	Support blindness and unfulfillable regulator requests

Notice that the two layers with the highest failure cost — responsible-gambling state and balances — are also the smallest by volume. Size and importance are unrelated in this workstream, which is why prioritising by table row-count gets it exactly backwards.

Identity first, everything else joins through it

The identity map is built first because every other artefact depends on it, and it is where the source platform's accumulated tolerance comes due: duplicate accounts, shared emails, formats that were never validated, test accounts nobody flagged. Three practices keep it sane:

Deterministic rules, written down. What makes two source records the same person, what happens to duplicates, who adjudicates the ambiguous cases. Judgement calls happen — they happen once, in a documented queue, not per-record in a script.
Validate against reality, not the schema. The schema says email is unique; the data says otherwise. Run the map against full production-shaped exports early, because every surprise found in rehearsal is one not found at cutover.
Freeze it before cutover. A map that keeps changing while balances are being reconciled produces differences nobody can explain. Late-arriving account changes go through a controlled delta process, not an edit.

Balances: the reconciliation contract

Write the reconciliation contract before the first rehearsal — it is the definition of done for the entire workstream:

Scope: every balance type that exists — real, bonus, pending, held, loyalty points — in every currency, including the accounts everyone assumes are empty.
Method: source snapshot and target snapshot at the same logical moment, compared at account level, not in aggregate. Aggregates hide offsetting errors, and offsetting errors are still errors in individual players' money.
Tolerance: zero. Every difference is explained and resolved, or the cutover does not proceed. A "small" unexplained difference is not small — it is evidence the process has a defect of unknown size.
Artefact: a signed report, retained with the migration evidence, reproducible from the snapshots. This is the document the regulator, the auditor and the first disputing player will each eventually require.

The states that must never lapse

Balances can be frozen during a cutover window; protections cannot. Self-exclusions, deposit limits, cool-offs and risk flags must be enforced on the target platform before any player can log in — including the interval when the migration itself is running. That usually means they migrate first, are verified independently of the main reconciliation, and are re-checked as the final pre-open gate. If a register integration exists in the market, its rewiring belongs to this gate too, not to the general integrations list.

Sequencing and the rehearsal loop

Order	What	Exit criterion
1	Identity map on full production-shaped data	Ambiguity queue empty; duplicate policy applied; map frozen
2	RG state and compliance flags	Independently verified on target; enforced before any login path opens
3	Balances and bonus state	Reconciliation report at zero unexplained difference
4	History to the cut line	Support and reporting can answer without the source platform
5	Full rehearsal, timed	Duration and defect rate stable across consecutive runs

The loop in step five is the honest schedule generator: the migration window you can commit to is the rehearsal duration you have actually measured, plus the contingency you have actually rehearsed — not the duration you hope for. This feeds directly into the freeze-window decision in parallel run and cutover.

After cutover: keep the evidence

The snapshots, the reconciliation report, the identity map and the decision log survive the project. Retention duties continue across the platform change, disputes reach backwards in time, and the question "what did this account look like before the migration" arrives months later with a deadline attached. Archive the workstream as if you will be asked to defend it — because the one time it matters, you will be.

Continue reading: The migration risk checklist — everything around the data that also breaks. KYC and AML across regimes — the verification design the migrated statuses land in.

Moving the players.