A player has 20 hours on Steam and 35 on Xbox, then hits "Link Account" expecting everything to merge cleanly. Now you have two valid progression states competing to be authoritative. Does the level 24 Steam character replace the level 17 Xbox one? Do currencies combine? What happens to duplicate legendary unlocks? Any merge rule risks deleting progress the player considers earned.
That is the real problem behind cross-platform progression. It is not primarily a cloud-save problem; it is an identity, ownership, and state-authority problem. You need to define which account represents the player, which backend owns canonical progression, and how conflicts are resolved when platform states diverge. Storage and transport are the easy parts.
This piece looks at that architecture and the edge cases that usually expose weak designs: platform-independent identity, where progression state should live, what data can travel between ecosystems, why purchases and gameplay progression need separate rules, and how to handle the hardest case—merging two already-active profiles into one.
The terms get used interchangeably, but they describe different systems.
Cross-save moves save data between devices. Cross-progression maintains a single player state across platforms: XP, stats, inventory, achievements, unlocks, and entitlements.
That distinction matters because copying saves does not solve ownership. Premium currency, platform-exclusive items, and conflicting progression states still need explicit rules.
The fragile model looks like this:
Steam save ↔ PlayStation save
That works until both saves contain meaningful progress and disagree. At that point, "sync" becomes conflict resolution. A better model starts with identity:
Steam player → shared game identity ← PlayStation player
Each platform account is an entry point to the same player, and progression belongs to that shared identity rather than to a platform-specific save.
If cross-platform identity is not solved yet, start there. We cover that in backends for cross-platform play. The rest of this piece assumes a shared player identity already exists and focuses on the progression architecture built on top of it.
Teams often start with, "Where should progression live?" The more important question is: "Who owns it?"
A player might sign in through Steam, Xbox, PlayStation, or Epic. Your backend has to decide whether those are four separate players or four platform identities attached to the same player. That decision drives everything else: storage, ownership, linking, and conflict resolution. It helps to separate identity into two layers:
Platform identity authenticates the player with Steam, Xbox, PSN, Epic, and so on.
Game identity represents the player inside your ecosystem and owns their progression.
Multiple platform accounts should be able to link to one game identity. AccelByte follows this model by separating a Studio/Publisher-level user from per-game user data, while allowing multiple platform identities to link back to the same account. The player can enter through any supported platform, but the backend still resolves them to one underlying identity.
The key distinction is simple: platform accounts handle authentication; the game account handles ownership. If you treat those as the same thing, switching platforms can accidentally mean becoming a different player.
Once that identity model is in place, the rest of the architecture becomes clearer. Platform accounts resolve into one game identity, and progression, economy, and player data live as separate domains under that identity. Account linking, offline sync, versioning, and conflict resolution then become cross-cutting concerns rather than the foundation of the system.
Once your identity layer sits above the platforms, the next decision is when players have to link their account.
Required linking happens before meaningful progression begins. It gives every player one canonical identity, reduces duplicate accounts, simplifies support, and avoids most save and entitlement conflicts. The downside is obvious: more friction before the player gets into the game.
Optional linking gets players into gameplay faster, which can help first-session conversion, especially in free-to-play. But the complexity doesn't disappear, it moves downstream. If a player builds progress independently on Steam and Xbox, linking later means you need rules for reconciling saves, inventories, currencies, entitlements, and progression.
For most games with meaningful persistent progression, require linking early—ideally before the player earns anything they would care about losing. That creates a single source of truth from the start and keeps account state predictable. If you defer linking, define and test the merge and conflict-resolution flow before launch. Don't wait for real players with incompatible accounts to force the policy through support tickets. Also avoid launching with optional linking and making it mandatory later. That tends to create player frustration and turns an account-system decision into a live-ops problem.
The practical rule: deferring the login is fine; deferring the account-merging strategy is not.
Cross-progression gets much easier once you stop treating progression as one save blob and split it into domains with clear ownership. Different kinds of state have different requirements. Graphics settings, XP, inventory, achievements, and premium currency do not have the same consistency, security, or conflict rules, so they should not share the same authority model.
Define that up front:
| Player state | System of record | Typical authority |
|---|---|---|
| Campaign / save slot | Cloud Save | Client / server / hybrid |
| XP and level | Statistics / progression | Server |
| Inventory | Inventory service | Server |
| Premium currency | Wallet / ledger | Server |
| Achievements | Achievement / stat system | Server-validated |
| Settings (graphics, audio) | Cloud Save | Client |
| Loadouts | Cloud Save or inventory | Hybrid |
| Platform purchase | Platform store + entitlement service | Server reconciliation |
| Battle-pass progress | Progression / stat service | Server |
| Cosmetic ownership | Entitlements / inventory | Server |
The important column is authority: when two devices disagree, which system wins? Last-write-wins is fine for a graphics setting. For premium currency, it is a duplication exploit waiting to happen. Also avoid putting everything into one cloud-save document just because it is convenient. Freeform game state belongs there, but structured values that other backend systems need to query or reason about should live in purpose-built services.
The general rule is simple: store state where its semantics are understood. Numeric progression belongs in structured systems, freeform state belongs in save storage, and sensitive economy data belongs behind server authority.
Once each state domain has an owner, decide whether it should actually cross platforms. The answer is not always yes. Think in three buckets:
Fully shared: XP, character progression, campaign state, earned cosmetics, loadouts, and other gameplay-earned progress. If the player earned it, it should follow them.
Shared with restrictions: premium currency, purchased items, DLC, subscriptions, and platform-exclusive content. These are constrained by platform policy, commerce rules, and entitlement reconciliation.
Platform-specific: graphics settings, controller mappings, native achievements, and device-specific options. Syncing these across platforms usually creates a worse experience.
That middle category is the important one. It is where cross-progression stops being purely a progression problem and starts intersecting with commerce and platform entitlements. Progression and purchases may appear together in the player profile, but they should not be modeled as the same system.
Consider a common flow: a player buys premium currency on PlayStation, spends it on an item, then launches the game on Steam. Now you have several separate questions.
Does currency transfer? Do purchased items transfer? Is that item allowed on Steam? What proves ownership? And if the PlayStation purchase is refunded later, what needs to be revoked or reconciled?
Those are commerce problems, not progression problems. Keep three concepts separate:
Progression: what the player has done—levels, campaign state, stats.
Entitlements: what the player owns or can access—DLC, battle passes, cosmetics.
Wallet: what economic value the player holds—currency balances and transaction history.
They interact, but they should not share the same source of truth. A refund may need to revoke an entitlement and adjust a wallet without touching the fact that the player reached level 40. That is why cross-progression and cross-commerce should be designed as separate systems. AccelByte reflects this split: progression lives in services such as Cloud Save and Statistics, while purchases are reconciled through Entitlements, wallet systems, and platform-store sync.
The rule is simple: Accomplishment, ownership, and value are different state domains so model them separately.
This is the account-linking case that creates support tickets, so solve it early. A player has a level 24 Steam profile and a level 17 Xbox profile. They link the accounts. Now you need a reconciliation policy. There are four practical outcomes:
Keep Steam: Xbox progress is discarded.
Keep Xbox: Steam progress is discarded.
Merge: combine both profiles into one.
Keep both: preserve separate profiles under the linked account.
Choosing one profile is technically simple but costs the player progress. Keeping both avoids merging, but forces every downstream system to understand multiple profiles indefinitely.
Merging is the hardest option. Currency can be duplicated, unique rewards can collide, quest states can conflict, and mutually exclusive story choices may have no valid combined state. Some profiles simply cannot be merged without breaking the game's own rules.
That is why there is no universal answer. A single-player game may let the player choose a profile. A live-service game with a premium economy may prohibit merging entirely or define strict per-domain rules.
The important part is having that policy before launch. Account reconciliation is a game-design decision, not something support should invent after players start linking accounts.
Linking a second platform account is not just adding another login method. You may be changing which identity owns years of progression, inventory, purchases, and player state. Treat it like a data migration. Do not model linking as a single "connect account" call. Make it a reconciliation flow:
Authenticate the new platform account.
Resolve its existing game identity, if any.
Check both identities for meaningful progression.
If there is no conflict, link them.
If both sides have active state, run the reconciliation policy, show the player the outcome, and require explicit confirmation.
After linking, verify ownership and record the migration result.
That final audit record matters. Store what identities were involved, what state existed before the link, which reconciliation path ran, and what the player selected. When a player later reports missing progress or inventory, support needs a deterministic history of what happened—not a guess.
Solving identity does not solve save conflicts. Even after you know exactly which game profile belongs to a player, you still need to decide which version of that profile is authoritative.
Consider one correctly linked player. They reach level 30 online on console, then play offline on a Steam Deck from an older synced state and reach level 28. When the Deck reconnects, a naive last-write-wins sync can overwrite level 30 with level 28 and silently delete valid progress. That is a save-state conflict, and it is separate from an identity conflict:
Identity conflict: which game profile belongs to this player?
Save-state conflict: which version of that profile is current?
A complete cross-progression system has to solve both. The save layer should track revisions, detect writes based on stale state, and prevent older versions from silently overwriting newer ones. Depending on the game, that may mean rejecting the write, merging supported fields, or preserving both versions and asking the player to choose. This is a deep enough topic that it deserves its own treatment, and it interacts with where your saves live in the first place; we go further into the storage side in platform-native versus game-backend cloud saves and the broader cloud saves and player data piece.
The key point is simple: if you only solve identity conflicts, save conflicts can still cost players progress.
For a competitive or economic state, the answer to "which device owns the truth?" should usually be: none of them. The server does. XP, currency, item grants, battle-pass progress, ranked rating, and competitive achievements should not be directly writable by clients. If a client can author that state, a modified client can forge it. Cross-platform only increases the number of clients and sync paths you need to defend.
With server-authoritative progression, devices submit actions or events and the backend decides the resulting state. That simplifies cross-platform progression because platforms are no longer competing sources of truth; they are clients of the same authoritative system.
The tradeoff is operational complexity. Authoritative actions require connectivity, retries, idempotency, latency handling, and server-side validation. A duplicated reward grant becomes an exploit; a duplicated currency spend becomes a support issue. You also need an explicit offline model for anything that cannot be committed immediately.
That leaves a useful split:
Client-owned: low-risk, device-local, or offline-friendly state.
Server-owned: valuable, competitive, or economy-sensitive state.
AccelByte exposes this boundary directly in Cloud Save through client- and server-writable records. The implementation detail matters less than the rule: decide who is allowed to write each class of state before you build progression around it. Retrofitting server authority onto a live currency or progression system is far harder than designing that trust boundary up front. For a deep dive, see server-authoritative versus client-authoritative architecture.
In a cross-platform game, clients will not always update in lockstep. Steam may be on v1.8 while PS is still in certification on v1.7, and both may be reading and writing the same progression data. That makes schema compatibility a production requirement.
A v1.7 client needs to survive fields introduced by v1.8. More importantly, it must not overwrite or delete data it does not understand. If an older client writes back an entire record using its older schema, it can silently remove progression added by the newer build. Design for staggered versions from the start:
Make schema changes additive where possible.
Version persisted data.
Preserve unknown fields on write.
Migrate older records forward.
Define a minimum compatible client version.
Force updates only when backward compatibility is no longer safe.
Microsoft calls out the same issue in its Game Saves guidance: multi-storefront releases need to account for title updates that do not happen at the same time. The key point is simple: Schema evolution is part of cross-progression architecture. Without it, a normal staggered rollout can become a data-loss bug.
Cross-progression will fail in production. Players will link the wrong account, lose access after unlinking, hit bad syncs, create duplicate profiles, or miss entitlements after a purchase fails to reconcile. The real question is whether support can recover those cases without escalating every ticket to engineering. Define three things up front:
What support can inspect: linked identities, progression state, save history, inventory, entitlements, and account-link audit logs.
What support can change: unlink or reattach identities, restore saves, grant missing items, and repair account state.
What requires escalation: destructive operations such as merges, splits, or irreversible ownership changes.
Unlinking deserves special care. If a platform account is the player's only authentication method, removing it can orphan the underlying game identity and make years of progression unreachable. Prevent that by requiring at least one valid login method, warning before destructive unlinks, and giving support a safe way to reattach access.
Recovery also needs observability. Track link failures, duplicate profiles, reconciliation outcomes, sync conflicts, stale writes, rollback and migration failures, entitlement delays, refund inconsistencies, support volume, and recovery time. Cross-progression bugs are unusually costly because players experience them as lost time or lost purchases. Recovery tooling and operational visibility are part of the architecture, not post-launch support features.
Not every game needs the full stack. The right architecture is the smallest one that matches the state your game actually owns.
Model A: Simple cross-save
Best for mostly single-player games with little or no economy. A shared game identity sits in front of Cloud Save, and most progression lives in save data. You still need identity, but you can avoid heavy economy and server-authority systems.
Model B: Online progression
For multiplayer games with persistent progression, achievements, seasons, and inventory. Shared identity connects to systems such as Statistics, Cloud Save, Achievements, and Inventory, with valuable progression kept server-authoritative. At this point, every state domain needs an owner.
Model C: Full cross-platform live service
For games spanning PC and consoles with premium currency, platform purchases, and LiveOps. Shared identity sits above progression, saves, stats, inventory, wallets, entitlements, and achievements, while platform-store reconciliation runs alongside them. This is where all the hard problems show up together: identity, save conflicts, offline behavior, version skew, entitlement reconciliation, and recovery.
Games like Fortnite and Destiny 2 operate at this scale, but they evolved into it over time. If your game is Model B today and may become Model C later, the identity and ownership decisions you make now will determine how painful that transition is.
Most cross-progression failures come from a small set of early architecture mistakes:
Treating each platform account as a separate player, then trying to unify them later.
Allowing independent progression before defining how existing profiles will reconcile.
Putting all progression into one cloud-save blob, making authority, concurrency, analytics, and integrations harder.
Treating purchases like earned progression, ignoring refunds, entitlements, and platform restrictions.
Letting clients author valuable progression or economy state.
Assuming every platform will run the same build at the same time.
Designing account linking without unlinking, recovery, and support tooling.
Testing only the happy path.
The edge cases are the real system: existing profiles, offline devices, stale clients, duplicate accounts, refunds, reconnects, and failed links. If those cases are not in the design and test plan, they are where production will break.
Before you lock the architecture, you should be able to answer these questions:
Identity: What represents the player across platforms? Is linking required? What happens if a platform account is already linked elsewhere?
Ownership: Which system owns each type of state, and which state is server-authoritative?
Synchronization: What works offline, and what happens when multiple devices are active?
Conflict: How do you resolve identity conflicts and save-state conflicts separately?
Commerce: Which purchases transfer, how are entitlements reconciled, and what happens after refunds?
Versioning: Can older clients read newer data without corrupting or deleting it?
Recovery: Can support inspect history, restore progression, and recover from bad links or orphaned accounts?
Operations: Can you measure failures and trace why a player's state differs across devices?
Cross-progression is not a cloud-save feature. It is the job of keeping one player's state consistent across platforms, devices, client versions, and commerce systems without exposing that complexity to the player. The teams that get it right design the failure modes up front. Define the reconciliation policy before the support tickets define it for you.