IAM migration: preserve the application journey through cutover

The user signs in through the new identity platform and reaches an empty account. Their previous documents, approvals and application history belong to a different account that the migration did not match. From the identity console, the cutover may look successful. From the user’s desk, work has stopped.

This hypothetical failure captures the central challenge for an identity architect: migrate the application relationship, not merely the sign-in. Authentication, account maintenance and resource ownership must continue to agree throughout the transition.

Sequence by application dependency

Group applications by business consequence and integration complexity. Include their authentication method, provisioning path, local accounts and recovery requirements. An easy pilot is useful for learning the tooling, but it should not become evidence that the difficult cohort is ready.

Choose an early representative cohort that exposes the important complications without putting an uncontrolled business-critical service at risk. Include existing accounts, changed names or addresses, temporary access and at least one lifecycle change. Application owners should help define acceptance because they understand what work must survive.

Settle matching before enabling creation

Microsoft Entra’s provisioning process uses configured matching attributes to look for an existing target account; if no match is found, it can create one. That makes matching a substantive migration decision, not a housekeeping field.

Inspect representative existing accounts before the cutover. Determine which identifiers are stable and how historical duplicates will be handled. A familiar email address may be useful, but the team must understand what happens when it changes or differs between systems.

Where an account cannot be matched confidently, resolve it before broad automation proceeds. Creating a second account can be easier than later reconciling ownership, audit history and permissions. The right outcome is continuity of the authorised relationship, not simply a clean import count.

Control coexistence explicitly

During transition, two systems may be capable of changing the same application account. Decide which one is authoritative for each attribute and lifecycle action. Avoid an arrangement in which an administrator fixes a value and a later synchronisation silently changes it back.

Document when responsibility moves. Authentication might transfer before provisioning, or the reverse, depending on the application and migration design. Treat those as separate changes with separate acceptance evidence. The SSO and provisioning explainer helps make that distinction clear to application owners.

Keep departures and urgent removals working through the transition. A migration window is not a reason for the organisation to lose track of which system must end access.

Rollback includes the changes made after cutover

Returning authentication to the previous provider may be only part of rollback. New accounts, changed roles and transferred resources may need reconciliation. Establish the point beyond which reversal becomes a recovery exercise rather than a simple configuration change.

Use explicit triggers: a critical application fails its acceptance test, account matching produces unexplained duplicates, or the support team cannot recover an affected user within the agreed operating constraints. Decide who can stop expansion and who can authorise a return.

Preserve an appropriate emergency administrative route and test it under the planned conditions. The identity outage guide examines why recovery must not depend entirely on the identity path being changed.

Accept the cohort at the application

Have users complete real representative tasks, including access to existing resources and a role change. Confirm departure behaviour separately. Give the support team the failure cases encountered during the pilot, not only the successful configuration steps.

Then expand in cohorts whose risks the evidence supports. Track unresolved exceptions without hiding them in a programme-wide completion percentage. A smaller cohort with understood behaviour is a better basis for the next cutover than a larger migration whose account relationships remain uncertain.

The final handover should leave each application owner able to explain how access starts, changes, ends and recovers. That is the continuity the business purchased when it approved the migration.