In short

  • The platform is the smallest part of the migration. The programme logic, the data contracts, and the accumulated exceptions are the hard part.
  • Migrate the model before the messages. If your segmentation and trigger logic only exist as configuration inside the old tool, you are porting artefacts rather than intent.
  • Parallel running is not optional in a category where revenue is this concentrated in a small share of players.
  • The most common failure is silent: campaigns migrate and appear to work, but trigger timing has shifted by hours and nobody is measuring that.
  • A migration is the only cheap opportunity you will get to delete things. Use it — most programmes are carrying campaigns nobody has evaluated in years.

Why operators end up here

Platform migrations in iGaming come from a small number of causes, and which one you have determines how the project should be run.

  • The programme outgrew the tool. A platform that handled a single market and a simple lifecycle is now being asked for multi-market eligibility, real-time triggers, and a value model. Common, and the least risky kind, because the destination is well understood.
  • The operator outgrew the arrangement. A platform bundled with a provider, or inherited through a group relationship, no longer matches how the business is run. Usually the most political.
  • A market entry forced it. A new jurisdiction imposes requirements — data residency, consent handling, protection-event flows — the incumbent tool cannot satisfy. These carry a deadline that is not yours.
  • Nobody can explain the current programme. The team that built it has turned over, the configuration has accumulated exceptions, and the honest reason for moving is to get a clean start. This is a legitimate reason, and it is the one most likely to be mis-scoped — because the mess follows you unless it is dealt with explicitly.

If you cannot say in one sentence which of these you are doing, the migration is not ready to start. The scope of the data work, the tolerance for downtime, and the amount of programme redesign that belongs inside the project all depend on the answer.

What actually breaks

The platform switch itself is a procurement and integration exercise, and it is usually delivered competently. The programme damage comes from four places, roughly in order of how often we see them.

Trigger timing shifts and nobody notices

This is the big one. Behavioural triggers depend on how quickly an event reaches the CRM system and how quickly the system acts on it. Change the platform and you have changed both, usually without anyone stating a target.

A deposit-abandonment message that fired within minutes on the old stack and fires within hours on the new one is, functionally, a different campaign. It will still show as delivered. Open rates may look fine. The conversion attributable to it quietly halves, and because the change is spread across every triggered campaign at once, the effect shows up as a general softening that gets attributed to seasonality.

In markets with instant payments — Brazil being the clearest case — this failure mode is severe enough to swamp everything else in the migration. Measure end-to-end latency per trigger before and after, and treat it as a release gate rather than a metric.

The undocumented exceptions

Every mature CRM programme carries exceptions: the VIP list that is suppressed from a particular campaign, the country excluded from an offer after a compliance conversation two years ago, the cohort permanently held out for a test nobody ended. These live in the old platform's configuration and in the heads of two people.

They will not migrate, because nobody knows to migrate them. The compliance-driven ones are the dangerous subset — an exclusion added for a regulatory reason and never written down is an exclusion that silently disappears the day you switch. Before anything else, extract every suppression, exclusion and hold-out from the incumbent system and force each one to acquire a written reason. The ones nobody can justify are your first deletions.

Data contracts that were never contracts

CRM platforms consume events from the player platform, and the shape of those events is usually an accident of history rather than a designed interface. Field names mean things nobody wrote down. One event carries three different meanings depending on a flag. A timestamp is in local time for historic reasons.

The migration is where all of this surfaces, and it is genuinely the most valuable part of the project: for the first time, someone has to state what the data means. Budget for it properly. A migration plan that assumes the event stream is well-defined is a plan that will slip.

History that does not come with you

Value models, propensity scores and lifecycle stages are computed from history. If the migration carries forward only current state, every model starts cold, and the segmentation that took two years to tune produces noise for a quarter.

Decide early whether history migrates, is recomputed from the source data warehouse, or is deliberately abandoned. All three can be correct. What is never correct is discovering the answer after go-live.

The sequence that works

We would run it in this order, and the ordering matters more than any individual step.

  1. Document the programme independently of the tool. Segments, triggers, journeys, suppressions, offer ladder, and the reason each exists — written down somewhere that is not the platform you are leaving. If this cannot be produced, that is the actual finding, and it is worth more than the migration.
  2. Decide what dies. Go through the documented programme and cut everything that cannot justify itself. In our experience a meaningful share of campaigns in a mature programme have not been evaluated since launch. Migrating them costs real money and carrying them costs more.
  3. Define the data contract. Agree what each event means, when it fires, and what latency the CRM is entitled to expect. Write it down. This is the artefact with the longest useful life of anything the project produces.
  4. Rebuild the model, not the configuration. Re-express segmentation and trigger logic as intent in the new platform, rather than reproducing the old tool's settings. Configuration is an artefact of a system you are leaving; intent is the thing you actually own. Our segmentation guide covers what that intent should look like.
  5. Run in parallel. Both systems live, with the new one shadowing rather than sending, until timing and audience selection match on the campaigns that matter. Then cut over in tranches, not at once.
  6. Cut over by value band, lowest first. If something is wrong, you want to find it on the cohort where being wrong is cheapest. Player value in this category is concentrated enough that the top band should be the last thing you move, never the pilot.
  7. Measure against pre-migration cohorts, market by market. Blended numbers hide a single market breaking. Split by jurisdiction, because a migration that works everywhere except one market is the normal outcome, not the exceptional one.

On parallel running

Parallel running is where migration budgets get cut, and it is the wrong place to cut them.

The argument against it is that you are paying for two platforms while getting the benefit of one. That is true, and it is the correct trade. Player value in iGaming is concentrated enough that a few weeks of degraded retention on the top value band can cost more than the entire overlap period — and unlike the platform fee, that loss is not recoverable, because a high-value player who lapses because their treatment quietly changed does not come back on request.

Set the exit criteria for parallel running before it starts, in numbers: trigger latency within an agreed band, audience selection matching within an agreed tolerance on the campaigns that matter, no unexplained divergence in send volume by market. Without written criteria, parallel running ends when someone gets impatient — which is the same as not doing it.

Choosing what to migrate to

We deliberately do not publish vendor comparison tables. Platform capability in this category moves faster than any page can track, we are not resellers, and a table that is six months stale is worse than no table — it makes a decision look researched when it is not.

What we will say is that the selection criteria that matter are mostly not feature lists. They are: how the platform handles jurisdiction as a dimension, what end-to-end trigger latency it can actually achieve against your event volume, whether your team can operate it without the vendor in the room, what happens to your data if you leave, and whether the commercial model punishes the growth you are planning for. Our guide to choosing an iGaming CRM platform works through those in detail.

Our consultants have run programmes on the platforms this category actually uses — including Smartico, Optimove, Xtremepush, Salesforce and Customer.io, and in-house systems — which informs how we assess a fit. It does not make us a reseller of any of them, and we would rather tell you where we would be guessing.

For the vendor-level detail this page deliberately leaves out, StackCapybara — the group's software review property — publishes a map of the iGaming CRM platforms, including what the April 2026 Optimove–Smartico agreement does and does not change for a buyer running a shortlist.