Guide
Identity Migration Checklist
Everything that has to be true before a migration wave runs, and everything that has to be proven before it is accepted. Works for an Okta or a Ping Identity starting point.
Identity migration planning · Published and last reviewed July 27, 2026 by PhaseArc.
What belongs on the checklist?
Six groups of checks: discovery of the source estate, a target design decision for every object category, wave plans with entry and exit criteria, controlled execution, validation evidence per application, and an explicit cutover or fallback decision before anything is decommissioned.
Stage 01
Discovery checklist
- Applications listed and grouped by protocol.
- An owner and vendor contact recorded for every application.
- Users, groups, group rules, and assignment paths captured.
- Sign-on or authentication policies and MFA methods documented.
- Provisioning connections and directory synchronization recorded.
- Scripts, API clients, hooks, and reporting pipelines identified.
- Known unknowns written down rather than left implicit.
Stage 02
Target design checklist
- A treatment agreed for every object category.
- Naming convention and group model defined in the target.
- Claims and attribute requirements confirmed per application.
- Policy intent translated into Conditional Access design.
- Authentication methods designed in the target.
- Provisioning target design agreed, including deprovisioning.
- Exceptions logged with an owner and a decision date.
Stage 03
Wave planning checklist
- Waves grouped by owner, risk, protocol, and business calendar.
- Entry and exit criteria written for each wave.
- Change windows agreed and communicated to users.
- Vendor coordination scheduled where metadata or credentials change.
- Fallback position defined and prepared before the wave runs.
- Test plan written for the applications in the wave.
Stage 04
Execution checklist
- Wave approved by the identity team before any change is made.
- Source platform confirmed live for everything not in this wave.
- Prepared changes executed and recorded as they are applied.
- Support informed and ready for the change window.
- Deviations from the plan captured during the wave, not afterwards.
Stage 05
Validation checklist
- Sign-in tested per application, including a non-administrator account.
- Assignments and group memberships confirmed.
- Claims checked against what each application expects.
- Conditional Access behaviour verified for the wave scope.
- Provisioning and deprovisioning confirmed end to end.
- Results recorded as evidence, with exceptions logged.
Stage 06
Cutover and decommission checklist
- Explicit accept, remediate, or fall back decision recorded per wave.
- Federation or domain changes handled as their own wave.
- Remaining source dependencies listed with owners.
- Logs, reporting, and monitoring re-pointed to the target.
- Source platform retired only after decommission is approved.
Checklist questions
What should be on an identity migration checklist?
Discovery of applications, identities, access, policies, and provisioning; a treatment decision for every object category; a named exception list; wave plans with entry and exit criteria; validation per application; and an explicit cutover or fallback decision.
What is most often missed?
Scripts and API integrations built against the source platform, deprovisioning behaviour, and applications with hard-coded issuers or embedded certificates. All three fail quietly rather than loudly.
When is a migration actually finished?
When the final wave is validated and accepted, every dependency on the source platform has a confirmed owner and replacement, and decommission has been approved deliberately.
Official sources
Pair this with the migration map to decide the treatment for each object category.
Work the checklist against a real inventory
An assessment fills in discovery and target design so wave planning starts from facts.