Migrating from PlayFab to Supercraft GSB: A 10-Step Checklist (2026)

Microsoft PlayFab is a mature live-ops backend, but indie and mid-size studios increasingly hit the same set of friction points: confusing usage-based pricing that's hard to forecast, mandatory Azure account dependencies, an enormous API surface that punishes simple games, and rising concern about long-term Microsoft commitment to PlayFab as a standalone product (GameSparks was sunset in 2024). This guide walks through migrating a live game's backend from PlayFab to Supercraft Game Server Backend (GSB) with zero downtime.

Before You Start: Is GSB the Right Replacement?

GSB replaces PlayFab cleanly if your game uses PlayFab primarily for: player auth, save sync (player-scoped JSON documents), leaderboards, friends, matchmaking, virtual currencies, inventory, and dedicated-server registry. GSB does not currently replace PlayFab if you depend heavily on Azure-specific features like Application Insights, Azure A/B testing, or PlayFab Multiplayer Servers (the orchestration layer — Supercraft hosting is the equivalent but you'd treat it as a separate product).

Read the PlayFab vs GSB comparison first if you're still in the decision phase.

The 10-Step Checklist

Step 1: Audit your PlayFab usage

List every PlayFab API call your client and server code makes today. Group them by category: auth, player data, leaderboards, virtual currency, inventory, cloud script / Azure Functions, multiplayer matchmaking, analytics events. This list becomes your migration spec.

Pull a 30-day call-volume report from the PlayFab dashboard. Anything called <1% of total volume can usually be deferred or dropped during migration.

Step 2: Map PlayFab APIs to GSB equivalents

PlayFab	GSB equivalent	Notes
LoginWithEmailAddress / LoginWithCustomID	POST /v1/auth/login (email + password) / POST /v1/auth/anonymous	Direct mapping. GSB also supports OAuth (Google, Apple, Steam).
UpdateUserData / GetUserData	Player JSON docs with patch semantics	GSB uses RFC 6902 JSON patch. Map PlayFab key/value pairs into a single document.
UpdatePlayerStatistics / GetLeaderboard	Leaderboards API	Direct mapping. Seasonal boards supported.
AddUserVirtualCurrency / SubtractUserVirtualCurrency	Currencies API with atomic transactions	Direct mapping; atomic semantics for multi-currency operations.
GrantItemToUser / GetUserInventory	Inventory API	Direct mapping. Stack-based and unique-item modes both supported.
PlayFab Cloud Script (JavaScript) / Azure Functions	GSB cloud-functions endpoint	Rewrite required. GSB uses a different runtime; budget the most rewrite time here.
Matchmaking API	GSB matchmaker	Map your queue config; rule-set semantics differ slightly.
GetTitleData (live config)	Live config bundles, environment-based	GSB ships environment-aware bundles; map your title-data keys to bundle versions.

Step 3: Export your PlayFab player data

Use PlayFab's GetPlayerSegmentReport or the data export feature in the PlayFab dashboard to dump all player accounts, statistics, virtual currency, and inventory state. The export typically produces JSON or CSV chunks.

Critical: capture player IDs alongside the data. You'll need to map PlayFab IDs to GSB IDs in step 7.

Step 4: Set up your GSB project

Create a GSB project at gsb.supercraft.host/pricing (start on free tier for migration testing). Configure your environments — typically dev, staging, prod. Generate API keys for each.

Step 5: Build the import script

Write a one-shot import script that iterates your PlayFab export and creates equivalent GSB entities:

• For each PlayFab player: create a GSB player with anonymous-promote auth, then merge in their email if present
• For each statistic: write to the matching GSB leaderboard
• For each virtual currency: write to the matching GSB currency
• For each inventory item: write to GSB inventory
• Write a mapping table: playfab_id → gsb_id

Test on staging first. Run import in batches of 1,000 players to monitor for errors.

Step 6: Rewrite Cloud Script logic

This is the longest single step. PlayFab Cloud Script and Azure Functions don't translate 1:1. For each function:

• Identify the trigger (player call, scheduled task, server-side validation)
• Map to GSB cloud function equivalent
• Rewrite the business logic; do NOT just port the JavaScript verbatim — GSB's runtime has different semantics
• Write tests; the production data is the only audit you'll get

Step 7: Update your client SDK calls

Replace PlayFab SDK calls in your game client with GSB SDK calls. Wrap each in a feature flag so you can toggle between PlayFab and GSB during the cutover.

Use the playfab_id → gsb_id mapping from step 5 so existing players see their progression seamlessly after the switch.

Step 8: Stage a parallel-write period

For 1-2 weeks before cutover, run both backends in parallel. Every player action writes to both PlayFab (current source of truth) and GSB (shadow). This catches mapping bugs before they hit production.

Compare data integrity daily. If GSB diverges from PlayFab by more than 0.1%, fix the import script and re-run.

Step 9: Cutover

Pick a low-traffic window (usually a weekday off-hour for your game's primary audience). Flip the feature flag from PlayFab to GSB. Monitor for 4 hours minimum.

Keep PlayFab in read-only mode for 30 days as a rollback safety net. Most migrations don't need to roll back, but the 30-day buffer covers edge cases.

Step 10: Decommission PlayFab

After 30 days of stable GSB-only operation:

• Cancel your PlayFab subscription / Azure billing
• Delete API keys
• Archive the import scripts and mapping tables (don't delete — they're audit trail)
• Remove PlayFab SDKs from your client codebase in the next release

Common Pitfalls

• Cloud Script rewrites are 60% of the work, not 20%. Plan timeline accordingly.
• PlayFab "PlayerData" keys are flat; GSB documents are nested JSON. Decide on a schema before you import — fixing it after is painful.
• PlayFab analytics events do NOT migrate. If you depend on PlayFab's event tracking, plan a separate analytics solution (PostHog, Mixpanel, GameAnalytics) or use GSB's tracking endpoints.
• Don't skip the parallel-write period. Cutting over without it is the #1 source of post-migration data loss.

Cost Comparison After Migration

Indie studios moving from PlayFab to GSB typically see 30-60% cost reduction at the 1,000-10,000 MAP scale, primarily because GSB's flat tier pricing is predictable while PlayFab's usage-based bills scale unpredictably with API call volume.

Scale	Typical PlayFab cost / mo	GSB cost / mo
100 MAP	$0 (free tier)	Free
1,000 MAP	$30-80 (highly variable)	$19
10,000 MAP	$200-500	$99
50,000 MAP	$800-2,500	$399

Bottom Line

Migrating from PlayFab to GSB is not a weekend project, but it's a tractable 1-3 week effort for most indie games. The biggest wins post-migration are predictable pricing, no Azure account dependency, simpler API surface, and the option to unify your backend with Supercraft dedicated-server hosting under one vendor. The biggest cost is rewriting Cloud Script logic — plan for it.

Ready to start? Sign up for the GSB free tier and start with the parallel-write period in a staging environment. The GSB documentation covers the SDK quickstart for Unity, Unreal, and Godot.