Verify the migration

Prove it before you depend on it

Your old system is still serving access right now, which means this is the safest possible moment to check Crossdeck's work — a mistake here costs you nothing, because nothing customer-facing reads from Crossdeck yet. So you verify in the middle: confirm the mapping is right while the old gate still holds, then flip. Skipping this and cutting over blind is the one way to turn a smooth migration into an incident.

Spot-check, then read the migration counts

Two checks, and you've already learned the tool for the first:

• Spot-check with the Identity Explorer. Paste a handful of real user IDs and emails (the tool from Trace any identity) and confirm each lands on the right customer with the right plan.
• Read the migration counts. The migration surface reports how many rows linked, how many are unlinked, and how many are conflicts. Linked is done; unlinked is usually expected; conflicts need you.

Conflicts need a human, not more time

The verification tracks the migration to completion, but it deliberately stops waiting once only conflicts remain — because a conflict won't resolve itself with patience. Auto-link can't fuse a genuine identity conflict (two signals that might be two people), so it surfaces them as a queue for you to decide, exactly the moat you met in Resolve a conflict. Clear that queue — your call — and confirm the unlinked count is what you expect (often Apple and Google subscribers, who have no bulk history and will fill in live).

Then you cut over. "Cutting over" is just rewiring your app to read access from Crossdeck — the isEntitled / useEntitlement checks from Gate your features — instead of your old system. Because you verified first, the flip is a formality.

Verified, cut over, done

Spot-checks pass, conflicts cleared, unlinked count understood — now flip your app to read from Crossdeck. Your customers never notice a thing, which is exactly the point. That's the migration, and the end of the build path through Crossdeck.