Entra ID cutover: the identity switch is a sequence, not a copy
Nobody's account moves from one tenant to another — you build a new identity in the target and match it to the old one, and everything attached to that identity has to be rebuilt in the right order or your users get locked out on switch day.
New to cloud? CAMPUX is a free, build-first course. Start here →
The identity cutover is the part of a tenant-to-tenant migration people underestimate, and it is the part that locks users out when it goes wrong. This note is one piece of a larger guide — the full Azure tenant-to-tenant migration field manual covers mailboxes, files, and Teams alongside it. Here the focus is narrow: the Entra ID switch, why it goes first, and why treating it as a copy is the mistake that ends in a support queue a mile long. A tenant is an isolated directory. You do not lift a person out of one tenant and drop them into another. You provision a new account in the target and connect it to the source identity, and only then do the mailbox, the files, and the Teams data have something to land on.
Why identity is sequenced first
Every workload you migrate later — mailbox, OneDrive, SharePoint, Teams — attaches to a user object in the target tenant. If that object does not exist yet, or exists but is not matched to the right source person, there is nothing for the data to migrate onto. So identity is the foundation you pour before anything else. Microsoft's own planning guidance puts identity strategy first: decide how users map from source to target, decide whether they keep their UPN or get a new one, and plan any domain transfers before you touch a single mailbox. Get the identity layer wrong and every downstream workload inherits the error.
Accounts are provisioned and matched, not moved
In the target tenant you create a user object for each person and match it to their source identity — usually keyed on a stable attribute so the migration tooling knows account A in the old tenant equals account B in the new one. The source object keeps existing the whole time. That is what coexistence means: for a stretch, the same human has a live account in both tenants, and you route mail and share calendars between them until the switch is complete. The account in the target is genuinely new. It has a new object ID, a new set of tokens, and none of the history bolted onto the old one.
The sharp edge here is the UPN and primary SMTP address. A user's sign-in name and email depend on a domain, and a domain can be verified in exactly one tenant at a time. You cannot claim contoso.com in the target while it still lives in the source. So users often run on a temporary .onmicrosoft.com UPN in the target until the domain is released from the old tenant and re-verified in the new one — a hard dependency that shapes the entire timeline.
The same person exists in both tenants at once, and the new account carries none of the old one's history.
What does not transfer — and has to be rebuilt
This is where copy-thinking hurts. Several things you assume are part of the user are not part of the object that lands in the target tenant, and each has to be stood up from scratch:
- MFA registration. A user's registered authentication methods live in their home tenant and do not follow the identity. Every migrated person re-registers MFA in the target. Do this at the wrong moment and the entire population hits enrollment on the same morning.
- Conditional access. Policies are per-tenant and enforced after first-factor sign-in in the tenant that owns them. None of the source policies exist in the target until you recreate them. Sign users into a tenant with no policies and you have handed out access with no controls.
- Self-service password reset. SSPR registration is tenant-scoped like MFA. Users re-register, or the first forgotten password becomes a helpdesk call instead of a self-service reset.
Rebuild these ahead of the switch, not during it. Recreate conditional access in the target and run it in report-only mode first so you can see what it would block before it blocks anyone. Stage MFA and SSPR registration so people enroll on their own schedule instead of all at once under pressure.
Guests and cross-tenant access during coexistence
While both tenants are live, people in one need to reach resources in the other, and that runs through cross-tenant access settings and B2B collaboration. You configure inbound and outbound access between the source and target so a user in the old tenant can open a file or join a meeting in the new one as a guest. Trust settings are the useful lever: you can tell the target to trust the MFA claim a user already satisfied in their home tenant, so external users are not prompted twice while your own conditional access still applies. Set this deliberately — the defaults do not trust MFA or device claims from other Entra organizations, so a guest can face a second MFA wall unless you configure trust on purpose.
At a high level the identity switch runs like this: provision and match target accounts; stand up conditional access in report-only, then enforce; stage MFA and SSPR registration; configure cross-tenant access for coexistence; migrate mailbox, files, and Teams onto the matched accounts; release the domain from the source and re-verify it in the target so UPNs and mail addresses finalize; flip authentication so users sign in to the target for real. The rule underneath all of it: identity and its controls land before you move authentication, never in the same window.
Leave yourself a way back
Because the source objects still exist through coexistence, you have a rollback — but only if you protect it. Do not decommission source accounts, release the domain, or tear down source conditional access the moment the target looks healthy. Keep the old tenant able to authenticate its users until the target has proven itself for a real business day, ideally longer. The expensive failure is releasing the domain too early: once contoso.com is out of the source and mid-verification in the target, users can sign in to neither, and there is no fast undo. Sequence the irreversible steps last, and confirm each one before you take the next.
The takeaway
An Entra ID cutover is a sequence, not a copy. Accounts are provisioned in the target and matched to source identities; UPN and primary SMTP wait on a domain that can only live in one tenant at a time; and MFA registration, conditional access, and SSPR do not transfer and must be rebuilt before authentication moves. Order the work so identity and its controls are in place first, stage the enrollments so nobody hits a wall on switch day, and keep the source alive as a rollback until the target has earned the handover. That ordering is the whole job.
Questions people also ask
Do Entra ID accounts move between tenants during a migration?
No. A tenant is an isolated directory, and objects do not physically move out of one into another. In the target tenant you provision new user objects and match them to the source identities, then migrate mailboxes and files against those new accounts. The source object keeps existing until you decommission it, so plan for a period where both tenants hold a version of the same person.
Does MFA transfer between tenants?
No. MFA registration lives on the user object in one tenant and does not follow the identity to another. Every migrated user re-registers their authentication methods in the target tenant. If you provision accounts and cut credentials over in the same window, the whole population hits MFA enrollment at once, so stage registration ahead of the switch and expect it to be your busiest support queue.
What happens to conditional access policies after a tenant migration?
Nothing carries over. Conditional access policies are per-tenant and are enforced after first-factor authentication in the tenant that owns them. You rebuild every policy in the target tenant before users sign in there, or you either lock people out or leave a window with no controls. Recreate them, test in report-only mode, then enforce ahead of the cutover.
How do guests keep access across the two tenants during migration?
Through cross-tenant access settings and B2B collaboration. You configure inbound and outbound access between the source and target tenants so users in one can reach resources in the other during coexistence. Trust settings let the target accept MFA claims a user already satisfied in their home tenant, which spares external users a second prompt while your own policies still apply.
What is the biggest risk in an Entra ID cutover?
Lockout from sequencing the switch wrong. If credentials, conditional access, and MFA registration all land in the same window, users authenticate into a tenant that has no controls or cannot complete sign-in at all. The fix is order: provision and match identities first, stage MFA registration and conditional access ahead of time, then flip authentication last with a tested rollback.