How to Migrate an iGaming Platform

Start with a system and responsibility map, not the target vendor's import template. List the PAM, wallet and ledger, sportsbook, casino remote game servers and aggregators, payment services, identity and verification services, safer-gambling controls, CRM, bonus engine, affiliate tracking, data warehouse, reporting, customer support, fraud and AML case tools, regulatory feeds, finance systems, and every manual process that reads or changes customer state. Record the legal entity, product, market, environment, supplier, interface, data owner, operational owner, and upstream and downstream dependency for each item.

For every dataset and workflow, name the source of truth before, during, and after cutover. The answer can change by phase, but it cannot be ambiguous. A target database may hold a copied wallet record while the legacy ledger remains authoritative; a sportsbook may own settlement while the PAM owns the cash posting; a self-exclusion service may remain authoritative even after the account record moves. Write those boundaries as state transitions rather than a diagram with unnamed arrows.

The operator release owner should control the final go or stop decision. Suppliers can own delivery tasks and provide technical sign-off, but their completion notice is not operator acceptance. Give named owners authority over data, wallet and finance, sportsbook and casino state, payments, compliance, privacy, security, customer operations, regulatory communication, and rollback. Record which approvals are mandatory and who can stop the window without commercial escalation overriding the control.

Treat identifiers as part of the financial and regulatory evidence. Preserve the legacy player ID, account ID, wallet and ledger entry ID, payment reference, bet and selection ID, game round and transaction ID, bonus and promotion ID, limit and exclusion ID, compliance case ID, support ticket ID, affiliate and campaign ID, device or session reference where retained, content ID, and the relationships among them. If the target requires a new internal key, keep a durable one-to-one translation record with the source system, source key, target system, target key, mapping rule, migration run, timestamp, and exception state.

Do not silently collapse records because the target has a simpler model. One person may have multiple brand accounts, wallets, currencies, product wallets, historic identities, or status periods. Conversely, duplicate legacy accounts may require a controlled merge decision. Record which relationships remain separate, which are linked, and which are deliberately consolidated, with the legal and operational authority for that choice. Unresolved many-to-one or one-to-many mappings are migration defects, not formatting problems.

Normalize representation without rewriting history. Fix timezone and daylight-saving rules, currency precision, sign conventions, status vocabulary, nullable fields, enumeration mappings, character encoding, and date boundaries in a versioned transformation specification. Preserve raw source values or a reproducible source extract for investigation. Database replication features do not automatically carry every schema or sequence behavior, so the migration design must test the exact source and target rather than assume that replicated rows make the target ready to accept writes.

A displayed balance is not the wallet. Reconcile the opening ledger, every migrated debit and credit, held or ring-fenced funds, pending deposits and withdrawals, chargebacks, manual adjustments, bonus balances, jackpot liabilities, product transfers, and the closing balance by player, wallet, currency, legal entity, and accounting period. The acceptance record should explain every difference; an unexplained difference cannot be hidden inside a net total that happens to match.

Freeze a product-specific state catalog before writing transformations. Sportsbook states may include requested, accepted, rejected, partially accepted, open, cashed out, void, settled, resettled, and disputed, with selections and external feed references beneath the bet. Casino state can include a reserved debit, accepted debit, open round, feature or bonus state, pending credit, rollback, completed round, jackpot contribution, and progressive state. Payment, bonus, poker, bingo, lottery, and other products need their own contracts. Do not force all products through a generic open or closed flag.

Choose one documented treatment for every in-flight state: migrate and continue, leave on the legacy system until resolved, settle before the freeze, or apply a specifically authorized cancellation or refund path. A blanket refund is not a safe default because rules, supplier protocols, market requirements, tax, bonus treatment, and player outcomes differ. For an interrupted game that can be continued, GLI-19 expects wagers to remain held until completion and the player account to reflect those held funds; it also describes recovery of unresolved play. The exact implementation and receiving-market requirement still need confirmation for the contracted product.

Run the migration against production-shaped volume and relationships in an approved environment. A masked dataset can protect people while preserving account-to-wallet-to-transaction-to-bet relationships, but masking itself needs validation because it can destroy uniqueness, dates, status sequences, or reconciliation keys. Before live personal data is copied outside production, record and approve its purpose, necessity, environment, access, security, retention, and deletion controls.

Use several layers of validation. Database tools can compare rows and report pending, mismatched, suspended, missing-primary-key, and error states. That is useful evidence, but it does not prove that a limit has the right effective date, a bet can settle, a round can resume, a withdrawal remains payable, a regulatory return is unchanged, or a customer can see a complete statement. Add domain comparisons for counts, sums, state transitions, relationships, referential integrity, duplicate detection, financial reconciliation, customer journeys, report outputs, and exception replay.

Version the source extract, transformation code, configuration, schema, mapping tables, target load, validation queries, exception decisions, and result pack for every rehearsal. A pass from an earlier run does not cover a changed mapping or target release. Rehearse the final source-delta method, duration measurement, failure recovery, and rollback steps with the same owners who will operate the production window. Repeat until every mandatory gate passes; do not invent a standard number of rehearsals or a universal acceptable mismatch rate.

A dual run should not mean two independent platforms changing the same customer state. Keep one write authority for each record and use replication, event capture, controlled replay, or an explicitly designed transition service to feed the other environment. If the target runs in shadow mode, disable real-world side effects such as payouts, payment requests, emails, SMS, CRM campaigns, regulatory submissions, supplier settlements, bonus issuance, and account interventions unless that exact action is part of the controlled test.

Reconcile from a shared watermark. Track source changes captured, target changes applied, lag, rejected or quarantined events, duplicates, reordered events, missing dependencies, replay attempts, and the highest complete sequence for each stream. Measure business outputs as well as technical delivery: wallet postings, balances, open liabilities, bet and round status, payment status, limits and exclusions, account blocks, regulatory aggregates, finance totals, and customer statements.

Partial traffic can reduce exposure only when the architecture can assign customers, wallets, products, and external callbacks to one coherent state owner. A customer cannot safely deposit in one system while an open bet settles into another unless the wallet and idempotency design explicitly supports that path. The duration of the parallel run should be set by coverage of the operator's settlement cycles, reports, peak loads, delayed callbacks, and exception types; a calendar period by itself is not proof.

Write the cutover runbook as an ordered control record with entry criteria, owner, expected duration, command or action, evidence captured, success condition, stop condition, and dependency for every step. Include customer entry controls, maintenance or read-only mode, source ingestion freeze where required, final backup, last change capture, target apply, financial and state reconciliation, credential and endpoint changes, traffic routing, smoke tests, monitoring, supplier confirmation, business approval, and the exact point at which the target becomes authoritative.

Define rollback triggers before the window. They can include an unexplained financial difference, missing restriction, unresolvable open state, failed payment or settlement path, material performance loss, security event, unavailable regulatory report, or loss of required support. Each trigger needs a measurement, decision owner, latest safe decision point, and data treatment. Avoid a vague instruction to roll back if there are issues.

Rollback is materially different before and after the target accepts new writes. Before new production state exists, restoring source authority and traffic may be straightforward. After deposits, withdrawals, bets, rounds, limits, or cases have changed on the target, the source is stale. The plan then needs a tested reverse-sync or fail-forward destination, conflict rules, idempotent replay, and reconciliation of every post-cutover action. AWS guidance explicitly separates rollback with and without changed data; a DNS reversal alone does not repair the ledger.

Do not assume that every platform migration needs the same player notice or that a backend supplier change is invisible. Assess changes to the contracting or licensed entity, controller and processor roles, recipients and subprocessors, data locations, purposes, privacy information, terms, authentication, account access, payment routes, customer-funds arrangements, balances, bonuses, open bets or games, statements, support, planned unavailability, and customer rights. Communicate the material change in plain language through the channels and lead time required for that market and contract.

Build a jurisdiction-by-jurisdiction notification matrix with the rule, trigger, owner, authority, submission method, required evidence, deadline, approval state, and dependency on testing or certification. Some changes may be reportable before release, some after an event, some only when a named system, payment arrangement, data flow, license detail, or certified component changes, and some may not require a filing. The Great Britain LCCP, for example, identifies specific key events including certain payment-arrangement changes, a breach that adversely affects customer-data confidentiality or prevents legitimate account access for more than 12 hours, and gaming-system faults causing incorrect player payments. That example is not a universal migration notification rule.

Align third parties as well. The legacy and target platform, game and sportsbook suppliers, payment providers, identity services, banks, testing laboratory, data protection contacts, customer support outsourcers, affiliates, auditors, and reporting recipients may need an endpoint, credential, entity, file, schedule, or responsibility change. Keep delivery confirmation and rejected-message handling. A notice marked sent is not complete if the recipient did not accept the change or the operating team still uses the old route.

Use separate gates for scope, identity, data, money, open product state, regulated controls, privacy and security, integrations, operations, performance, cutover, rollback, and exit. A green average is unsafe because excellent performance cannot offset a missing self-exclusion, and a complete row count cannot offset an unreconciled player liability. Each gate should show pass, block, or an explicitly permitted exception with evidence, owner, expiry, compensating control, and final approver.

Set thresholds from the actual product and risk. Record counts and tolerances where rounding, timing, or known transformation differences are legitimate, but do not label unexplained money or missing mandatory control state as an acceptable statistical variance. Test all target markets, legal entities, currencies, products, account statuses, restriction types, payment routes, supplier protocols, and production configurations in scope. Anything not tested should be listed as excluded or blocked, not silently treated as passed.

Keep the signed gate pack with the exact source snapshot, migration build, target release, configuration, evidence, defects, waivers, approvers, and timestamp. If the data, code, mapping, configuration, supplier version, or release population changes materially, identify which gates must run again. The acceptance record should be reproducible by a team that did not attend the cutover call.

The release decision starts a controlled warranty period; it does not end the migration. Keep a single exception ledger for customer, financial, product, compliance, technical, security, supplier, and reporting issues. Each item needs the affected records, severity, customer or liability impact, containment, owner, source and target evidence, correction method, approval, retest, and closure. Direct production data fixes without a retained before-and-after record create a second migration problem.

Reconcile on the cadence required by the actual processes in scope. Cover deposits and withdrawals, payment settlement and chargebacks, wallet and product balances, open and settled bets, game debits and credits, jackpot and bonus liabilities, customer statements, affiliate and supplier calculations, finance postings, safer-gambling and AML workflows, complaints, and regulatory submissions. Delayed callbacks and resettlements mean a clean first hour cannot prove later state.

Set warranty exit criteria before cutover. They can include completion of the scoped settlement and reporting cycles, no blocked or unexplained migration exceptions, passed backups and restore, stable monitoring, accepted supplier and finance reconciliations, completed regulatory actions, support handover, and approved residual-risk ownership. The necessary observation period varies by product, market, volume, settlement cycle, and contract; do not use a generic number of days.

Keep the legacy environment available only for defined operating, recovery, dispute, audit, reporting, legal, and regulatory purposes. The retained package may need a read-only application, searchable exports, schemas, data dictionaries, mapping records, game and bet history, financial and compliance evidence, report logic, encryption and signing keys, supplier documentation, credentials under controlled access, and a support route. A raw database dump that the operator cannot interpret or restore is not usable exit evidence.

Create a dataset-level retention and access schedule. Record the purpose, legal or regulatory basis, controller and processor, location, access group, format, integrity control, availability requirement, retention trigger, review date, deletion or anonymization method, backup treatment, and evidence owner. Data-protection rules do not provide one universal retention period for all personal data; the operator must justify each period and also preserve records required by gambling, AML, tax, accounting, dispute, or other applicable rules.

Decommission only after the target and its contingency capability are accepted, post-cutover reconciliations close, retained evidence is readable, required reports can be reproduced, contract and regulator actions are complete, and the rollback decision point has passed under the approved plan. Then remove write paths, external callbacks, scheduled jobs, credentials, privileged access, DNS and routing dependencies, licenses, infrastructure, and supplier connections in a controlled order. Obtain return or deletion evidence from processors, including the documented treatment and later deletion cycle for backups that cannot be erased immediately.