Identity platform migrations fail less often at cutover than in the months either side of it, when two systems both issue access, neither is fully governed, and the old one is never quite switched off. Moving from one identity provider to another, from on-premises federation to cloud authentication, or from one IGA product to another touches every application, every joiner and leaver, and every non-human identity that authenticates through the platform. This guide sets out how to sequence such a migration: inventory, coexistence design, pilot rings, cutover, rollback and decommissioning, with the controls that keep access reviews, separation of duties and audit evidence intact throughout. It is for IAM architects, IGA owners and programme leads. Product selection is covered in the IAM and IdP Buyer's Guide and the IGA Buyer's Guide; this page starts once the decision is made.
Key takeaways
- Inventory decides the timeline. The number of applications, protocols, custom claims, provisioning connectors and service accounts sets the plan. Most overruns trace back to integrations nobody had listed.
- Coexistence is a security state, not a waiting room. While both platforms are live, every control must exist in one place or the other: MFA, conditional access, provisioning, deprovisioning and logging. Write down which system is authoritative for each.
- Migrate in rings with a rollback per ring. Pilot users and low-risk applications first, privileged users and critical applications last, and a tested, timed rollback for every step.
- Governance must not pause. Access certifications, separation of duties checks and audit trails need a bridge across the migration, or auditors will find a gap of months.
- Decommission deliberately. An old tenant, federation farm or IGA instance left running is an unmonitored identity system with valid trusts. Retire it on evidence of zero use, then remove its trusts and credentials.
Types of identity platform migration
| Migration | What moves | Main risks | Typical coexistence mechanism |
|---|---|---|---|
| Federation to cloud authentication (for example AD FS to a cloud IdP) | Primary authentication, relying party trusts, claims rules, MFA | Authentication outage, lost claims logic, legacy protocols | Staged rollout by group; per-domain conversion |
| IdP to IdP (cloud to cloud, or mergers) | SSO applications, MFA enrolments, policies, admin roles, API integrations | Re-enrolment phishing, broken SAML or OIDC integrations, duplicated admin access | One IdP federated to the other; per-application cutover |
| Directory consolidation (forest or tenant mergers) | User and group objects, identifiers, groups used for authorisation | Identifier collisions, lost group-based access, orphaned accounts | Synchronisation between directories; dual accounts |
| IGA platform replacement | Identity sources, connectors, roles, policies, certifications, workflows, history | Certification gap, lost SoD rules, provisioning drift, lost audit history | Parallel run with one system authoritative per application |
| PAM platform replacement | Vaulted credentials, sessions, rotation jobs | Credentials rotated by both tools, or by neither | Per-account cutover with rotation owned by exactly one tool |
Most real programmes combine two or three of these. Treat each as its own workstream with its own rollback.
Inventory before you design
Build a migration register with one row per integration. For federation migrations, Microsoft's guidance is to document current domain federation settings (for example with Get-MgDomainFederationConfiguration), review settings such as federatedIdpMfaBehavior and PromptLoginBehavior, back up the AD FS configuration and export relying party trusts before any change. The same discipline applies to any platform.
- Applications: protocol (SAML, OIDC, WS-Federation, LDAP, Kerberos, header-based), claims and attribute mappings, signing certificates and their expiry, owners, criticality and user count.
- Provisioning: every inbound source (HR, contractor systems) and outbound connector (SCIM, API, scripts), with the attribute used as the immutable identifier.
- Policies: MFA rules, conditional access, network rules, session lifetimes and custom sign-in logic. Microsoft notes, for example, that custom AD FS
onload.jsbehaviour cannot be replicated. - Non-human identities: service accounts, API tokens, OAuth clients, admin automation and SCIM tokens that authenticate to or through the platform. These are the integrations most often missed. See NHI Inventory Reconciliation.
- Governance artefacts: roles, entitlement catalogue, SoD rules, certification campaigns in flight and their evidence, approval workflows. See the Entitlement Catalogue and Application Onboarding Guide.
- Administrators: every person and identity with admin rights on the old platform, which will need equivalent, least-privilege rights on the new one.
Microsoft's application migration guidance tracks each application through states (initial request, assessment complete, configuration in progress, test configuration successful, production configuration successful, complete and sign-off). A status board like this, with an owner per row, is the programme's single source of truth.
Designing coexistence
During coexistence, define for every control which platform is authoritative. Gaps appear where both teams assume the other system is enforcing something.
| Control | Coexistence decision to record | Common gap |
|---|---|---|
| Primary authentication | Which users and applications authenticate where, by group or domain | Applications that force the old IdP (for example via a domain hint) while users think they have moved |
| MFA and conditional access | Equivalent policies on both sides, or a federation trust that passes MFA claims | Weaker policy on the new side for migrated users; MFA claims trusted without verification |
| Joiners | Which system creates accounts for new staff | New starters created in the old system after its cut-off date |
| Leavers | Deprovisioning reaches both systems until the old one is retired | Leaver disabled in the new IdP but still active in the old one or in its applications |
| Identifiers | Immutable identifier mapping between systems (for example SCIM externalId or an employee ID) | Email used as the key, breaking on name changes; duplicate accounts |
| Logging and detection | Both platforms' sign-in and admin logs reach the SIEM with detections | Old platform logs dropped from the SIEM before it is retired |
| Admin access | Named admins per platform, phishing-resistant MFA, no shared accounts | Migration consultants with broad admin rights on both, never removed |
For federated coexistence, the trust between the two IdPs is itself a high-value target: a forged or stolen signing key on either side may grant access across both. Protect signing keys and monitor trust configuration changes. See the Federation and Trust Relationships Guide and the Golden SAML and Federation Trust Abuse Defence Guide.
Cutover in rings
- Ring 0, the migration team: IAM staff and test accounts. Validate sign-in, MFA, device SSO, password reset and logging end to end.
- Ring 1, pilot users and low-risk applications: a few hundred volunteers across locations and device types, and applications with modern protocols and engaged owners. Microsoft's staged rollout feature, for example, moves selected groups to cloud authentication while the domain stays federated. It supports up to 10 groups per feature, does not support nested or dynamic groups, limits a newly added group to 200 users initially, and can take up to 24 hours to reflect membership edits, so plan ring sizes around those limits.
- Ring 2, broad user population: by business unit or location, with support capacity scaled for each wave.
- Ring 3, complex applications: custom claims, legacy protocols, header-based and on-premises applications, each with its own test plan and owner sign-off.
- Ring 4, privileged users and break-glass: administrators last, once the new platform's controls are proven, and with break-glass accounts tested on the new platform before the old one is touched. See the Break-Glass Account Guide.
- Final cutover: the irreversible or hard-to-reverse step, such as converting a domain from federated to managed. Microsoft recommends starting with a test domain or the domain with the fewest users, scheduling off-hours, noting that conversion can take up to 60 minutes, and confirming authentication agents show as active first.
Exit criteria per ring: sign-in success rate at or above the pre-migration baseline, help desk tickets per thousand users within an agreed limit, no open severity 1 issues, and logs for the ring visible in the SIEM. Do not open the next ring until the criteria are met.
User communication: tell users what will change, when, and how to get help, and warn them explicitly that the help desk will never ask for MFA codes. Attackers use migrations as cover for re-enrolment phishing.
Rollback planning
Every ring needs a rollback that has been rehearsed and timed. Write it down before the change, with the trigger conditions and the person who can call it.
| Step | Rollback mechanism | Time to effect | Prerequisite |
|---|---|---|---|
| Pilot group moved to new authentication | Remove user or group from the rollout feature; in Microsoft's staged rollout, users then need one more interactive sign-in before redirecting back to the federated IdP | Minutes to hours | Old IdP still running and trusted |
| Application switched to new IdP | Restore previous SAML or OIDC configuration in the application | Minutes, if the old metadata and certificates were kept | Exported configuration; old signing certificate still valid |
| Domain converted from federated to managed | Re-create federation (for example New-MgDomainFederationConfiguration) and reapply claims rules | Hours | AD FS farm and backups intact; documented settings |
| Provisioning connector moved to new IGA | Re-enable old connector in read-only reconcile, then write | Hours to days | Old connector configuration retained; drift report available |
| MFA re-enrolment | Usually not reversible; fall back to old IdP for affected users | Varies | Old enrolments retained until the ring is signed off |
Microsoft's guidance is to keep the AD FS farm and backups intact until validation is complete and until usage reports show no new authentication requests. Apply the same rule to any old platform: do not decommission until monitoring proves zero use for an agreed period.
Keeping governance intact
- Certification bridge: complete in-flight access reviews on the old IGA, export results and evidence, and schedule the first campaign on the new platform no later than the next due date. Auditors look for continuous coverage. See the Access Reviews Guide.
- Entitlement mapping: map every old role and entitlement to its new equivalent and have business owners sign the mapping. Unmapped entitlements become either orphans or silent over-provisioning.
- SoD rules first: load separation of duties rules into the new platform before it starts provisioning, so the first requests are checked.
- Reconcile before write: run new connectors in read-only reconciliation, compare accounts and entitlements with the target application, and fix drift before enabling provisioning. SCIM servers return a 409 uniqueness error on duplicate
userName, which helps catch collisions, and RFC 7644 warns that paged results can be inconsistent if data changes between requests, so re-check large reconciliations. - History retention: keep old audit logs, approvals and certification evidence for the full retention period, either migrated or archived in a searchable form.
- Admin role review: after cutover, review every admin role on the new platform and remove migration-only access, especially for integrators and consultants.
Non-human identities in a migration
Service accounts, OAuth clients, API tokens and SCIM connector credentials are the integrations most likely to break silently or to survive on the old platform after everyone has moved. Inventory them separately, give each an owner and a target state (re-created on the new platform with least privilege, or retired), and rotate any credential that was handled by migration staff. Old OAuth applications and tokens issued by the retiring platform must be revoked, not just left to expire. See NHI Dormancy Detection for finding what has stopped being used.
Decommissioning the old platform
- Confirm zero authentication and provisioning traffic for an agreed period (for example 30 days) from logs, not from the project plan.
- Remove trusts: federation relationships, relying party trusts, SCIM endpoints, API clients and certificates that point to or from the old platform.
- Revoke admin accounts, service accounts and tokens on the old platform.
- Archive configuration, logs and governance evidence for retention.
- Shut down infrastructure and remove DNS records, so attackers cannot take over abandoned endpoints.
- Record the decommission with evidence in the asset inventory.
Detection and measurement
- Sign-in success rate per ring compared with the pre-migration baseline.
- Authentication still reaching the old platform, by application and user, trending to zero.
- Leaver parity: leavers disabled in both systems within the deprovisioning SLA; any mismatch is a finding.
- Entitlement drift between IGA and target applications after each connector cutover.
- Certification coverage: share of in-scope applications with a completed review in the last cycle, which should not drop during the migration.
- Migration admin accounts remaining after the programme closes; target zero.
Detections to add during coexistence: changes to federation trust settings or signing certificates on either platform, new admin role assignments, MFA method registrations in bulk, and sign-ins to the old platform by users already migrated.
Framework mapping
| Framework | Reference | Migration activity |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2 Account Management; AC-5 Separation of Duties; CM-3 Configuration Change Control; CP-2 Contingency Plan; CP-10 System Recovery and Reconstitution; AU-11 Audit Record Retention | Account parity and leavers; SoD continuity; controlled cutover; rollback; evidence retention |
| NIST CSF 2.0 | PR.AA-05 access permissions managed and reviewed; ID.AM-08 systems managed through their life cycles | Entitlement mapping and certification; decommissioning |
| ISO/IEC 27001:2022 | A.5.18 Access rights; A.8.32 Change management | Access rights continuity; change control for cutover |
| MITRE ATT&CK | T1078 Valid Accounts; T1098 Account Manipulation; T1550.001 Application Access Token | Abuse of leftover accounts, admin changes and tokens on the old platform |
Common failure patterns
- Undocumented integrations: a script or service account authenticating with legacy protocols breaks at cutover, and the quick fix is a permanent exception on the old platform.
- Leaver gap during coexistence: leavers removed from the new system only, keeping access to applications still on the old one.
- Re-enrolment phishing: users trained to expect "set up your new MFA" emails are easy targets for exactly that lure.
- Weaker policy on the new side: conditional access rebuilt from memory, missing device or location rules that existed before.
- Certification gap: no access review for six months or more because the old campaign was cancelled and the new platform was not ready.
- Never decommissioning: the old platform stays online "just in case" with live trusts and admin accounts, and drops out of monitoring.
Lessons from incidents
The Microsoft Midnight Blizzard breach began with a password spray against a legacy, non-production test tenant account without MFA, and continued through a legacy test OAuth application with elevated access to the corporate environment. Leftover environments and the application identities in them are exactly what an unfinished migration leaves behind. The lesson for migration programmes is that decommissioning, including removal of trusts and application permissions, is part of the security scope, not an optional clean-up.
Practitioner checklist
- Migration register covers every application, connector, policy, admin and non-human identity, each with an owner.
- Authoritative system recorded for every control during coexistence.
- Immutable identifier mapping agreed and tested for collisions.
- Rings defined with entry and exit criteria; privileged users and break-glass last.
- Rollback written, rehearsed and timed for every ring and for the final cutover.
- Leavers deprovisioned in both systems until the old one is retired.
- Certification bridge and SoD rules in place before the new platform provisions.
- Both platforms' logs and trust changes monitored in the SIEM.
- Migration-only admin access and credentials removed at programme close.
- Old platform decommissioned on evidence of zero use, with trusts and DNS removed.
Standards and references
- Microsoft Learn: Migrate from federation to cloud authentication
- Microsoft Learn: Migrate to cloud authentication using Staged Rollout
- Microsoft Learn: Application migration phases from AD FS
- IETF: RFC 7644 System for Cross-domain Identity Management: Protocol
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Valid Accounts
Related NHI Mgmt Group resources: SailPoint Hardening Guide · AD FS Security Guide · SCIM Provisioning Guide · Identity Provider and SSO Security Guide · Emergency Identity Operations When the Primary IdP Is Unavailable