Casino Platform Migration Playbook 2026

A casino platform migration takes 4 to 9 months from decision to full cutover for a single-brand operator, and 9 to 18 months for a multi-brand, multi-jurisdiction estate. The work splits into five workstreams that run partly in parallel: commercial exit from the incumbent, player and wallet data migration, game content re-integration, payment and compliance re-certification, and marketing attribution continuity. The last of those is the one operators consistently underestimate, because affiliate tracking, historical commission ledgers, and postback endpoints are usually owned by the outgoing platform and are not covered by any standard exit-assistance clause. This playbook sets out the triggers, the sequence, the risk register, the cutover patterns, and the specific controls that keep player balances, game licences, and affiliate attribution intact through a replatform.

Migration Timeline: The Six Phases and What Each Takes

Six phases carry a casino replatform from decision to steady state, and only two of them can be safely compressed. Discovery and vendor selection can be shortened with a disciplined requirements document; parallel-run and stabilisation can be shortened when the data model of the incoming platform closely matches the outgoing one. Contract exit, data migration, and certification cannot be compressed, because they are gated by third parties: the incumbent vendor, the regulator, and the testing laboratory. The table below gives the phase structure Track360 sees most often across operator programs, with indicative durations for a single-brand operator holding one or two licences.

The critical path almost always runs through phase 4. Game studios have to re-paper commercial agreements to the new platform entity, and each studio integration then needs technical certification in each licensed jurisdiction. An operator with 20 studio relationships and two regulated markets is managing 40 discrete certification tracks, and any one of them can hold up a full-catalogue launch. Sequencing studios by revenue contribution, rather than alphabetically or by ease of integration, is the single highest-leverage scheduling decision in the whole programme.

Migration Triggers: When Replatforming Beats Staying Put

Five triggers justify a casino platform migration, and cost alone is rarely one of them. Operators who migrate purely to shave revenue-share points usually find the saving consumed by migration cost and post-cutover revenue dip within the first year. The triggers that hold up under scrutiny are structural: the platform cannot enter a market the operator needs, the data model prevents the analytics or personalisation the operator wants to run, the vendor roadmap has stalled, the commercial model no longer fits the operator's scale, or the operator has outgrown a white-label arrangement and needs to hold its own licence and player relationship.

The white-label exit case deserves separate treatment because it is not only a technology migration but a change in who holds the licence, the player funds, and the regulatory obligation. Operators weighing that step should work through the commercial and control differences first; the white label vs turnkey vs custom operator framework sets out where each model breaks, and the iGaming platform providers market map covers who serves which segment before a shortlist is drawn.

Vendor Exit Terms and Data Ownership: Audit Before You Shortlist

Four clauses in the incumbent contract set the outer bound on every migration date: the notice period, the definition of operator data and the export format promised, the scope and price of exit assistance, and any post-termination restriction on soliciting players or reusing configurations. They must be read before a shortlist is drawn, not after a new vendor is chosen. Operators regularly discover, six weeks into a migration plan, that the contract requires 180 days notice and defines exportable data as a CSV of account records with no transaction, bonus, or affiliate attribution history.

Operators who cannot get satisfactory answers from the incumbent contract have one reliable defensive move available immediately: stand up an independent data pipeline that captures the events the operator will need later. A daily export of transactions, bonus grants, KYC status changes, and affiliate click and conversion events into an operator-controlled warehouse costs little to run and converts a contested data-ownership question into a settled one. Doing this before serving notice, rather than after, avoids the awkward conversation entirely.

Player Data and Wallet Migration: Reconciling to Zero Variance

Wallet migration requires a signed reconciliation showing zero variance between the closing balance on the outgoing platform and the opening balance on the incoming one, per player and in aggregate. Everything else in a player migration can be remediated after cutover; a balance discrepancy cannot, because it becomes simultaneously a customer-trust incident, a regulatory reporting problem, and an accounting reconciliation that grows harder every day it is left open. Player funds protection obligations under MGA and UKGC licensing require the operator to evidence that customer balances are held and accounted for correctly at all times, which includes the moment of a platform change.

Responsible gambling state is the entity to migrate first and test hardest. Self-exclusion registrations, deposit limits, loss limits, time-outs, and reality-check settings must be present and enforced on the new platform from the first second of live traffic. A player who self-excluded on the old platform and can deposit on the new one is a reportable failure in every regulated market, and it is a failure that regulators treat as a control breakdown rather than a technical accident. Build the migration test plan so that responsible gambling controls are verified in the target environment before any other acceptance test is signed.

Game Licence and Content Re-Integration: The Longest Dependency

Game content re-integration runs 8 to 20 weeks and is the most common cause of a slipped cutover date, because each studio relationship has to be re-papered commercially and then re-certified technically in each jurisdiction. Game supply agreements are typically held between the studio and the platform, or between the studio and the operator with the platform named as the integration point. Either way, moving platforms means the studio must approve the new integration path, agree revenue terms with the new counterparty, and in regulated markets submit the game set for testing against the local technical standard.

Three practical rules shorten this path. First, obtain the incoming platform's live studio list before signing, and treat any studio in the operator's top revenue decile that is absent from that list as a contract condition rather than a roadmap item. Second, sequence certification by revenue contribution so the catalogue that matters is live on day one even if the long tail arrives over the following weeks. Third, plan for the fact that jackpot and tournament participation often cannot be migrated at all: progressive contributions and leaderboard state usually reset, which is a player-communication task, not an engineering one.

Preserving Affiliate Attribution and Historical Commission Data

Affiliate attribution is the workstream most often discovered late and the one where operators lose the most money in a platform migration, because the tracking layer, the click history, and the commission ledger frequently sit inside the outgoing platform and are not covered by its exit-assistance obligations. The damage is specific and quantifiable. If pre-cutover click and conversion data does not move, every player acquired before the switch loses their source attribution, which means commissions on their future activity cannot be calculated correctly. Affiliates whose earnings drop for reasons the operator cannot explain stop sending traffic, and the acquisition channel degrades for months after a migration that was otherwise technically clean.

The seven-step affiliate cutover sequence

Seven steps keep the affiliate layer whole through a platform change, and they run on a schedule that starts before notice is served on the incumbent. Each step produces an artefact that can be checked, not a status update.

1. Export the full affiliate dataset from the outgoing platform before notice expires: player-to-affiliate mapping, click and impression logs, conversion events, and the commission ledger broken down by RevShare, CPA, and hybrid deals.
2. Rebuild every commission plan from the signed affiliate agreements rather than from the outgoing platform's configuration screens, including tier thresholds, negative carryover settings, and qualification rules for a depositing player.
3. Replay at least one historical payout period through the new configuration and diff it against the actual payment made, at the level of GGR, NGR, and net commission per affiliate.
4. Map the outgoing platform's event feed to the incoming one field by field, covering registration, first deposit, deposit, bonus grant, and adjustment events, then run both feeds in parallel for a full week before switching.
5. Re-point postback and server-to-server endpoints for every affiliate and network, verify delivery with test conversions, and confirm geo-targeting and traffic-source parameters still arrive intact.
6. Re-establish fraud controls on the new event feed before live traffic: bonus abuse detection, multi-accounting patterns, self-referral checks, and the velocity thresholds that flag suspicious first deposits.
7. Publish the affiliate communication plan with the cutover date, the reporting blackout window, the date statistics will be complete again, and the payment guarantee for the transition period.

Step 3 is the one operators skip and later regret. A replay diff against a known-good payout period is the only test that proves the new configuration reproduces the economics both sides already agreed, and it catches the silent errors that a functional test will not: a tier boundary applied to GGR instead of NGR, a hybrid deal where the CPA component fires twice, or a qualification rule that counts a bonus-funded stake toward player lifetime value.

The structural fix is to hold affiliate tracking and the commission ledger outside the casino platform, in a dedicated partner-management system that the operator controls. When attribution lives in an independent layer, a platform change becomes an integration change rather than a data-loss event: the affiliate system keeps its click history, its player mapping, and its commission ledger, and only the inbound event feed is re-pointed. This is the operating model Track360 is built for, and it is the same reason many operators separate the affiliate layer before they start a platform search rather than during it. The sequencing and validation steps are covered in the affiliate program migration framework, and the evaluation criteria for the affiliate layer itself are in the affiliate platform RFP evaluation template.

Whatever the architecture, the affiliate communication plan matters as much as the data plan. Affiliates should be told the cutover date, the reporting blackout window, the date their statistics will be complete again, and the guarantee the operator is offering for the transition period. Many operators pay affiliates on a pre-cutover trailing average for the first reconciliation period rather than on possibly incomplete data, then true up once the ledger is verified. That costs a small amount of money and preserves a channel that costs far more to rebuild.

Downtime Planning and Cutover Patterns

A well-planned casino cutover needs 2 to 6 hours of maintenance window, and the pattern chosen determines whether that window is the whole story or just the beginning. Three patterns dominate. A big-bang cutover moves everything in one window and is simplest to reconcile but concentrates all risk in a single night. A phased cutover moves brands, markets, or player cohorts in waves, reducing blast radius at the cost of running two platforms and two reconciliations in parallel. A parallel-run approach keeps the old platform live in read-only mode for a defined period so history remains queryable while new activity accrues on the new platform.

Whichever pattern is chosen, the cutover runbook needs an explicit rollback decision point with a named owner, a stated deadline, and pre-agreed criteria. The most common criteria are a failed balance reconciliation, a responsible gambling control that does not enforce correctly in production, or a payment method that will not process live transactions. Rollback becomes practically impossible once real-money activity has accrued on the new platform, so the decision point must sit before traffic is admitted, and the runbook must state exactly who can call it.

Migration Risk Register: The Twelve That Recur

Twelve patterns account for most migration overruns, and eleven of them are visible in the planning phase if the right questions are asked. The register below is the version Track360 recommends operators start from, scored on likelihood and impact for a typical single-brand replatform. Each risk should carry a named owner and a mitigation that is a scheduled task rather than an intention.

What a Migration Costs and How to Model the Payback

Migration cost lands in four buckets that operators routinely model incompletely: direct vendor fees, internal effort, dual-running overlap, and post-cutover revenue impact. The fourth is the one omitted most often and is frequently the largest. A replatform changes the interface players know, resets recommendation and personalisation models, and interrupts lifecycle campaigns, and a temporary dip in activity in the weeks after cutover is the norm rather than the exception. A business case that shows payback only if there is no dip is not a business case.

Methodology & Assumptions

Three sources feed every duration and range on this page: operator programmes running affiliate infrastructure on Track360, published integrator and consultancy guidance on replatforming, and regulator documentation on licensing and player-protection obligations. Every figure is Track360 analysis rather than a vendor quotation and is labelled as such wherever it appears. iGaming platform vendors do not publish pricing, exit terms, or migration timelines, and no figure here is attributed to any named provider. The phase durations and risk likelihoods are drawn from operator programmes running affiliate infrastructure on Track360 alongside platform changes, cross-checked against publicly available integrator and consultancy guidance on replatforming. Where a range is wide, it is wide because the underlying variance is real: an operator with two studio integrations and one licence sits at the bottom of every range, and an operator with 40 studios and five licences sits above the top of several of them.

Regulatory obligations referenced here are stated generically because they vary by jurisdiction. Player funds protection, self-exclusion enforcement, record retention, and change-notification duties are set out in licence conditions rather than in platform contracts, and operators should read the specific conditions applying to each licence they hold. Primary references used for the regulatory framing are the Malta Gaming Authority licensee obligations and the UK Gambling Commission licence conditions and codes of practice, with market context from the European Gaming and Betting Association. This page is reviewed quarterly in January, April, July, and October, with out-of-cycle corrections when a regulator changes a relevant obligation.