How to Switch iGaming Platform Providers
Migrating a live casino or sportsbook changes the systems that hold balances, player controls, payments, approvals, and customer access. This guide turns the move into an evidence-gated plan: what has to transfer, which dependencies set the date, and which exit rights must be signed before you need them.
Last updated August 2026
When a migration is worth the risk
A legacy stack may block a regulated-market plan, fail defined scale or reporting requirements, produce unacceptable full-term economics, or leave material contractual failures unresolved. Document the problem, the acceptance criteria for a replacement, and the cost and risk of staying versus moving. A phased migration may limit scope, but any move still requires an explicit plan for affected accounts, balances, markets, counterparties, and controls.
First, consider not moving at all
Before a full replatform, test whether a narrower intervention solves the same problem with less operational and regulatory change. Options to evaluate include:
- Fix in place — test whether a scoped change to payments, bonusing, reporting, or another module meets the acceptance criteria without replacing the stack.
- Add a module instead of replatforming — where the architecture and approvals permit it, replace or add one layer without moving the player ledger.
- Launch the new stack as a second brand — assess whether a separate licensed brand can prove the configuration before any player migration.
- Migrate one market or vertical first — phase only where entities, licences, wallets, data, and integrations can be separated safely.
- Renegotiate before you leave — use a documented shortlist and an itemized migration case to test whether revised terms solve the underlying problem.
If none of those close the gap, migrate — but go in with the timeline, the data map, and the exit terms below settled up front.
Build the critical path
No market-wide week range survives contact with the actual contract, licensed entities, markets, data, and counterparties. Date every workstream, identify its external owner, and plan from the slowest dependency. Use evidence gates rather than a platform deployment estimate:
| Discovery & audit | Inputs complete | Inventory every data object, integration, contract, licensed entity, and market approval. Test a representative export before committing the plan. |
|---|---|---|
| Build & approvals | External clocks | Stand up the new stack, integrate payments, and complete the regulator, lab, supplier, and PSP work required for each market. The slowest dependency sets the pace. |
| Rehearse & reconcile | Risk-based window | Rehearse the export and cutover, reconcile wallets and transaction history, and test rollback. Use parallel operation only where the architecture and approvals permit it. |
| Cutover | Change window | Apply any required freeze, switch the controlled services, validate balances and access, execute the URL map, and invoke rollback if the agreed thresholds fail. |
| Stabilize | Exit criteria | Monitor balances, payments, customer access, approvals, crawl health, and incidents until the agreed acceptance and legacy-shutdown criteria are met. |
A short technical deployment estimate establishes only that scope. It does not establish when data rights, approvals, PSPs, reconciliation, customer communications, and cutover acceptance will all be ready.
What actually has to move
“Migrate the data” hides how many distinct things have to survive the switch, each with its own failure mode. This is the checklist the sales deck skips:
| What moves | Why it's the hard part | Verify in the plan |
|---|---|---|
| Player accounts & credentials | Authentication systems may not permit credential transfer, which can require account linking or a reset flow. | Confirm the auth migration path and whether a password reset is required. |
| Wallet balances | Every affected balance must reconcile to the ledger's specified precision; the architecture and cutover design determine whether a freeze is required. | Agree the freeze window and a signed-off reconciliation before go-live. |
| Transaction history | Migration, archive, access and retention requirements differ by jurisdiction, contract, dispute process and control design. | Define which history moves, which remains in an accessible archive, the retention period, and the evidence required by each market. |
| KYC & verification records | A new entity or control framework may not be able to rely on every prior check; unnecessary reverification can add customer friction. | Establish the lawful transfer, document scope, reliance rules, status mapping, and any required reverification. |
| Bonus & free-bet state | Dropping or mis-mapping active balances and wagering requirements can create incorrect player states and disputes. | Map active bonuses and wagering progress before cutover. |
| RG limits & self-exclusion | Applicable limits, exclusions and player-protection controls must remain effective under the rules of each live market. | Map each legal and policy obligation, transfer the required state, and test enforcement before customer access. |
| CRM segments & consent | Consent evidence, purposes, suppression state and segmentation may have different legal and operational treatment. | Confirm consent flags and segments come across cleanly and lawfully. |
| Affiliate structure & commissions | Incorrect links, attribution or deal mapping can affect traffic records, invoicing and commission disputes. | Map affiliate links, deals, and historical commissions. |
| Open bets & game rounds | Unsettled bets and interrupted game rounds need an agreed settlement and customer-remedy plan. | Agree how in-flight bets and rounds are settled across the switch. |
Failure modes to control
The same risk classes recur across migration plans, but their severity and controls depend on the stack, market, and contract:
- Wallet and balance integrity — define a signed reconciliation and rollback rule; use parallel validation where the ledger design permits it.
- Regulatory approvals — identify which games, systems, entities, and integrations require notice, testing, or approval in every live market; do not assume transferability.
- Organic traffic and SEO — preserve stable URLs where possible, map retired URLs, validate redirects and canonicals, and monitor crawl and ranking data.
- Customer access — test authentication, balances, journeys, communications, and support escalation before exposing the full player base.
- Payments and KYC — establish each PSP's onboarding status and the lawful, usable transfer path for verification records per market.
Who actually lets you leave
Lock-in is decided long before a migration starts — in the contract you signed with your current provider. Our dataset shows the gap between what providers say and what they give you. Of the 18 platforms we track, 13 state that the operator owns the player data — reassuring, and a clear majority, but not universal. Ownership on paper is not the same as getting the data out: only 7 confirm a clean, portable export of the player database. A further contract signal is that 16 of 18 say they support a migration to a competitor, while 13 name an export format.
| Provider | Data owned by | DB portable | Export format | Migrate to a rival |
|---|---|---|---|---|
| EveryMatrix | operator | Restricted | CSV, API, Kafka | Yes |
| Playtech | operator | Restricted | API | Yes |
| SOFTSWISS | operator | Portable | — | Yes |
| Pragmatic Solutions | operator | Portable | API; documented SQL/table views; full Customer Data transfer on exit | Yes |
| Aristocrat Interactive | operator | Restricted | API, operational reports and customer-specified exports | Yes |
| Altenar | — | — | — | Yes |
| Kambi | operator | Portable | API, CSV | Yes |
| Light & Wonder | operator | Restricted | APIs, portal exports and operational reports | Yes |
| Pariplay | operator | — | Partner API plus Client Area/report downloads | Yes |
| Digitain | shared | Restricted | — | Yes |
| White Hat Gaming | operator | Portable | — | Yes |
| GR8 Tech | operator | Portable | CSV; API; real-time streams | Yes |
| GiG | operator | Restricted | API, CSV, SQL | Yes |
| Bragg Gaming Group | operator | Portable | Structured reports and exports; exact CSV/API/warehouse formats are partner-gated | Yes |
| Slotegrator | Shared | — | CSV | No |
| BetConstruct | shared | Portable | API and scheduled reports | No |
| SoftGamings | operator | Restricted | — | Yes |
| Soft2Bet | — | — | API | Yes |
Contract visibility is uneven. Across all 18 providers, 8 profiles establish an exit notice period and 11a minimum contract term. Even where known, these can be customer-specific findings rather than public standard terms. Treat the remaining silence the way we read the rest of the market's pricing blackout: do not treat an unstated right as a contractual entitlement.
Delivery model is only the starting context
A delivery label does not determine exit difficulty. Start with the licensed entity, then inspect the signed data, hosting, export, certification, PSP, notice, and transition rights. In our data 18 of 18 profiles record an operator-held license route; 0 names provider-held licensing as the default. That does not mean every white-label deal is operator-held: a provider, affiliate, or licensed partner may still hold the B2C license under a specific contract. Get the exact licensed entity in writing, because leaving that wrapper can turn a technology switch into a re-licensing project.
| Delivery model | License held by | Players owned by | Exit difficulty |
|---|---|---|---|
| White label | Provider, affiliate, or licensed partner | Contract-dependent | Adds a licence-wrapper transition when the operator does not hold the B2C permission; data and contract rights decide the rest. |
| Turnkey | Yours | Contract-dependent | The operator may retain its licence, but export, certification, PSP, notice, and transition support decide the switch. |
| Standalone / PAM | Yours | Contract-dependent | API and operator control help only when export, hosting, approval, and transition rights are proven. |
The full trade-offs behind each model are in our guide to choosing a provider.
The exit-terms checklist — settle these before you sign
The best time to protect a future migration is the day you sign the current deal, while you still have leverage. Get each of these in writing. They map to fields we record on every review, so you can check a provider's posture before the sales call:
Full data-export right, in a named machine-readable format
Accounts, wallet balances, transaction history, KYC documents, and bonus state — not a partial dump. Get the format named in the contract.
Notice period to terminate, and any minimum contract term
8 of 18 profiles establish an exit notice period and 11 establish a minimum term. Most are customer-specific contract findings, not standard public terms, so get both written into your own deal.
Early-exit penalty, if any
What leaving before the term ends actually costs. Silence establishes nothing; require the penalty, waiver, or calculation method explicitly in the contract.
Migration-out and competitor-migration support
Who runs the export if you leave, on what timeline, at what cost, and whether they'll hand data to a rival platform. This is the real lock-in clause.
Player, brand, and domain ownership
Confirm the accounts, the brand, and the domain are yours to take. On white-label deals, rights to one or more of these are often restricted or shared under the contract.
Who holds the operating license
If the provider, an affiliate, or a licensed partner holds the licence, the move may require a new licensed route. An operator-held licence can preserve that permission while valid, but approvals, data rights, PSPs, certification, and contract duties remain separate workstreams.
How to run the move
When the decision is made, turn the following controls into dated, owned workstreams:
- Audit and map — inventory every data object, integration, and market certification, and get a sample export from the outgoing provider to test against before you commit.
- Rebuild and re-certify — stand up the new stack, re-integrate payments, and start the longest-lead market certifications first.
- Rehearse and reconcile — test the export and cutover, reconcile wallets and transaction history, and use parallel operation where the architecture and approvals permit it.
- Cutover — switch with 301 redirects mapped, players notified in advance, and support briefed for the spike.
- Monitor — watch balances, deposits, withdrawals, and rankings closely for the first weeks, when problems surface.
If you're moving to escape lock-in, the destination matters as much as the exit. An API-first standalone platform or a data-portable PAM can reduce dependence only when the contract proves export, hosting, approval, and transition rights. Weigh the itemized cost of the move against the documented benefit — our cost breakdown covers the numbers.
Frequently asked questions
How long does an iGaming platform migration take?
There is no defensible market-wide duration. Build a dated critical path from the actual export, data mapping, regulator and lab work, payment onboarding, reconciliation, cutover, rollback, and acceptance criteria. The slowest external dependency sets the launch date; a quoted platform deployment date does not establish the end-to-end migration date.
How much does a platform migration cost?
It is a project cost, not one comparable line item. Across our 18-provider dataset, 6 profiles contain a usable conclusion about migration-out cost, but no provider publishes a standard rate card. Two disclosed contracts provide only partial benchmarks: a no-cost extract with paid transition support, and a free customer-data export with normal fees and paid transition. Price the actual export and assistance rights, data engineering, required approvals and testing, PSP work, any dual-running window, cutover contingency, and post-launch support.
Can I move my players to a new platform without losing them?
Only when the contract, applicable data-protection basis, export scope, and operational plan support it. You need a machine-readable export of player accounts, wallet balances, transaction history, KYC records, and bonus state, plus a migration plan that keeps wallets accurate through cutover. 13 of the 18 providers we track say the operator owns the data, but ownership on paper is not the same as a usable export — check portability and the export format before you sign, not at the breakup.
Can I run the old and new platform in parallel?
A parallel run is one useful risk control, but it is not always technically, legally, or commercially available. Decide its scope from the ledger architecture, regulator constraints, duplicate-running cost, data synchronization method, and rollback capability. Where full parallel operation is impossible, require a rehearsed cutover, signed reconciliation, and an explicit rollback or recovery plan.
Will I lose SEO rankings when I migrate?
Rankings can change when URLs, rendering, internal links, content, performance, canonicals, or redirects change. Preserve stable URLs where possible, map every retired URL to its closest replacement, validate canonicals and indexability, and monitor crawl and ranking data before and after cutover. A migration does not guarantee either a loss or a quick recovery.
What's the biggest risk when switching casino platforms?
The material risk classes are ledger integrity, open bets and game rounds, identity and responsible-gambling controls, market approvals, PSP continuity, data-protection compliance, customer access, and web migration. Do not assume an approval or certificate for the old stack transfers. Assign an owner, acceptance evidence, rollback rule, and regulator or counterparty dependency to each risk.
Should I migrate all markets at once or one at a time?
Neither approach is universally safer. Compare market and entity boundaries, shared-wallet architecture, approval dependencies, dual-running cost, data synchronization, customer impact, and rollback capability. Phase where the stack and licences let you isolate risk; use one coordinated cutover only when cross-system dependencies make a split unsafe or impractical.
Will my new provider help me migrate off the old one?
Support is contract-dependent in both directions. Ask the incoming and outgoing providers, in writing, who extracts, transforms, validates, and transfers each dataset; which formats and delivery methods apply; what assistance is included; and what dates, fees, acceptance tests, and post-termination access are binding.
What should be in the contract before I sign, so I can leave cleanly later?
Get a full data-export right in a named machine-readable format, the notice period, minimum term, early-exit penalties, migration-out cost, and competitor support in writing. Our data establishes a notice period for 8 of 18 providers, a minimum term for 11, a migration-out cost conclusion for 6, and competitor support for 16. Most are customer-specific findings rather than standard public terms, so negotiate your own version while you still have leverage.