MIGRATION GUIDE · 2026-07-01

Unity Multiplay alternative:
how to migrate your backend and validate it before cutover.

By Alexander Strandberg · Founder, Aevs

Unity ended Multiplay Game Server Hosting in March 2026. If your game ran authoritative dedicated servers on Multiplay, you need a new host — and a way to prove the replacement behaves the same before your players find out it doesn't.

This guide maps Multiplay's primitives to Aevs validation concepts, gives you a sandbox config template and a validation plan, and walks the migration step by step. Aevs is Netcode CI — it does not host your servers; it validates whichever host you move to. For a wider look at replacement providers, see the provider comparison →

What happened to Unity Multiplay?

Unity Gaming Services ended Multiplay Game Server Hosting (rebranded as Unity Game Server Hosting) in March 2026. Studios using Multiplay for fleet management, server allocation, and matchmaking integration needed to migrate. Unity recommended its own Relay and Lobby services for certain topologies, but neither covers the authoritative dedicated-server use case that Multiplay served — leaving studios running persistent authoritative servers needing a third-party replacement.

Some studios that moved off Multiplay landed on Hathora — which then shut down on May 5, 2026, after being acquired by Fireworks AI. If you migrated twice this year, the validation plan below is host-independent and protects every future move. See the Hathora migration guide →

Concept mapping: Unity Multiplay → Aevs

Aevs doesn't reproduce Multiplay's hosting primitives — it validates that whatever replaces them still works. The table below maps each Multiplay primitive to the Aevs concept that verifies it on your new host.

Sandbox config template

Drop an aevs.sandbox.yaml at your repo root. The comments show where each field comes from in your old Multiplay setup. This is illustrative — adjust image, ports, and regions to your stack.

# Migrating from Unity Multiplay
version: 1
sandbox:
  name: multiplay-migration
  runtime:
    image: ghcr.io/your-studio/game-server:latest  # Multiplay build -> image
    transport: [udp]                                 # Multiplay dedicated UDP servers
    port: 9000                                        # Multiplay game port
    queryPort: 9010                                   # Multiplay SQP query port
  regions:                                            # Multiplay fleet regions
    - eu-west
    - us-east
    - ap-southeast
  concurrency:
    maxConcurrentSandboxes: 20                         # Multiplay fleet capacity
validate:
  plan: ./aevs.plan.ts                                # runs on every pull request

Validation plan: mirror your Multiplay behavior

Write the plan first, while Multiplay — or your captured Multiplay behavior — is still the reference. It becomes the pass/fail contract for the migration: if the replacement passes the same plan, it is behaviorally equivalent for the scenarios you care about.

export default {
  id: 'multiplay-migration-smoke',
  steps: [
    // 1. Server allocation (Multiplay "allocate")
    { type: 'http', method: 'POST', path: '/v1/servers/allocate',
      body: { region: 'eu-west', gameMode: '5v5' },
      assert: { status: 'allocated' } },

    // 2. Match assignment callback within 5s (Unity Matchmaker)
    { type: 'wait', condition: 'server.status === "ready"',
      timeout: 5_000 },

    // 3. Player connects and session persists
    { type: 'http', method: 'POST', path: '/v1/session/join',
      body: { playerId: 'p1', serverId: '{{server.id}}' } },
    { type: 'wait', condition: 'session.connected === true',
      timeout: 3_000 },

    // 4. Reconnect flow survives a drop
    { type: 'http', method: 'POST', path: '/v1/session/reconnect',
      body: { playerId: 'p1', serverId: '{{server.id}}' },
      assert: { reconnected: true } },
  ],
}

Estimated migration time

Rough guide for a mid-size studio. The validation work is fast and front-loaded; the host cutover dominates and varies by provider.

Step-by-step migration guide

Frequently asked questions

Is Aevs a drop-in replacement for Unity Multiplay?

No. Aevs does not host game servers. It is Netcode CI — it provisions an isolated sandbox per pull request, runs a declarative validation plan, and blocks merge when the plan fails. During a Multiplay migration you still pick a new host; Aevs proves that host works before players see it.

Can I use Unity Relay and Lobby instead of dedicated servers?

Unity Relay and Lobby are viable for games that don't need authoritative dedicated servers — typically turn-based, casual, or latency-relaxed titles. For real-time competitive games (FPS, MOBA, battle royale) that need authoritative server-side physics and anti-cheat, dedicated servers remain the only viable architecture, and Relay is not a substitute.

How much of my game code changes?

That depends on how deeply you used Multiplay-specific APIs. Standard allocation and deallocation calls have equivalents on most hosts. Custom fleet configuration, the Multiplay QoS system, and Unity Matchmaker integration will need provider-specific replacements — which is exactly what the validation plan is there to catch.