Every migration proposal you will read describes a data import. That is the easy part. The difficult part is that a casino does not stop trading while you move it, so every decision has to be made twice: once for the history and once for what is happening right now.
This is what the work actually consists of, in the order it usually happens.
Discovery is mostly an inventory, not a design exercise
Before anything is planned, five lists have to exist and be accurate.
- Brands and domains. Every live brand, every domain, every certificate, and who holds the registration for each.
- Players. How many accounts, how many with a balance, how many verified, and how many are dormant under whatever definition your jurisdiction uses.
- Providers. Every game studio, aggregator, payment provider, verification provider and affiliate platform currently connected, with the contract holder for each.
- Obligations. Reporting deadlines, regulator commitments, self-exclusion registers you are enrolled in, and any open regulatory correspondence.
- Anything custom. Every report, integration, bonus mechanic or workflow that exists because somebody built it for you. This list is always longer than the operator expects.
The last one is the risk. A migration that fails usually fails because a report that finance depends on every Tuesday was never on the inventory.
Player identity is the first real decision
Players do not migrate. Player accounts migrate, and the person behind the account has to be able to log in afterwards.
Three questions decide most of the plan.
Do credentials transfer? Password hashes are sometimes portable and sometimes not, depending on the algorithm the old platform used and whether the export includes them. If they are not portable, every player resets their password on first login, which means the communication plan is part of the migration plan rather than an afterthought.
Does verification evidence transfer? This is the one that costs money. If the verification evidence transfers in a form your new provider and your regulator both accept, a verified player stays verified. If it does not, you are asking your entire active base to upload documents again, and a meaningful share of them will not.
On our platform a person verified once stays verified for every future brand in the group, which is a property of the identity model rather than a migration feature. Whether the evidence from your previous platform can carry into it depends on the provider it came from and the format it is in, and that is a discovery question with a real answer rather than a promise.
What happens to accounts under restriction? Self-excluded, suspended, frozen and closed accounts must arrive on the new platform in the same state, on day one, before anybody can deposit. This is the single most important correctness requirement in a migration and it is worth a dedicated test.
Money is a reconciliation problem, not a transfer problem
Balances do not move. They are stated on the old platform, stated on the new one, and reconciled between the two.
Four categories behave differently:
- Real balance. The player's own money. It must reconcile exactly, and the reconciliation has to hold at a fixed point in time, which is why deposits are usually stopped for a window.
- Bonus balance. Money the player has not yet earned the right to withdraw. It carries wagering progress, expiry and eligibility rules with it.
- Locked or pending balance. Withdrawals requested and not yet paid, deposits confirmed and not yet credited, and anything sitting in a review queue.
- Crypto balances. These carry a conversion question as well as a reconciliation question. Decide the settlement currency and the rate source before the cut-over, not during it.
The practical answer is a freeze window: deposits and withdrawals stop, the ledger is closed, the balances are exported, imported and reconciled line by line, and only then does trading resume. Everybody wants that window to be short. It should instead be long enough that nobody is reconciling under pressure.
Bonuses are where migrations quietly go wrong
An active bonus is a contract with a player. It has a reward, a wagering requirement, a progress figure, a game weighting, an expiry and often a maximum bet while it is active.
Three options, and all three are legitimate:
- Migrate the bonus state. Cleanest for the player, hardest technically, because two bonus engines rarely agree on how progress is calculated.
- Settle bonuses before the cut-over. Let everything expire or complete under the old rules, and start the new platform clean. Cheapest and most predictable, but it changes the offer some players thought they had.
- Honour them manually. Fine for a small number of high-value players. Not a plan for thousands.
Whichever you choose, decide it early and write it into the player communication, because the alternative is a support queue full of people who believe they have been robbed of a wagering balance and are, from where they are standing, correct.
The audit trail has to survive
Your regulator does not care that you changed platform. If they ask about a transaction from fourteen months ago, the answer has to exist.
Two workable approaches:
- Import the history into the new platform, so one search covers everything.
- Freeze the old system as a read-only archive for the retention period, and document exactly where the boundary is.
Both are acceptable. What is not acceptable is discovering after the old contract lapses that the archive went with it. Settle the retention period, the access method and who pays for the archive before you sign the termination notice.
Payment and content contracts are yours to move
This is the part operators underestimate most often, because it is not technical work at all.
If you hold the licence, you usually hold the payment relationships, and each one has to be re-pointed at the new platform. That means new integration credentials, new settlement instructions, and in several cases a fresh risk review by the payment provider, on their timetable rather than yours.
Game content is similar. Aggregator agreements can sometimes be re-pointed. Direct studio agreements often cannot, and the studio may need to approve the new deployment before its games appear in your lobby. Start those conversations in discovery, because they are the item most likely to move your launch date.
What does not move
Some things cannot be migrated, and a plan that assumes they can is a plan that fails in the last week.
Passwords. Credentials are stored as hashes, and the two platforms rarely agree on the algorithm. Assume a reset for every player, and write the email that explains it before you need it.
Payment tokens. The card and account tokens held by your old payment provider belong to that provider. Returning players will re-enter details unless the same provider follows you.
Provider side campaigns. Free spin campaigns configured inside a game studio's own system are tied to the integration that created them. They stop, and they are rebuilt on the new side.
Reports built on the old schema. Any dashboard your team wrote against the previous database is a rewrite. Inventory those early, because the person who built them has usually left.
None of this is fatal. All of it is worse when it is discovered in the final week.
The cut-over itself
A cut-over that goes well is boring. It usually looks like this:
- Freeze. Deposits and withdrawals stop at an announced time. The old platform stops accepting new registrations.
- Final export. Players, balances, verification states, restrictions, bonus state and the ledger.
- Import and reconcile. Every category checked against the source. Restrictions checked first, then real balances, then everything else.
- Verify in production. A real deposit, a real bet, a real withdrawal, a real verification, and a restricted account that is correctly refused.
- Open. Traffic moves. The old platform stays available in read-only mode.
- Watch. For at least a full weekly cycle, because weekend traffic, weekly bonuses and Monday reporting all behave differently.
How long it takes, honestly
Provisioning an environment takes hours. Migrating a live casino into it does not, and any provider who quotes you a single number without seeing your inventory is quoting a wish.
The variables that actually drive the timeline are the number of live brands, whether verification evidence transfers, how many payment and content contracts have to be re-pointed, and how much custom work exists that nobody documented. Two operators of identical size can be three months apart on those four questions alone.
What we can commit to is the shape of the plan and the order of the work. We publish the sequence on platform migration, and the assessment that produces your dates is a conversation with your own inventory in front of us.
The three things worth insisting on
If you take nothing else from this into your next provider meeting, insist on these:
- A rehearsal. A full migration into a staging environment, with real volumes, before the real one. If a provider will not rehearse, you are the rehearsal.
- A rollback plan. Written down, with a decision point and a named person who can call it.
- A restriction test. Prove that a self-excluded player on the old platform cannot deposit on the new one, before a single real player moves.
If you want to walk your own inventory through this with us, book a platform demo and bring the five lists.
