Buyer-owned exit pack · no form · no data sent

iGaming platform migration checklist

A working inventory and acceptance pack for moving player records, wallet ledgers, payments, open games and bets, KYC and AML evidence, player-protection controls, reports, configuration, and the digital estate without losing legal or financial continuity.

Start with the data inventory Download inventory CSV

15 migration domains10 controlled phases8 acceptance gatesChecklist snapshot August 2, 2026

Public product pages do not establish a complete exit right

In the current 16-provider dataset, 0 profiles have public claim-level evidence for every tracked ownership and exit field. Architecture, APIs, dashboards, or an “operator owns the data” sales statement do not by themselves prove export scope, retained history, post-termination access, migration assistance, or deletion obligations.

The migration unit is a reconciled domain

Data and system-of-record inventory

For each domain, name the authoritative entity and system, stable keys, fields and history, full and incremental export, schema, delivery, control totals, legal holds, owner, and acceptance result.

Required iGaming migration data domains and controls
Domain	System-of-record question	Stable keys	Required scope	Control totals	Live cutover handling
Player master and identity	Which entity and system own the canonical player, brand, market, account-status, contact, consent, and identity attributes?	player ID, external IDs, brand ID, market ID, identity-version ID	Current values, full change history where retained, merges, closures, deceased or blocked flags, preferences, consents, and provenance.	Players by brand, market, state, account status, verification state, and registration period.	Freeze identity-changing workflows or replicate deltas until the final cutover watermark.
KYC evidence and decisions	Does the platform, KYC supplier, or operator retain the evidence and decision audit trail?	player ID, case ID, check ID, document ID, provider reference	Checks, results, documents or retrievable references, reason codes, manual reviews, timestamps, reviewer, version, expiry, and retry history.	Cases and checks by outcome, provider, age, market, and missing-evidence exception.	Define whether in-flight checks finish on the old system or restart with preserved evidence and customer state.
Wallet ledger and balance buckets	Which ledger is authoritative for cash, bonus, locked, pending, reserved, withdrawable, and product-specific balances?	ledger entry ID, transaction ID, player ID, wallet ID, currency, brand	Immutable entries, opening balance, debit, credit, reversal, adjustment, reservation, release, reason, reference, event time, posting time, and actor.	Opening + credits - debits + adjustments = closing by entity, brand, currency, bucket, day, and player; unmatched entry count and value.	Set a ledger watermark, stop or dual-control writes, replay final deltas once, and prohibit manual balance copying without entries.
Deposits, withdrawals, and payment operations	Which system owns the payment lifecycle, PSP references, settlement, reserves, disputes, and withdrawal review?	payment ID, provider transaction ID, player ID, ledger references	Initiation, authorization, capture, settlement, failure, reversal, refund, chargeback, withdrawal approval, method token references, fees, and FX.	Count and gross/net value by status, PSP, method, currency, day, unresolved withdrawal, chargeback, and settlement batch.	Keep callbacks routable, preserve idempotency keys, and assign ownership for in-flight deposits and withdrawals during DNS or API cutover.
Casino rounds and game transactions	Does the PAM, aggregator, or RGS settle and retain the authoritative round and transaction history?	round ID, game transaction ID, player ID, game ID, provider ID	Round open/closed state, bets, wins, rollbacks, voids, resettlements, jackpot and free-spin references, game version, timestamps, and wallet entries.	Bets, wins, GGR, open rounds, rollback/void counts, unmatched wallet entries, and ageing by provider, game, currency, and market.	Migrate open rounds with protocol support or retain the old stack as settlement authority until every round closes and reconciles.
Sportsbook wagers and settlement	Which sportsbook engine remains authoritative for accepted wagers, liabilities, cashout, results, settlement, and resettlement?	bet ID, leg ID, market/event ID, player ID, wallet references	Selection, odds, stake, acceptance, rejection, limit decision, status, cashout, result source, settlement, void, resettlement, and liability.	Open stake and liability, accepted/settled/voided counts, cashout, payout, GGR, resettlements, and wallet exceptions by event and currency.	Do not move open bets without an agreed settlement authority, result feed, liability owner, wallet bridge, and resettlement process.
Bonus, loyalty, and promotional state	Which engine owns awards, balances, wagering progress, eligibility, expiry, and abuse decisions?	award ID, campaign ID, player ID, wallet and transaction references	Offer version, award, opt-in, progress, contribution, completion, forfeiture, expiry, manual action, segmentation, and terms accepted.	Awards and value by state, campaign, currency, expiry, outstanding liability, and unmatched wallet or game references.	Freeze new awards or replicate campaign and award deltas; preserve player-visible progress and the exact accepted terms.
Limits, exclusions, and safer-gambling interactions	Which system and entity own self-exclusion, cool-off, deposit/loss/time limits, risk flags, interactions, and regulatory notifications?	player ID, protection-event ID, limit ID, interaction ID	Current and future-effective limits, increase cooling-off, exclusions, risk events, case notes, interactions, assessments, decisions, and acknowledgements.	Records by type, status, effective date, market, player, unresolved action, and failed target-system enforcement test.	Protection controls must be active before the player's first target-system login; never rely on a post-launch backfill.
AML, fraud, source-of-funds, and investigations	Which case system retains alerts, rules, evidence, decisions, filing references, confidentiality restrictions, and legal holds?	case ID, alert ID, player ID, transaction IDs, filing reference	Alerts, scores, rule versions, linked activity, evidence, analyst actions, approvals, restrictions, reports, notes, and attachments or retrievable references.	Open and closed cases by type, age, severity, outcome, owner, missing evidence, and legal-hold state.	Assign in-flight cases and preserve access controls, confidentiality, evidence chain, retention, and regulator-reporting continuity.
Complaints, disputes, and support	Does the platform, CRM, ticketing tool, ADR process, or operator own the complete customer-contact record?	case/ticket ID, player ID, complaint ID, transaction references	Contacts, category, channel, attachments, responses, outcome, redress, escalation, ADR or regulator reference, timestamps, SLA, and owner.	Open/closed cases by age, category, severity, market, redress value, escalation, and missing attachment.	Keep channels routable and move every open case with owner, deadline, history, evidence, and customer-visible reference intact.
Affiliate and acquisition attribution	Which system owns click, registration, first-deposit, player attribution, deal, commission, and fraud-adjustment history?	affiliate ID, click ID, player ID, campaign/deal ID, commission ID	Attribution events, hierarchy, deal version, revenue basis, deductions, commission, carry, payment, disputes, tags, and consent scope.	Players, FTDs, revenue basis, commission, unpaid amounts, negative carry, and orphan attribution by affiliate and period.	Preserve links and callback routing through cutover; freeze retroactive deal changes and reconcile the split period before paying commissions.
Back-office users, roles, and audit logs	Which identity and audit systems prove who could access or change player, financial, configuration, and regulatory data?	user ID, role ID, permission ID, audit-event ID, target record ID	Users, employment status, roles, permissions, approvals, segregation, privileged access, login history, changes, exports, and impersonation.	Active users, privileged roles, orphan accounts, conflicting permissions, failed mappings, and audit events by category and retention period.	Provision least privilege before data loads, disable old access at the agreed point, and retain tamper-evident historical logs outside the retiring UI.
Regulatory, tax, and financial reports	Which ledger and reporting layer can reproduce every submitted return, amendment, control total, and underlying transaction?	report ID, period, entity, market, submission/amendment reference	Returns, source data, transformations, sign-off, submissions, acknowledgements, amendments, reconciliations, and retained report versions.	Submitted values reproduced from immutable source data by entity, market, product, currency, tax basis, period, and version.	Define split-period ownership and ensure one party can produce a complete return spanning the old and new systems.
Configuration, content, and market controls	Which repositories and approval workflows own brands, markets, games, limits, payments, bonuses, rules, copy, and feature flags?	configuration ID, version, market, brand, product/content ID	Versioned configuration, effective dates, approvals, dependencies, localization, market restrictions, game and payment matrices, and rollback state.	Objects and active versions by market/brand, unmapped IDs, unauthorized differences, expired approvals, and failed regression checks.	Freeze non-essential changes, diff every target configuration, approve exceptions, and keep a tested configuration rollback package.
DNS, CDN, certificates, apps, analytics, and code/IP accounts	Who owns every account, domain, key, signing certificate, repository, app listing, analytics property, and vendor integration?	account/property ID, domain, certificate/key ID, app ID, repository	Ownership, admins, billing, credentials, secrets, certificates, DNS zones, app signing, releases, analytics history, repositories, licenses, and third-party consents.	Complete asset register, owner, admin coverage, expiry, rotation, transfer status, backup, and unresolved third-party consent.	Lower DNS TTL safely, pre-provision certificates and callbacks, coordinate app releases, rotate secrets after cutover, and retain rollback access.

Download the working inventory

Rehearse the process, not only the import

Ten controlled migration phases

Phase 1
Contract and system-of-record baseline
Signed source/target responsibility map, export right, retention and legal-hold rules, environments, owners, dependencies, and acceptance schedule.
Phase 2
Discovery export
Real schema, field dictionary, sample values, keys, history depth, attachments, encodings, volumes, delivery method, and known gaps.
Phase 3
Mapping and transformation
Version-controlled source-to-target rules, stable ID strategy, reference-data crosswalk, defaults, rejects, privacy treatment, and sign-off.
Phase 4
First full rehearsal
Timed production-scale load with technical rejects, domain control totals, journey tests, performance, and exception ownership.
Phase 5
Second rehearsal and delta proof
Repeatable full load plus change-data capture or timestamp watermark, no duplicate application, and measured cutover duration.
Phase 6
Freeze and final delta
Approved change freeze, exact transaction watermark, channel controls, callbacks, open-item ownership, and final extraction evidence.
Phase 7
Reconcile and decide
Signed financial and record totals, zero unexplained critical exceptions, RG controls active, open bets/rounds assigned, and formal go/no-go.
Phase 8
Cut over
DNS/app/API switch, production smoke tests, payments and game checks, monitoring, customer communications, and timestamped command log.
Phase 9
Hypercare and settlement tail
24/7 ownership, exception queue, old-system settlement bridge, reconciliations, incident decisions, and daily business sign-off.
Phase 10
Exit closure
Final export, retained-access inventory, third-party transfers, access removal, deletion certificate subject to retention/legal hold, and contract closure.

Go-live acceptance gates

A migration does not pass because most rows loaded. Every critical domain needs an explicit result, retained evidence, and approved exceptions.

Gate 1

Financial control totals reconcile by legal entity, brand, market, currency, product, balance bucket, and reporting period.

Gate 2

No duplicate stable IDs and no unexplained orphan relationships remain in critical domains.

Gate 3

Self-exclusions, limits, blocks, and other player-protection controls are effective before first login on the target.

Gate 4

Every open game round and sportsbook wager is migrated with preserved state or assigned to an explicit old-system settlement authority.

Gate 5

KYC, AML, complaint, and regulatory evidence is retrievable with provenance, access controls, and retained history.

Gate 6

Payment callbacks, idempotency, withdrawals, chargebacks, PSP reconciliation, and settlement continue across the cutover boundary.

Gate 7

Rollback has a decision owner, latest safe decision time, data direction, DNS/app/API procedure, and reconciliation plan.

Gate 8

Every accepted exception has severity, affected population/value, owner, workaround, deadline, approver, and contract consequence.

Cutover and rollback must share one data model

“Point DNS back” is not rollback once the target has accepted money, wagers, limits, KYC decisions, or support cases. Define how every target write is retained, reversed, or merged into the restored authority.

Control	Cutover definition	Rollback definition
Decision authority	Named go/no-go owner and domain sign-offs	Named rollback commander and delegated out-of-hours authority
Latest safe time	Start and checkpoint timestamps against the approved runbook	Last moment before new-system writes or settlements make reversal unsafe
Data direction	Final old-to-new watermark, delta, replay, and write controls	Treatment of target-system writes, deposits, bets, rounds, limits, and cases created after cutover
Traffic and channels	DNS, CDN, apps, APIs, callbacks, deep links, and customer messaging	TTL, previous origin, app compatibility, callback routing, queues, and cache purge
Financial integrity	Signed balances, open liabilities, PSP batches, GGR, and exception totals	Reconcile both systems and prevent duplicate payment, bet, win, adjustment, or withdrawal posting
Player protection	Limits, exclusions, blocks, risk cases, and support routing active before login	Merge any new target-system protection event into the restored authority before reopening

Six schedules to agree before notice is served

Schedule 1
Systems of record, legal entities, controller/processor roles, product scope, markets, environments, and third parties
Schedule 2
Data dictionary, export schema, stable IDs, history depth, attachments, formats, delivery, encryption, and incremental feed
Schedule 3
Migration services, environments, rehearsals, performance, staffing, acceptance tests, evidence retention, and remediation
Schedule 4
Cutover runbook, freeze, final delta, callbacks, open-item ownership, go/no-go, rollback, communications, and hypercare
Schedule 5
Financial and operational reconciliation definitions, control totals, thresholds, sign-off, dispute process, and regulator reporting
Schedule 6
Exit assistance, post-termination access, settlement tail, third-party consents, deletion subject to retention/legal hold, and evidence certificate

Standards establish requirements, not the supplier's export promise

GLI-19 and jurisdictional technical rules provide useful controls for accounts, transactions, interrupted play, audit, security, and recovery. The UK Gambling Commission's equipment guidance also distinguishes customer accounts, shadow wallets, gambling transaction records, results, and state. Use those sources to shape acceptance, then bind the exact export and exit obligation in the contract.

GLI-19 Interactive Gaming Systems v3.0
UKGC remote gambling equipment guidance
GDPR text, including Article 20 — data-subject portability does not replace the operator's B2B ledger, configuration, history, and exit rights.

Migration and exit questions

When should migration planning start?

Before the original platform contract is signed. Export rights, stable identifiers, retained history, post-termination access, assistance, third-party consent, settlement tail, and deletion evidence are negotiating requirements, not tasks to discover after notice is served.

Can player balances be migrated as one number per account?

Not safely. The target needs a reconciled ledger position with cash, bonus, locked, pending, reserved, withdrawable, and product balances plus the transactions and references that explain them. Manual opening adjustments need explicit controls and audit evidence.

What happens to open game rounds and sportsbook bets?

They must either move with preserved state and protocol support or remain under a named old-system settlement authority. The wallet bridge, result source, resettlement, customer display, reporting, and final reconciliation must be defined before cutover.

How many migration rehearsals are enough?

There is no universal count, but one successful sample is not production proof. This checklist requires at least two production-scale rehearsals: one to expose mapping and performance failures and another to prove the corrected full-load and delta process is repeatable.

Does GDPR data portability give the operator a full platform export?

No. Data-subject portability and the operator's B2B system, ledger, configuration, history, audit, and exit rights are different questions. The contract and technical design must grant the exact operator export and transition rights required.

RFP checklist Pricing and TCO Wallet protocol checklist