Who this is for
An operator on its own licence moving from one platform vendor to another: to ours, or to a custom platform we build. The usual reasons are the revenue share, a module that cannot be replaced on the old system, or a vendor that cannot follow the brand into a new market.
A white label brand moving to its own licence is a different project. There the platform often stays the same and the licence, the merchant accounts and the legal entity change; that path is on the white label page and takes about a quarter, set by the licence rather than by the engineering.
When not to migrate yet
- The current contract has no exit clause. Read the notice period, the exit-assistance terms and any migration fee first. If they are missing, you need a lawyer before you need an engineer.
- The problem is the licence, not the platform. A new platform does not fix a restricted-country list, a payment stack an acquirer will not accept, or a regulator's open file.
- The new licence or supplier approvals are not in place. On Curaçao, from 24 December 2026, operators may not do business with unregistered suppliers.
Exit terms decide the calendar
The lock-in is discovered at exit, which is the one moment you have no leverage. Three clauses set the earliest possible cut-over date: the notice period, the exit-assistance period after termination, and how long the old platform stays available read-only. Read them before you set a date, because a notice served late moves everything that follows.
The player data is yours to take if you are the data controller. Where GDPR applies, Article 28(3)(g) requires a processor to delete or return all personal data at the controller's choice when the service ends. What the article does not set is the format, the field mapping or the deadline, and those are what decide whether an export is usable. Ask for a test export of the full schema months before termination, not in the last week.
What moves, and what breaks if it moves badly
Read the last column as the failure the regulator or the player sees.
| Data | How it moves | What breaks if it is wrong |
|---|---|---|
| Player accounts and KYC status | Full export with documents and verification results, mapped to the new player account model | Verified players asked to verify again, or unverified players paid out above the licence's KYC threshold |
| Responsible-gaming limits and self-exclusions | Migrated as active controls with their start and end dates, never as notes | A self-excluded player can deposit on the new platform. This is the most serious failure on the list |
| Balances | Cash, bonus and locked funds as separate amounts, plus pending withdrawals | Player complaints on day one, and a player-funds figure that no longer matches the bank |
| Bonuses in progress | Each active bonus mapped to a rule on the new bonus engine, or settled before cut-over under terms published in advance | Wagering progress lost or reset, which players treat as confiscation |
| Open bets and jackpots | Settled before cut-over where possible; long-dated bets migrated with their odds and stake | Bets settled twice, or not at all |
| Transaction and game history | Kept in a read-only archive for the retention period the licence sets, with a bulk import into the new back office where it is needed | Complaints and regulator requests that nobody can answer |
| Affiliate tracking | Player-to-partner links and commission history exported and loaded into the new tracking | Partners lose credit for their players and stop sending traffic |
| CRM segments and consents | Marketing consents migrated with their dates and source | Players contacted without consent, or a whole database that cannot be mailed |
Two rows are the easiest to lose. Affiliate tracking and commission history may sit in a separate tracking tool, outside the player database the exit clause covers. Responsible-gaming controls are stored differently on every platform and get flattened into a status field. Name both in the exit request.
What the regulator and the suppliers need
A new platform is a change to the licensed operation. What that triggers depends on the licence, and some of it takes longer than the build.
| Licence | What a platform change triggers |
|---|---|
| Isle of Man | Test certificates for the new gaming system, sent to the GSC with an updated test certificate master list before launch. Player registration stays on Isle of Man servers |
| Curaçao | The new platform and studios must be registered suppliers from 24 December 2026. RNG and game reports must come from a test house that meets the CGA's criteria: ISO/IEC 17025 accreditation with online gaming in its scope |
| Anjouan | Notification of the material change. Every new B2B supplier, the platform included, needs an Anjouan B2B licence or Recognition Certificate |
| Tobique | Updated infrastructure disclosure: data centre, architecture, disaster-recovery plan. The bi-weekly encrypted backup to the Commission's provider must run from the new platform without a gap |
| Finland | From 1 July 2028 the platform supplier needs a Finnish gambling software licence |
Studios are often the longest dependency. Each one must be integrated with the new platform and, on Anjouan or Curaçao, cleared as a supplier, and each runs its own integration queue. The studio count drives the timeline more than the data volume. Start the studio list on day one; the game provider work is on its own page.
Payments: re-routing without losing deposits
On your own licence the merchant accounts are yours, so they do not move. The connections to them do. Each PSP and acquirer is connected to the new platform, tested per method and currency, and switched at cut-over. Saved cards are tokens held by the PSP, so a player keeps them if the PSP stays the same and usually re-enters the card if it changes, unless the two PSPs agree a transfer of the card data between them. Pending withdrawals are either paid out before the freeze or migrated with their approval status.
With our gateway in front of the processors, the route is moved in the gateway rather than rebuilt per PSP, and adding or dropping an acquirer needs no platform redeploy.
Cut-over and rollback
The cut-over is a rehearsed sequence, run at least once in full on a copy of production data before the real night. The planned downtime goes into the lowest-traffic window of the week, announced to players in advance. For a sportsbook that window is set by the fixture list, not the clock.
- Freeze. Stop new bonuses, close or settle open bets you can settle, pay pending withdrawals or record their status.
- Final export and load. The last delta of accounts, balances and transactions since the rehearsal.
- Reconcile. Every balance on the new platform against the old, to the cent, with a signed variance report. A variance not explained is a go/no-go failure.
- Smoke test. Login, deposit and withdrawal per payment method and per currency, game launch per studio, bet placement per sport, self-exclusion check.
- Switch. DNS and payment routes moved; players see the new platform.
- Hypercare. Our team on call for 30 days, as on every launch we deliver.
Rollback needs a decision point, written down before the night. Until the first real deposit lands on the new platform, rolling back means switching DNS back to an old system that was frozen, not changed. After real money moves on the new platform, a rollback means migrating those transactions back as well. Keep the old platform restorable and read-only until reconciliation has been signed, and agree with the outgoing vendor in the exit terms that it stays available for that period.
Questions to put to the outgoing and the incoming vendor
- To the outgoing vendor: can we have a test export of the full schema now, including responsible-gaming controls, bonus progress and affiliate links?
- To the outgoing vendor: how long will the old platform stay available read-only after termination, and at what cost?
- To the incoming vendor, including us: which of our studios and PSPs are already integrated and cleared for our licence, and which are not?
- To the incoming vendor: show us the reconciliation report from your last migration rehearsal, anonymised.
- To both: who notifies the regulator, with which documents, and by when?
Frequently asked
Will players have to register again?
No. Accounts, KYC status, balances and limits move with them. Players may need to log in again, and re-enter a saved card if the payment provider changes.
Can we migrate one brand first?
Yes, and on a multi-brand operation it is the safer order. The first brand proves the export, the mapping and the reconciliation, and the next brands run on a tested process.
What happens to active bonuses?
Each one is either mapped to an equivalent rule on the new bonus engine or settled before the freeze. Which option applies is published to players in advance, because a bonus that disappears overnight becomes a complaint and, on some licences, a dispute with the ADR provider.
Does the regulator have to approve the migration?
It depends on the licence. On the Isle of Man the GSC must receive the new system's test certificates before launch; Anjouan requires notification of material changes; Tobique requires updated infrastructure disclosure. We prepare the platform side of each filing, and you submit it as the licence holder.
How long does a migration take?
It depends on the exit terms, the number of studios and the regulator, more than on the data. We give a date after reading your current contract and your studio and PSP list, not before.