How casino platform migration works, step by step

Operators put off changing platform because they imagine losing players. In practice the player base is the most portable part of the whole arrangement. What takes the time is everything around it: payment providers, certification, and whatever your current contract says about your own data.

This is the sequence we work through, in the order it needs to happen.

Step 1: Audit what you depend on

Four questions, answered honestly, tell you how hard your migration will be.

Question	Why it matters
Who can export your player data, and how fast?	This is the clause the whole project rests on. Discretionary timing on the provider's side is a red flag.
Whose name is on the game contracts?	Aggregated supply does not travel with you. Direct studio contracts do.
Whose name is on the payment contracts?	Contracts in the provider's name mean starting fresh with every PSP, which is the longest task in the project.
Who is the registrant of the domain?	If it is not you, fix that before you raise the subject of leaving.

Step 2: Request a test export in writing

Do not wait for the end of the project to find out what the export actually contains. Ask early, in writing, for a sample covering the five things that matter: player records, wallet balances, bonus state, KYC outcomes, and the responsible gambling flags. What comes back tells you whether this is a four week project or a four month negotiation.

A provider who sends a clean sample export within a week is a provider you can leave calmly. A provider who cannot describe the format is telling you something useful.

Step 3: Configure the new platform while payments run in parallel

Platform configuration is the predictable part: brand and lobby, game selection, bonus rules rebuilt to match what players currently have, back office roles, reporting, and the responsible gambling tooling your market requires.

Start the payment conversations on day one of this step, not after it. Every PSP will run its own due diligence on the new technical setup, and some will want a new integration test. This is the single most common reason a cutover date slips, and it has nothing to do with the platform.

Step 4: Test import, then reconcile record by record

Import a representative sample rather than the whole base, and check it properly. The cases worth checking individually:

• Open bonuses. Remaining wagering requirement, eligible games, expiry date. These must survive intact or players lose value on cutover day.
• Partially verified players. Someone who submitted one of two documents must not land as unverified and get blocked at their next withdrawal.
• Self-exclusions and limits. Deposit limits, loss limits, time-outs and self-exclusions must carry across exactly. Getting this wrong is a regulatory incident, not a bug.
• Pending withdrawals. Decide explicitly whether they are settled on the old platform before cutover or carried to the new one. Settling them first is cleaner.
• Dormant and closed accounts. They still carry retention obligations even though they will never log in again.

Step 5: Notify the regulator

In most regulated markets the platform is a critical supplier, and changing it is a notifiable event. The new platform will also need to be certified for your jurisdiction by an accredited test house. Neither step is usually difficult, but both have lead times set by other people's calendars, so they belong in the plan early. More detail in what a casino licence actually requires.

Step 6: Cut over

Pick your lowest-traffic hour. Freeze transactions for 30 to 60 minutes, take the final snapshot, import, reconcile the totals, then open. A short, announced maintenance window is far safer than an ambitious attempt at zero downtime, because a freeze with no in-flight transactions is what lets balances match to the cent.

Keep the old platform readable afterwards. You will want it for reconciliation queries, for complaint handling, and because your retention obligations do not end when your contract does.

What players actually notice

Done properly, almost nothing: a maintenance window, and a one-time password reset because password hashes rarely move between platforms. Everything else, including balances, bonuses, history and verification status, should look exactly as it did. Tell them in advance about the password step and the support load stays manageable.

How we handle it

We treat migration as part of a launch rather than a separate professional services project, because for most of our conversations it is the actual job. Player data, wallets and open bonuses come across, and the reconciliation sample is something we work through with you rather than hand over as a report.

The casino platform overview covers what is included once you are live. If you are weighing up a move, send us your setup and we will tell you where the hard parts are for your specific case, including the ones that are not ours to solve.

Questions we get asked