Casino platform migration is the move of a gambling service from one technical stack to another. A usable transfer preserves more than login details and the displayed balance: it must account for unsettled transactions, game state, restrictions and the evidence behind each account. Switching platforms does not itself establish a new operator's permission to serve players.
This guide gives operations teams a practical acceptance matrix and includes checks players can use after a change. The matrix is an editorial proposal, not a regulator-issued standard or a tested supplier implementation. British regulatory examples are identified separately; legal, contractual and technical requirements need review for each market. Sources were checked on 10 October 2026.
Define what is changing before moving accounts
A replacement front end, a new wallet and a different legal operator are different projects. Write down which entity will contract with customers, which component will own the ledger, and which services will continue handling existing games and payments. A brand name staying the same answers none of those questions.
The Gambling Commission's equipment guidance distinguishes customer wallets, gambling transaction records and stored event state. Its diagrams describe functions rather than a prescribed system architecture. That is a useful starting point for identifying what a technical move actually touches, without treating the guidance as a migration approval.
Our PAM explainer describes the account control layer. This article addresses the handover: what proves that the replacement system has received a complete, usable account, and what should prevent it from reopening an incomplete one. The white-label versus turnkey comparison covers the separate procurement and responsibility questions.
A matching total can conceal a wrong account
Reconcile money by player, currency and balance category before comparing aggregate totals. Cash available to withdraw, restricted bonus credit and money committed to an unfinished round should not be flattened into a single opening value. A total can match even when one player's missing credit offsets another player's duplicate credit.
For example, suppose two hypothetical cash accounts should carry 80 and 120 units into the new ledger. Importing 90 and 110 still produces a total of 200, but both accounts are wrong. These are invented arithmetic inputs, not observed player balances. A row-level comparison exposes the discrepancy that the combined total misses.
Maintain a link between every imported opening balance and the source record used to calculate it. Record how pending withdrawals, reversals and late game settlements will be handled. When an external service confirms an event after the transfer, the reconciliation needs to establish whether that event was already included. The payment-orchestration guide explains the related duplicate-event problem.
Acceptance matrix for the account handover
Use the following as a working specification. Add an accountable reviewer and a retained test result for each row. The suggested evidence and stop conditions are BetTimes analysis; they do not imply that a particular regulator requires this field layout.
| Record | Evidence to retain | Stop condition |
|---|---|---|
| Account identity | Source-to-target identifiers, currency and account status | Two records merge incorrectly or one player gains another player's history |
| Cash and bonus balances | Per-account reconciliation with category definitions and adjustments | An unexplained difference remains or restricted credit becomes withdrawable cash |
| Pending payments | Original payment reference, status and nominated processing system | A withdrawal is duplicated, lost or treated as completed without confirmation |
| Open rounds and bets | Accepted wager, recorded state and settlement owner | Neither system can finish or reconcile an accepted transaction |
| Verification and case records | Check date, evidence reference, decision and active restriction | A copied status has no supporting record or an unresolved restriction disappears |
| Financial limits | Limit type, amount, period, consumed allowance and pending changes | A restart grants fresh allowance inside an existing limit period |
| Self-exclusion and account blocks | Identity match, scope, effective records and enforcement tests | An excluded account can gamble or enters a marketing audience |
| Consent and account history | Purpose-specific preferences, notice version and retrievable history | A refusal becomes consent or required history cannot be produced |
Test negative cases as well as successful transfers. An excluded player failing to log in can be a correct outcome; an active player reaching the lobby is not enough to demonstrate correct balances or limits. Use synthetic records in rehearsals and handle any necessary real personal data under the applicable security and data-protection arrangements.
Preserve limit meaning, not just the number
A stored limit of 100 is incomplete without its type, currency, time period and consumption. A gross deposit limit and a net deposit limit measure different activity. Importing the amount into a field with a different definition can change the practical restriction even when the interface shows the same number.
For British deployments, RTS 12 requires account-level financial limits as a minimum. Customer-led increases require a request, a cooling-off period of at least 24 hours and positive confirmation afterwards. Reductions must be immediate unless technical failure prevents this. A migration test should therefore inspect pending changes and elapsed time as well as the active value.
The Commission's 26 May 2026 implementation notice put the revised gross-deposit-limit requirements into effect from 30 September 2026, including fixed time frames for gross deposit limits. Its implementation explanation expressly says existing customers were not expected to be switched back to gross limits on that date. A platform move should not be described as permission to reset or silently redefine their choices.
Exclusions and unfinished games need explicit decisions
In Great Britain, LCCP 3.5.3 requires applicable remote licensees to prevent self-excluded customers from gambling, suppress relevant marketing, close their accounts and return funds held. A migrated exclusion record is evidence for enforcing that restriction, not an active account to reopen. Marketing suppression needs testing outside the gambling front end too.
For gaming covered by British RTS 10, the recorded state matters. A result should stand once the operator has received the gamble and the player can no longer influence it; an undetermined single-player, single-stage event has a different treatment. Stateful games require reasonable steps towards restoration. The disconnection guide explains those branches. A migration does not make every unfinished game a refund or authorise discarding its existing result.
Operationally, nominate who will settle each open item after the change. If an old game service remains responsible, the new account system still needs a traceable route for its result. Rehearse a late settlement and a duplicate message against the same record rather than assuming the interface change resolves them.
Review data roles when the organisation changes
A supplier replacement does not necessarily change the data controller. A transfer to a different or additional controller raises a separate due-diligence question. Identify the actual processing roles and purposes rather than assuming that a data-export clause settles every privacy issue.
The ICO's merger and acquisition guidance calls for examining the original purposes, lawful basis, transparency and security of a controller-changing transfer. It also warns that incompatible systems can lose or corrupt data. The page is under review following the Data (Use and Access) Act, so it should not be treated as a complete, final answer to an individual transaction's legal position. Obtain current specialist advice where that position is material.
For the project specification, keep consent and communication preferences tied to their purpose and history. Do not turn an empty imported field into permission to market. Preserve access controls and a usable audit trail; exporting verification documents does not justify distributing them broadly to migration staff.
Decide when to switch and when to stop
Before cutover, agree the record boundary: which events the initial export includes, how later changes arrive, and when the replacement starts accepting new activity. Without that boundary, a deposit between export and launch can disappear from both opening records or be counted twice.
Require sign-off on account-level reconciliation, open-item ownership, restriction enforcement and support access. Assign each unresolved exception an owner and a disposition. A missing exclusion, an unexplained cash difference or an accepted game with no settlement route is a reason to hold the affected service or account rather than hide the discrepancy in a launch total.
Define rollback before new transactions begin. Restoring a snapshot after the replacement has taken deposits or settled games can discard those later events. The return path needs to account for activity on both systems and prevent duplicate processing. Timings and tolerances are project decisions, not industry benchmarks, and this article promises neither zero downtime nor a universal safe migration duration.
What players can check after a platform change
Save the operator's notice and compare balances, outstanding withdrawal references, account restrictions and available history. Ask support to reconcile a specific missing entry in writing, including its date, currency and transaction identifier. Do not start a new wager merely to test whether an unfinished one has been restored.
For British services, RTS 1 requires easy access to at least three months of account and gambling history without contacting the licensee, with at least 12 months available on request. A new interface should not be confused with a new starting date for those records. Our British complaints and ADR guide explains the escalation route and its limits if the operator cannot resolve a transaction dispute.
Frequently asked questions
Does changing casino platforms mean changing operator?
Not necessarily. A business can replace technology while the same licensed entity continues contracting with customers. A brand can also change legal operator during a wider transaction. Check the customer terms and regulator record separately; the platform supplier's name alone does not establish either outcome.
Is matching the total player balance enough?
No. Matching totals can conceal opposite errors across individual accounts or balance categories. Compare each account, currency and category, then reconcile pending payments and unfinished games. A total is a useful additional check, but it does not demonstrate that every player has received the correct account state.
Can a migration reset self-exclusion or a deposit limit?
A technical move should not be treated as a customer's request to remove a restriction. In the British examples here, self-exclusion duties and the rules for customer-led limit changes remain relevant. Verify the actual exclusion scope and limit definition; do not assume that a replacement account is unrestricted.
Keep the handover evidence available
Retain the source record, mapping, reconciliation and exception decision needed to explain each transferred account. The useful acceptance question is whether the operator can demonstrate what happened to a particular player's money and restrictions, including events received after the switch. A successful login or a supplier's launch announcement cannot answer that question.