Platform Migration Risk Checklist

How to read this checklist

Each item names the thing that breaks, how you find out too late, and the check that surfaces it early. The discipline is the third column: an item without a concrete pre-cutover check is a worry, not a managed risk. Player data itself is deliberately absent — it has its own guide and its own reconciliation contract.

Player-facing surface

What breaks	How it announces itself	The check
Sessions and logins	Support flood at cutover: players stranded mid-session, password resets spiking	Rehearsed forced re-login flow; reset pipeline load-checked; honest maintenance page ready
Mobile apps	Old app versions calling dead endpoints for weeks after cutover	Version-gating or graceful-degrade path tested; store review lead time in the plan, not discovered during it
Deep links and bookmarks	Campaign links and saved URLs landing on 404s	Full inbound-URL inventory with mapped redirects, tested against real traffic logs
Localised content	A market quietly serving the default language or missing pages	Per-locale smoke of every migrated page type, not just the flagship market

Money paths

What breaks	How it announces itself	The check
Deposits	Approval rate drops in week one and gets blamed on players	Real transaction per provider, per method, per market, before and after; approval rate watched daily against the pre-migration baseline
Stored instruments	Returning players asked to re-enter cards; a share never do	Tokenisation continuity confirmed with each PSP, or the re-entry journey deliberately designed rather than left to default
Withdrawals	Payouts queued behind a verification gate nobody re-pointed	End-to-end real withdrawal through every path in rehearsal, including the KYC gate in front of it
Pending transactions	Deposits and payouts in flight at cutover land in neither system	Explicit in-flight policy: drain before the window, or a documented owner for every straddling transaction

Partner and data plumbing

What breaks	How it announces itself	The check
Affiliate postbacks	Partners report zero conversions, then dispute the period — trust damage outlasting the bug	Outbound-traffic trace on the source platform to find every postback; per-partner test conversion after rewiring
Analytics and attribution	A blind week exactly when you most need to see player behaviour	Tracking parity checked page-by-page pre-cutover; event volumes compared to baseline from hour one
CRM and marketing feeds	Campaigns firing on stale segments, or not at all	Every consumer of platform data inventoried by tracing access credentials, then re-pointed and confirmed
Regulatory reporting	The first post-migration submission fails or misstates the transition period	Rehearsed submission from the new stack, plus an agreed treatment of the cutover period itself — see regulatory reporting

The search surface

SEO damage is the migration failure with the longest repair time, because the feedback loop runs on a search engine's clock rather than yours. The surface holds together when four things ship in the same deploy: mapped one-to-one 301s for every URL that changes, sitemaps that list only the new reality, canonicals and hreflang that agree with the redirects, and structured data that survives the re-platform. The pre-cutover check is mechanical — crawl the old URL inventory against the new site and require every response to be a 200 or a single-hop 301 to the exact successor. Anything mapped to the homepage is a loss being booked politely.

The organisational items

Support readiness. Scripts for the predictable cutover questions, staff trained on the new back office before the week of, and a triage path for defects that separates "migration bug" from "normal ticket" so trends are visible.
The change freeze. A defined window around cutover where nothing else deploys — on either platform. Concurrent unrelated change is how a two-hour incident becomes a two-day investigation into which change did it.
Communication that matches reality. Players told the honest window; partners told before their integrations move; the regulator notified per the market's requirement. Optimistic comms convert a manageable overrun into a credibility event.
The decision log. Every accepted risk written down with its owner. At the post-incident review — and there is always one — the difference between an accepted risk and a missed one is whether it was documented.

Using it

Walk the checklist at three moments: when planning (does every item have an owner and a check), at the go/no-go (does every item have a proven status), and in the week after cutover (is every monitored metric back to baseline). The go/no-go pass is the one that matters — and it is the subject of parallel run and cutover.

Continue reading: Parallel run and cutover — the night itself. The migration guide — the full sequence this checklist protects.

Migration risks — common questions

What is the most commonly missed item in a migration?

The integration nobody owns: the affiliate postback configured by a contractor years ago, the CRM export a marketing tool quietly polls, the report a finance process downloads monthly. These are found by tracing outbound traffic and credentials on the source platform, not by asking the team — the whole point is that no one remembers them. Every one found after cutover costs a multiple of what it costs found before.

Does a platform migration hurt SEO?

It does not have to, but the failure mode is severe and slow to repair. If URLs change, every old URL needs a mapped 301 to its exact successor — not to the homepage. Sitemaps, canonicals, hreflang and structured data must reflect the new reality in the same deploy, and the old domain or paths must keep redirecting for as long as search engines and backlinks reference them. Treat the SEO surface as a migration workstream with an owner, not as a detail the new frontend inherits.

What happens to logged-in players at cutover?

Their sessions die — the only question is how gracefully. Plan for it explicitly: a maintenance page that states the window honestly, apps that handle the API change without stranding users on a dead version, and a forced re-login flow that has been tested with real password-reset volume in mind, because a fraction of every player base rediscovers its password at exactly this moment.

How do we keep payments working through the transition?

By treating each provider as its own mini-migration with its own confirmation. Depending on the setup, moving platforms can mean new merchant accounts, new API credentials, changed descriptors or re-tokenised instruments — and each of those has a player-visible failure mode, from declined deposits to orphaned stored cards. The check is per provider, per method, per market, with a real transaction in each path before and after cutover. See the approval-rate guide in the glossary for the metric to watch in week one.

Who should own the risk checklist?

One named person who is not also running a delivery workstream — risk ownership held by the busiest person in the project is decorative. Their job is not to fix items but to prove each has an owner, a check and a cutover-day status, and to have the standing to delay the cutover when the answer is unproven. If nobody in the project can credibly hold that line, the checklist is theatre.

What breaks, and the check that catches it.