How to Migrate Off PlayFab in 2026 (the Migration Window Is Finally Open)
Microsoft's migration path for existing PlayFab titles opens mid-2026. If the March free-tier cut stranded your live game on Development Mode, here's the vendor-neutral playbook to actually move off PlayFab - what breaks, what it costs, and how to keep player IDs intact.
Quick verdict (July 2026)
- The migration path for existing PlayFab titles opens mid-2026. Live games can finally move.
- If you are not shipping on Xbox, Foundation Mode is not an option - migration is the plan.
- Budget 2 to 4 engineering weeks. Most of it is player-ID mapping and validation, not API rewrites.
- Player progression survives if - and only if - you build the one-time ID mapping table.
Since March 11, 2026, PlayFab's free tier has effectively been gone for anyone not shipping on Xbox. Development Mode caps at 1,000 lifetime player accounts, and the free replacement - Foundation Mode - requires Xbox participation. For months, existing live titles were stuck: the new mode was not open to them, and the old free runway had been cut by 99%.
That waiting period is ending. Microsoft's migration path for existing titles is planned for mid-2026, which means this quarter is the first time a shipped game can actually move. If you have been waiting to leave, this is the playbook: what to check before you commit, what breaks, how long it takes, and how to move without wiping your players.
Should you migrate at all? The 60-second test
Migration is real work. Do not start it if you do not need to. Run this quick test:
- Shipping on Xbox in the next 12 months? Stay. Foundation Mode is free and the path of least resistance - link Partner Center and move on.
- Not on Xbox, and your title is past its first real playtest? Migrate. Your free runway is gone and the meter math only grows.
- Pre-production, tiny internal build? You have time. Prototype on any free tier and decide at soft-launch, not now.
- Live game with paying players and a PlayFab bill you cannot forecast? Migrate, and prioritize the player-ID mapping above everything else.
What actually breaks (the five surfaces)
A PlayFab migration is bounded. It touches exactly five things, and knowing them up front is half the battle.
| Surface | What it is | Migration effort |
|---|---|---|
| Client SDK calls | Every LoginWith*, Leaderboards, and player-data call | Mechanical but wide - wrap PlayFab in a thin client first |
| CloudScript | Server-authoritative logic running inside PlayFab | Medium - needs a new home (your service or the new backend's equivalent) |
| Scheduled tasks | PlayFab's cron-style jobs | Low - re-wire to cloud cron or the new backend's scheduler |
| Player ID continuity | Existing players' IDs and saved data | Hardest - a one-time export and mapping table |
| Live-ops dashboard | The event feed your community/data teams watch | Medium - re-point the same events before cutover |
The API rewrites look scary because they are everywhere, but they are mechanical. The part that actually decides success or failure is player ID continuity, and most of the two-to-four-week estimate lives there.
The migration in six phases
- Wrap PlayFab in a thin client. Before you change backends, route every PlayFab call through your own interface. This one refactor makes the actual swap a matter of changing the implementation behind the interface, not hunting call sites across your codebase.
- Export player data. Pull player accounts, saved data, statistics, and inventory out of PlayFab. This is your source of truth for the mapping.
- Build the ID mapping table. Map each PlayFab ID to a new-backend ID. This table is the difference between a clean migration and a player-progress wipe.
- Re-home CloudScript and scheduled tasks. Move server-authoritative logic and cron jobs to their new home. Test them in isolation before they touch live traffic.
- Run a shadow period. Write to both backends for a window, and diff. Verify leaderboards, progression, and economy match on both sides before you trust the new one.
- Cut over behind a version gate. Flip new clients to the new backend, keep the old one readable for stragglers, and monitor the live-ops feed. Retire PlayFab once the tail has updated.
The one rule that saves live games: never cut over without the ID mapping validated in the shadow period. Everything else is recoverable. A silent progression wipe on your paying players is not.
Where PlayFab titles are going in 2026
Studios that concluded Foundation Mode was not for them have a short list of real destinations.
Crux
Flat pricing with a free tier that covers 2,000 monthly active users and 2,000,000 API calls per month - no Xbox requirement, no Partner Center linkage, no payment instrument to evaluate. Auth, leaderboards, player progression, server registry, and dedicated server orchestration in one platform, with flat paid plans instead of per-meter math. Best fit for indie and mid-size studios that want predictable pricing and no platform lock-in. There is a Crux-specific 10-step PlayFab-to-Crux checklist if that is your destination, and a cost calculator to model your MAU curve first.
Nakama (self-hosted)
Open source, Apache-licensed, infinite free in dollars - you run PostgreSQL, the Linux fleet, backups, and on-call. Best fit for studios with a platform engineer who would rather own infrastructure than rent it. The self-hosted-vs-managed breakdown has the total-cost-of-ownership math at 10K and 100K MAU.
Firebase
A solid auth-plus-database foundation, but not a complete game backend: no dedicated server orchestration, no built-in leaderboards, no game-specific live-ops. Best for turn-based mobile and casual multiplayer where dedicated servers are not needed. If you are weighing it, read where Firebase stops for multiplayer before you commit.
Beamable
Managed backend with a free tier and per-MAU pricing, mature and strong on live-ops tooling. Best for studios that want a managed alternative without re-onboarding to Microsoft's platform.
Keeping player IDs intact (the part everyone underestimates)
This deserves its own section because it is where migrations go wrong. Your live players are identified by PlayFab IDs. Their saves, stats, purchases, and progression all hang off those IDs. If the new backend mints fresh IDs and you have no mapping, every player looks brand new on migration day and their progress is gone.
The fix is a one-time mapping table built during export: PlayFab ID on one side, new-backend ID on the other, populated as you import each player. At login, the client presents whatever identity it has, and your thin client resolves it through the mapping. Validate this against real accounts during the shadow period - pick ten live players, migrate them, and confirm their exact progression appears. Only then do you trust the table.
What we recommend (July 2026)
- On Xbox soon: Do not migrate. Foundation Mode is free for you. Link Partner Center and move on.
- Not on Xbox, live game: Migrate this quarter now that the window is open. Prioritize the ID mapping, use a shadow period, cut over behind a version gate. Crux if you want flat pricing and dedicated servers in one place, self-hosted Nakama if you have the ops muscle.
- Not on Xbox, still prototyping: No rush. Prototype anywhere free and decide at soft-launch.
Related reading
- Migrating from PlayFab to Crux: A 10-Step Checklist - the destination-specific version of this playbook.
- PlayFab Cut Free Tier 100K to 1K Users - the March change that started all of this.
- PlayFab Pricing 2026: Plans, the Free-Tier Cut and Real Cost - the deeper pricing and feature comparison.
- The 2026 Game Backend Shake-Up - if you also ran Unity Multiplay or Hathora, you may be migrating more than one thing at once.