An iGaming platform migration should be treated as a controlled transfer of authority, not as a database copy followed by a DNS change. The operator must decide which system owns every player, wallet, restriction, bonus, game-round and audit state before traffic moves, then prove that the new platform can accept, operate and reconcile that state without creating a second version of the truth.
For a casino or sportsbook operator, the useful delivery artifact is a migration control pack. It joins the authority map, interface contracts, data transformations, rehearsal evidence, cutover runbook, rollback conditions and named decisions that engineering, product, finance, compliance, support and suppliers need to share.
Freeze the migration boundary before choosing the switch
The migration boundary must name the products, jurisdictions, brands, player cohorts, suppliers and operating states that will move. A programme described only as replacing the PAM or moving the casino platform is too vague to test because it does not state whether wallet history, open rounds, bonuses, self-exclusions, identity evidence, reporting or support cases are inside the change.
Start with a system and data inventory. Record the current owner of registration, verification, authentication, product eligibility, customer funds, bonuses, limits, exclusions, game sessions, settlement, reporting and communications. Add every external interface, including payment providers, identity services, game aggregators, remote game servers, geolocation, CRM, fraud tooling, data warehouses and regulatory reporting.
The UK Gambling Commission’s remote gambling equipment guidance separates customer accounts, gambling transaction records, virtual-event state, settling and external interfaces as distinct components. That guidance applies to its regulatory context, but the component model is a useful warning for any migration: a customer balance is connected to transaction and game state, not an isolated number in one table.
Turn the inventory into an explicit scope decision. Anything deferred needs an owner, an interim interface and a retirement date. Anything included needs a source, target, transformation, acceptance test and rollback treatment.
Build an authority map for every critical state
The authority map should assign exactly one system of record to every critical state during each migration phase. It should cover the current platform, rehearsal environment, shadow or comparison path, cutover window and post-cutover period rather than assuming that authority changes everywhere at once.
Player identity illustrates why this matters. A player record may include identity evidence, account status, authentication credentials, communication choices, market eligibility and links to payment instruments. A successful row count does not prove that the target preserved the state that allows, restricts or blocks an action.
Wallet and round state require the same precision. The Commission guidance describes the customer account as tracking balances and transactions into and out of the account, linked to gambling transaction records and potentially to shadow wallets. It also notes that virtual-event state may be needed to recover interrupted gambling. The migration map should therefore distinguish cash, restricted or incentive value, pending withdrawals, unsettled wagers, held funds, completed transactions, reversible transactions and open-round state.
For each state, define who may write it, how changes are ordered, which identifier survives the move and how a support or finance team will trace it. A dual-run is safe only when it has one authority per state; two independent writers do not create redundancy.
Contract every interface and failure response
Migration interfaces should be specified as versioned contracts before data rehearsals begin. The OpenAPI Specification 3.1 provides a language-neutral way to describe HTTP paths, operations, components and webhooks, which makes it suitable for freezing the expected shape of synchronous APIs and callback boundaries.
The contract must go beyond a successful request example. Define stable player, account, transaction, round and supplier identifiers; authentication and authorization; ordering; retry behavior; duplicate handling; time zones and decimal precision; pagination; callback verification; rate limits; timeouts; and the lifecycle of every status. Include error semantics that a consumer can act on rather than a collection of free-text messages.
Contract review is also a security review. The OWASP API Security Top 10 for 2023 calls out broken authorization, unrestricted access to sensitive business flows, improper API inventory management and unsafe consumption of third-party APIs. A migration temporarily increases all four risks because old and new endpoints, bulk tools and supplier connections may coexist.
Prove the transformation through reconciliation
Reconciliation must prove preserved meaning, not merely matching record counts. A rehearsal should run the real extraction and transformation code against a representative, access-controlled copy, produce a signed or otherwise immutable run identity, and explain every rejected, changed or missing record.
Use several layers of comparison. Aggregate controls can compare total cash, restricted value, pending withdrawals and open liabilities by currency and brand. Player-level controls can compare balances, status and linked transaction totals. Lifecycle controls can compare deposits, withdrawals, wagers, wins, refunds, adjustments and reversals by stable identifier. State controls can verify limits, exclusions, identity status and open rounds.
No unexplained adjustment should be used to force two totals to match. Exceptions need a category, evidence, owner, deadline and disposition. The decision may be to transform, remediate before cutover, retain the legacy resolver, exclude a record under an approved rule or stop the migration. The important point is that the result remains inspectable.
This evidence should feed observability before launch. The existing guide to RGS observability for game rounds shows how correlation identifiers can connect client, RGS and wallet events; a migration needs the same traceability across old and new platform boundaries.
Protect open rounds, balances and player restrictions
Open rounds, balances and player restrictions are cutover-critical because each can change while the migration is running. A snapshot taken too early can omit a later restriction or transaction, while a snapshot taken without a write strategy can race the source system.
Choose an open-round policy with the game, RGS, wallet, support and compliance owners. Options include draining open rounds before the window, keeping the legacy round resolver available until they complete, or moving them only when the target preserves the authoritative state and settlement path. The GLI-19 Interactive Gaming Systems standard treats player-account information, transaction history and interrupted games as connected system responsibilities; section 4.16 requires held wagers and completion state to be reflected in game history and the player account.
Restrictions need a separate last-change check. A player exclusion, limit, lock, identity decision or jurisdictional eligibility change that lands during the window must reach the system that will accept the next session or wager. Test a denied action as carefully as a successful one.
The same principle applies to reconnect and retry behavior. The guide to resilient casino game sessions explains why authoritative round identifiers and idempotent commands matter after a disconnect. During migration, those controls must also survive a change of platform boundary.
Classify the release and assemble its evidence
The release plan must classify which platform and game changes require internal testing, independent testing or regulator-facing evidence in each jurisdiction. This is a decision for the operator and its qualified advisers, not a universal conclusion that can be copied from one market to another.
For Great Britain, the Commission’s testing strategy good-practice section says critical system changes should have a documented change-management plan with adequate testing, change controls and authorizations for migration into the operational environment. Its testing procedure says an RGS or RNG change that could affect game functionality and fairness may require representative retesting agreed with an approved test house before launch.
The migration control pack should therefore connect each changed component to its jurisdiction, classification decision, test owner, environment, evidence and approval. Preserve the exact source and target versions, transformation version, interface specifications, test data provenance, results, exceptions and authorizations. A green dashboard without this chain is an operating signal, not release evidence.
Cut over with stop conditions and a rehearsed rollback
The cutover runbook should be executable as a timed sequence with named owners, observable gates and predefined stop conditions. It should state when writes pause or reroute, when the final delta is captured, how restrictions and balances receive their last comparison, how suppliers switch, how caches and sessions behave, when smoke tests begin and who can declare the new platform authoritative.
Stop conditions must be specific enough to act on. Examples include an unexplained balance variance, a missing restriction change, unresolved open rounds, failed payment or game-provider callbacks, broken audit continuity or monitoring that cannot distinguish old from new traffic. Define the allowed tolerance only where the underlying state genuinely permits one; do not invent a tolerance for money or eligibility merely to keep the window moving.
Rollback is a business-state restoration plan, not only a software deployment. It must say which writes occurred after the switch, how they return to the prior authority, how duplicate or conflicting transactions are prevented, what happens to new registrations and open rounds, and how players and suppliers are informed. Rehearse the rollback path with the same transformation and reconciliation discipline as the forward move.
Procurement should require a migration control pack
Procurement should require evidence that the delivery partner can control the state transition, not merely export and import data. The response should include the source inventory, authority map, field and state mappings, interface contracts, transformation tooling, rehearsal plan, reconciliation controls, open-round policy, jurisdictional test plan, cutover runbook, rollback proof, monitoring and named exception owners.
Acceptance criteria should be observable. Ask the vendor to demonstrate a changed player restriction, a pending withdrawal, a duplicate callback, an interrupted game, a failed supplier switch and a rollback after controlled post-cutover writes. Require the resulting records to be traceable by stable identifiers.
For operators preparing a PAM, wallet, RGS or full-stack transition, Wizards can turn the current system inventory into a migration control pack and implementation scope through a platform development engagement. Talk to Wizards about the jurisdictions, suppliers and operating states the first rehearsal must preserve.
Frequently asked questions
What should an iGaming platform migration plan include?
An iGaming platform migration plan should include a product and jurisdiction scope, an authority map for every critical state, versioned interface contracts, transformation rules, rehearsal and reconciliation evidence, an open-round policy, cutover criteria, named owners and a tested rollback route.
How should player balances be migrated?
Player balances should be migrated from a frozen authoritative source with immutable transaction references, explicit treatment of pending and restricted funds, aggregate and player-level reconciliation, exception ownership and no unexplained adjustment used to force the totals to match.
What happens to open game rounds during cutover?
Open game rounds should follow a documented policy agreed with platform, game, wallet and compliance owners. The operator may drain them before cutover, keep the legacy resolver available for completion or move only when the new platform can preserve the authoritative round state and settlement path.
Should an operator run both platforms in parallel?
A bounded parallel run can provide useful comparison evidence, but only when one system remains authoritative for each state and every mirrored write is controlled. Two independent writers for balances, limits or round settlement create ambiguity rather than safety.
When should a platform migration roll back?
A platform migration should roll back when a predefined stop condition is crossed, such as unexplained balance variance, missing restriction state, unresolved open rounds, broken critical integrations or loss of audit evidence. The trigger, decision owner and restoration procedure should be rehearsed before the window.
What evidence should a platform migration vendor deliver?
A platform migration vendor should deliver the source inventory, field and state mappings, interface specifications, transformation code and version, test evidence, reconciliation reports, exception register, cutover runbook, rollback proof, monitoring plan and named ownership for unresolved items.
