This guide helps you migrate from the older PlayFab v1 SDKs to the new PlayFab Unified SDK v2. The unified SDK consolidates previously separate SDKs (Core, Services, Party, Multiplayer) into a single, integrated solution with improved interoperability and simplified authentication.
Overview of Changes
The PlayFab Unified SDK v2 introduces several key improvements:
- Unified architecture: All PlayFab services (Core, Services, Party, Multiplayer, GameSave) are integrated into a single SDK
- Simplified authentication: One login provides access to all PlayFab services through entity handles
- Automatic token management: No more manual token refresh or entity ID management
- Improved interoperability: Seamless communication between different PlayFab services
- Streamlined project structure: Single SDK installation instead of multiple separate packages
Project Structure Changes
For GDK Users
Legacy layout (GDK 2504 and earlier):
- Separate extensions for each SDK component
- Individual include and library folders: PlayFab.Services.Cpp, PlayFab.Party.Cpp, PlayFab.Multiplayer.Cpp
- Each service had distinct ExtensionLibrary names in GDK
- Multiple downloads required for different PlayFab services from GitHub
New layout (GDK 2510 and onward):
- Single unified PlayFab SDK
- Platform-organized structure with subfolders (xbox, windows, etc.)
- All headers consolidated in one includes folder (Core, Services, Multiplayer, Party, GameSave)
- Combined libraries in unified lib folder
Updating Your Project References
During the transition period (GDK 2510), both old and new SDKs coexist. To migrate:
- Remove old references: Delete references to PlayFab.Services.Cpp, PlayFab.Party.Cpp, and other individual SDK extensions
- Add unified reference: Reference the new PlayFab Unified SDK or update include/library paths to the unified locations
- Plan for future: Microsoft will remove old folders in future GDK releases (possibly by 2026), so update project files accordingly
For GitHub/Standalone Users
- Replace multiple SDK downloads with the single unified SDK package
- Update project paths to use the new platform-organized folder structure
Authentication and Entity Handling
The concept of entities and entity tokens exists in both versions, but how you use them has been simplified in v2.
Token Management Changes
PlayFab Standalone SDKs (v1) Approach:
- Manual token retrieval using
PFAuthenticationGetEntityTokenAsync
- Manual token refresh when tokens expire
- Passing entity ID and token strings to other services (e.g.,
partyManager.CreateLocalUser(entityId, titlePlayerEntityToken, &localUser))
PlayFab Unified SDK (v2) Approach:
- Automatic token management by the Core SDK
- Background token refresh before expiry
- Pass
PFEntityHandle directly to other services (e.g., partyManager.CreateLocalUser(entityHandle, &localUser))
Migration Steps for Authentication
- Remove manual token management: Delete code that manually retrieves or checks PlayFab tokens
- Store entity handles: Keep the
PFEntityHandle from login and use it across all PlayFab services
- Update service calls: Replace entity ID/token parameters with entity handles
- Handle re-authentication: Use
PFAuthenticationReLogin*Async APIs for re-authentication scenarios
Breaking API Changes by Component
PlayFab Core
Migration Impact: Minimal changes required
- Most Core service calls remain unchanged
- Update include paths to point to unified SDK headers
PlayFab Services
Migration Impact: Minimal changes required
- Most Service calls remain unchanged
- Update include paths to point to unified SDK headers
PlayFab Party (Networking/Voice)
Migration Impact: Small changes required
Initialization Changes
v1 Initialization:
v2 Initialization:
Local User Creation Changes
v1 Approach:
v2 Approach:
Migration Steps for Party
- Update initialization: Replace simple
PartyManager::Initialize() call with configuration struct approach
- Remove token retrieval: Delete any code that manually gets entity ID/token for Party
- Pass entity handles: Use
PFEntityHandle directly instead of string parameters
- Remove token refresh logic: Delete code that periodically checks or refreshes Party tokens
- Update dependencies: Ensure PlayFab Core is initialized before
PartyManager::Initialize()
- Remove XBOX-specific calls: Replace
PartyXblManagerInitialize() with generic PartyInitialize() on XBOX
PlayFab Multiplayer (Lobby & Matchmaking)
Migration Impact: Small changes required
Core concepts (Lobby, matchmaking Ticket) remain the same, but functions now expect entity handles instead of strings.
Lobby Operations Changes
v1 Approach:
v2 Approach:
Migration Steps for Multiplayer
- Update function calls: Replace PlayFab ID and entity token parameters with
PFEntityHandle
- Remove authentication steps: Delete separate “Authenticate Multiplayer” calls
- Initialize explicitly: Call
PFMultiplayerInitialize() and potentially PFMultiplayerStartProcessing()
- Update matchmaking: Use entity handles in matchmaking ticket creation
General Migration Checklist
Code Updates
Testing Checklist
After migration, verify each subsystem:
Common Issues and Solutions
Compiler errors about missing parameters:
- Check if function signatures changed to require
PFEntityHandle
- Ensure you’re passing the entity handle instead of string IDs
Runtime authentication failures:
- Verify PlayFab Core is initialized before other services
- Check that login completes before creating local users in Party/Multiplayer
Performance regressions:
- Rare, but verify v2 doesn’t introduce issues in performance-critical code paths
Benefits of Migration
Code Simplification
- Reduced complexity: Remove workaround code for v1’s service separation
- Unified error handling: All PlayFab services use consistent error reporting
- Centralized authentication: One login flow for all PlayFab features
Improved Interoperability
- Seamless integration: Adding new PlayFab features requires minimal setup
- Better multi-user support: Unified SDK handles multiple local users more effectively
- Consistent entity model: Same authentication approach across all services
Future-Proofing
- Active development: v2 is the actively maintained version
- New features: Future PlayFab capabilities will target the unified SDK
- Long-term support: v1 SDKs will eventually be deprecated
Next Steps
- Update project structure: Migrate to unified SDK layout
- Refactor authentication: Implement entity handle-based approach
- Test thoroughly: Validate all PlayFab functionality works correctly
- Clean up code: Remove deprecated v1 workarounds and manual token management
- Monitor performance: Ensure migration doesn’t introduce performance issues
For additional help, refer to the PlayFab Unified SDK documentation and samples for your specific platform. Last modified on August 20, 2026