Unity Multiplay Shutdown (2026): Migration Options After March 31

This is primarily a game-server hosting/control-plane migration. It does not automatically mean you must replace Unity Matchmaker, Lobby, Relay, your realtime networking stack, or your player-data backend. In fact, Unity's current Matchmaker documentation explicitly says Matchmaker continues after Multiplay Hosting deprecation and supports a preferred hosting provider.

What changed, and what did not

Layer	March/April 2026 impact	Migration question
Unity Multiplay Hosting	Direct Unity support ended; new allocations/scaling are deprecated outside the previously committed Rocket Science transition path.	Who now owns process placement, capacity, lifecycle and fleet operations?
Multiplay by Rocket Science	Independent continuation using licensed Multiplay technology, with its own hosting platform and current Unity/Unreal SDKs.	Is continuity of the Multiplay operational model preferable to re-platforming?
Unity Matchmaker	Continues as a Unity multiplayer service and can integrate with a preferred hosting provider.	Can you keep queue/rules/backfill and only change the allocation adapter?
Lobby / Relay / MPS session APIs	Not equivalent to the deprecated fleet-hosting product.	Which of these are actually in your shipped path, and which can remain untouched?
Durable player state	Independent of the hosting shutdown.	Do not move progression/economy merely because server allocation changes.

The migration paths that are actually comparable

Path	Why you would choose it	Main migration work
Multiplay by Rocket Science	Closest continuity path for existing Multiplay operational concepts and teams that want managed hybrid hosting/live operations.	Commercial transition, SDK/API version differences, build/config migration and validation of your title's existing allocation lifecycle.
Amazon GameLift Servers	Managed fleets/containers, multi-region AWS footprint, On-Demand/Spot capacity and independent FlexMatch if desired.	GameLift server lifecycle integration, build/container packaging, fleet/alias/queue design, IAM and observability.
Edgegap	Usage-based Edge Cloud plus reserved Private Fleets with one orchestration layer.	Container/build packaging, allocation API adapter, regions/QoS mapping and cost model for cloud versus fleet mix.
Gameye	REST-driven managed orchestration with on-demand/reserved capacity and included egress.	Container image, REST allocation adapter, provider-specific region/build metadata and lifecycle monitoring.
Agones + your infrastructure	You want an open-source Kubernetes game-server control plane and already have platform engineering capacity.	Clusters, nodes, networking, Agones SDK/lifecycle, autoscaling, upgrades, observability and on-call ownership.
Custom/bare-metal scheduler	Stable workloads, existing infrastructure expertise, unusual runtime requirements or economics that justify owning the stack.	Everything: placement, health, drain, deploys, regional capacity, failure recovery and scaling policy.

Do not compare these only by vCPU price. The migration risk sits in the control-plane contract: how quickly a process becomes ready, how allocation is acknowledged, how capacity is buffered, what happens during deploys, and what your operators can see when a region fails.

1. Inventory the Multiplay-specific contract

Before changing providers, search the dedicated-server build and backend for every Multiplay-specific assumption:

• allocation/deallocation callbacks and allocation ids;
• server readiness and health signals;
• launch parameters, ports and generated server configuration;
• payload retrieval and allocation metadata;
• QoS/site/region identifiers;
• build upload, version/configuration ids and rollout behavior;
• query protocol or server-status integration;
• fleet capacity/buffer assumptions exposed to your backend or operators;
• logs, metrics, crash artifacts and support runbooks.

Turn that list into an interface owned by your game/backend rather than by the next hosting SDK. The provider adapter should translate your stable session contract into GameLift, Edgegap, Gameye, Rocket Science or Agones-specific calls.

2. Keep Matchmaker separate from allocation

Unity Matchmaker can continue to decide which players form a match. The new hosting adapter decides which ready process receives it. Preserve that split.

tickets
  -> Unity Matchmaker rules / teams / relaxations / backfill
  -> match proposal
  -> hosting adapter Allocate(region, build, session_metadata)
  -> endpoint + allocation/session id
  -> connection handoff

This makes the next hosting migration cheaper too. Do not teach every matchmaking rule about a vendor-specific fleet id if a small adapter can translate region/build/capacity requirements instead.

3. Rebuild readiness before autoscaling

A process being started is not the same as a process being ready. Your replacement needs an observable startup boundary after maps/assets/configuration/network sockets are ready. Only then should the allocator route a match there.

Measure:

• process/container startup-to-ready distribution, not one best-case number;
• session-arrival rate by region;
• ready-capacity buffer required to hit queue-to-connect targets;
• drain/termination behavior during build rollout;
• what happens when the allocator succeeds but the process fails before players connect.

The orchestration guide covers the readiness/allocation/capacity loops in more detail.

4. Preserve region/QoS semantics deliberately

Provider region names are implementation details. Define your own stable region/latency policy and map providers into it. Otherwise every client, matchmaker rule and analytics query becomes coupled to the new vendor's location ids.

During parallel testing, compare real player RTT, packet loss and startup capacity, not only the geographic label. “Frankfurt” at two providers is not automatically the same routing/performance outcome.

5. Package the build for the target runtime

Different paths have different packaging contracts: container image, uploaded build archive, executable plus lifecycle SDK, or Kubernetes pod. Move secrets and environment-specific configuration out of the build artifact where possible, and make startup fail loudly when required allocation/configuration metadata is missing.

Do not combine the hosting migration with an engine upgrade or network-protocol rewrite unless you have to. Every extra moving part makes allocation failures harder to attribute.

6. Backfill and session recovery deserve explicit tests

If the game uses Unity Matchmaker backfill, confirm how the replacement hosting adapter maps a live process/session back to the ticket/backfill state. Test at least:

• player disconnect before connect;
• allocation succeeds but server fails readiness;
• server crashes mid-session;
• backfill while the fleet is scaling;
• region capacity exhaustion;
• deploy/drain while matches are active.

The hosting vendor cannot recover gameplay state your game never checkpointed. Decide separately whether a failed session is abandoned, reconstructed from durable state, or resumed through game-specific logic.

7. Keep persistent backend state out of the fleet migration

Your server host should not become the accidental database of record. Identity, progression, inventory, economy, leaderboard state and live configuration should have a stable backend contract outside the allocator unless there is a deliberate reason otherwise.

This is where Crux can participate: player/server auth, player documents, currencies/inventory primitives, leaderboards, live config and server registry. Crux does not currently provide general Unity dedicated-server fleet hosting, so it is not a replacement for Multiplay, GameLift, Edgegap, Gameye or Agones.

Migration sequence with the smallest blast radius

1. Freeze architecture changes. Do not simultaneously replace networking, player data and hosting.
2. Extract a hosting adapter. Define your stable Allocate/Ready/Drain/Terminate contract.
3. Bring up one replacement region/build. Validate packaging, ports, startup, health and logs.
4. Connect Matchmaker in staging. Run real queue → allocation → connection → backfill flows.
5. Load test startup and density. Derive the ready buffer from observed startup time and session arrivals.
6. Exercise failure paths. Capacity exhaustion, failed readiness, node loss, bad build, allocation timeout and drain.
7. Canary production traffic. Route a controlled region/cohort before broad cutover.
8. Only then revisit other UGS/backend choices. A successful hosting migration does not require a platform-wide rewrite.

Bottom line

Unity's direct Multiplay Hosting service is deprecated, but the technology did not simply vanish: Rocket Science operates Multiplay independently, while Unity Matchmaker remains usable with other hosting providers. The lowest-risk migration is therefore to isolate the hosting lifecycle and allocation contract, choose a replacement control plane, and leave matchmaking, networking and durable player state alone unless there is a separate reason to move them.