iGaming Platform Migration Guide

What "migration" actually contains

The word hides a bundle of workstreams with different owners, different risks and different clocks. Planning starts by unbundling it:

Workstream	What it covers	Whose clock it runs on
Platform provisioning	Target environments, configuration, standard integrations	The vendor's — this is the fast number in every pitch
Data migration	Players, balances, KYC status, bonus state, history — see player data migration	Yours, plus the source platform's export cooperation
Payments	PSP re-onboarding or re-pointing, instrument continuity, payout paths	Each provider's underwriting and setup queue
Regulatory	Notification or approval, certification of the new stack where required, reporting continuity	The regulator's and testing house's — see certification and go-live
Traffic and tracking	Affiliate postbacks, analytics, SEO surface, deep links, apps	Partly yours, partly every partner who has to change an endpoint
People	Back-office retraining, support scripts, runbooks, on-call	Yours entirely, and always underestimated

The vendor's fast number is honest about the first row. The realistic timeline is the critical path through all six — and rows two through five each contain at least one counterparty you do not control.

The phase sequence

Names vary; the structure does not. What matters is that each phase has an exit criterion someone signs, because phases without exit criteria overlap until the plan is fiction.

Discovery and inventory. Every integration, data flow, report, bonus construct and customisation on the current platform, found by tracing what actually runs — not by asking what people remember. The unfound integration is the classic cutover-day surprise.
Mapping and gap decisions. For each inventory item: migrate, replace, retire, or rebuild. Every "the new platform does this differently" is a decision with a named owner, made now rather than discovered by support later.
Build and integrate. The vendor's visible workstream, running in parallel with payments re-onboarding and regulatory work — never in front of them.
Data rehearsals. Full-volume migration runs against production-shaped data, repeated until the error rate and duration are boringly predictable. One rehearsal is a hope; the number you need is however many it takes to stop finding new defect classes.
Parallel run and cutover. Covered in depth in parallel run and cutover — the go/no-go criteria, the freeze window and the rollback plan.
Stabilisation. A defined period with elevated monitoring, a frozen change calendar and the old platform still readable. Declaring victory at cutover is how week-two defects become incidents instead of tickets.

The three decisions that shape everything

Decision	The trade
Big-bang vs staged	One cutover concentrates risk into a single night; staging by brand, market or product spreads it but means running two platforms — two support flows, two reconciliations — for the overlap period
Freeze vs live migration	A freeze window simplifies data consistency enormously and costs revenue and player trust; migrating live keeps the business running and multiplies the reconciliation complexity. The honest version of this choice prices both sides
History depth	Full history migrated makes the new platform self-sufficient but dominates rehearsal time; a cut line with archival read access is usually the rational answer — provided the retention obligations are mapped first

Where migrations actually fail

Rarely in the headline workstream. The recurring failure sites, in rough order of frequency:

Reconciliation defined too late. If "what proves the migration was complete and correct" is not written before the first rehearsal, every rehearsal result is an anecdote. Balance-level proof is the subject of player data migration.
The long tail of integrations. The bonus engine and wallet get attention; the CRM feed, the affiliate postback and the regulatory report discover the migration on cutover day. The full list lives in the risk checklist.
Counterparty lead times found serially. The same sequencing failure as any launch: payment re-onboarding started after the build, certification after that. Run the external clocks in parallel from day one.
The team migrated last. Back-office users trained in the final week operate the new platform at support-ticket speed for a quarter.

The honest planning posture

State every gate separately, put a name and an externally confirmed date on each, and let the timeline be whatever the critical path says. A migration plan that fits in one number is not a plan — and the operators who ask for the gate-by-gate version in vendor conversations get materially better information from every vendor they talk to, including us.

Continue reading: Player data migration — the workstream that decides the whole timeline. The Turbo Stars platform — what the target side of a migration looks like here.

Platform migration — common questions

How long does an iGaming platform migration really take?

As long as its slowest gate, and the slowest gate is rarely the software. Data migration rehearsals, payment-provider re-onboarding, certification where the target market requires it, affiliate and tracking rewiring, and staff retraining each carry their own lead time, and several depend on external counterparties. A credible plan states each gate separately with an owner and an externally confirmed date; a single headline number is a sales artefact, not a plan.

Why do vendor estimates and real timelines differ so much?

Because they measure different things. A vendor estimate usually covers provisioning its own platform: environments, configuration, standard integrations. The migration is everything else — your data, your payment relationships, your regulatory obligations, your traffic sources and your team — and most of that work is invisible from the vendor's side of the fence. Neither number is dishonest; they are answers to different questions, and the failure is comparing them as if they were the same one.

Should we migrate everything at once or in stages?

Stage wherever the business allows it. Migrating by brand, by market or by product cuts the blast radius of every defect and gives the team a rehearsal on the least risky slice first. The all-at-once cutover is sometimes forced — licence timing, a terminating contract, a shared wallet that cannot straddle two platforms — but it should be the justified exception, not the default plan.

What should we keep from the old platform?

Read access to the source data for a defined retention period, exports of every report you are obliged to reproduce, and the reconciliation snapshots from cutover. Regulatory record-keeping duties do not end because the contract did, and the first dispute that reaches back past the migration date will need evidence the new platform never held.

When is migrating a mistake?

When the problem being solved is actually configuration, content or operations on the current platform — migration resets all three and solves none of them by itself. It is also a mistake when the motive is a single feature that could be integrated, or when the organisation cannot staff the migration and normal operations at the same time. A platform move is justified by structural limits: architecture, market coverage, commercial terms or vendor viability. See managed vs turnkey for the adjacent build-vs-buy question.

Platform migration, realistically.