Switching platform providers without losing players

A platform migration puts balances, histories, limits and payment details into a new system while players keep playing. The risk is in the details nobody listed at the start.

Begin with the data, because everything else depends on it. Players, wallets, transaction histories, bonus states, verification status, responsible gambling settings, communication preferences, consent records. Each has a format in the old system and a different one in the new. Mapping them field by field takes longer than the technical build, and every gap shows up later as a support ticket or a compliance problem.

Some items deserve a separate list because errors there are costly.

Balances must match to the cent, in every currency, including bonus balances and pending withdrawals. Self-exclusions and limits must carry across without a reset, since a player who excluded themselves and finds their account open again is a serious incident. Verification status should transfer so that players are not asked to start again. Stored payment tokens can be hard to move between providers, and where they cannot move, expect a drop in returning deposits until players re-enter details. Plan for that dip and tell finance in advance.

Open bonuses and wagering progress need a decision. Honour them in the new system, or settle them before the switch. A half-completed offer that vanishes is a complaint.

Say an operator moves 400,000 registered players, of which 60,000 are active in a month. The aim is that those 60,000 notice almost nothing. Anything they notice should be planned: a short maintenance window, a new login screen, a request to confirm a card.

The cutover can take one of three common forms.

A single weekend, everything at once. It is the quickest and it has the largest blast radius. If something is wrong with balances, every player sees it.

By market or brand. One brand moves first, then the next. Problems found on the first brand are fixed before the others go. It takes longer and needs both platforms running at once, with the cost that implies.

By cohort. A small share of players move first, usually the less active ones, and the rest follow in waves. It gives the best early signal and needs careful handling of anyone who shares a wallet or an affiliate link across systems.

The right choice depends on your size and your tolerance for risk. Larger operators nearly always choose a phased route.

Whichever you pick, rehearse. Run the migration on a copy of production data at least twice and reconcile every balance. Define a rollback plan with a clear trigger, such as a balance mismatch above a stated threshold, and test that you can return to the old platform within hours.

Timing matters too. Avoid major sporting events and peak trading periods. Freeze other releases in the weeks around the switch so that you can tell what caused any issue.

Several other things break at cutover. Affiliate tracking links and postbacks must keep working, or commissions and reports will go wrong from day one. Domains, redirects and search engine indexing need a plan if URLs change. Reporting needs a bridge, so that finance can compare the month before and after on one definition. Customer support needs scripts and training, because the first week of questions will cover things nobody expected.

Contracts matter before you start. Check the old provider's terms on data export, notice periods and support during the transition. Some providers are slow to hand over full data exports, and the format may be proprietary. Ask for a sample export during the evaluation phase, not after you have signed with the new one.

Communication to players needs the same care as the technical work. Tell active players what is changing, when and what they need to do, once and early. Keep the message short. Give support teams the same text and a list of likely questions. After the switch, run a hypercare period of at least two weeks with a daily review of tickets, balance mismatches, failed logins and failed deposits, and a small team with authority to fix issues the same day.

Seven questions for the vendor and the team:

1. Who owns the field-by-field mapping, and who signs it off?
2. How are self-exclusions and limits carried over, and how will we test it?
3. What happens to stored payment details?
4. What is the rollback trigger and how long does a rollback take?
5. How many rehearsals will run on production-sized data?
6. Which reports will not match on day one, and why?
7. What does the old provider owe us during the transition?

Players rarely praise a smooth migration. They remember a bad one for a long time. The work is in making sure there is nothing to remember.