Tenant-to-tenant migration: the identity decisions you can't take back

· 5 min read

Every tenant-to-tenant migration project starts with the same slide: mailboxes, OneDrive, SharePoint, Teams. Data volume, throughput, batches. It’s measurable, so it gets planned.

The things that actually go wrong on cutover weekend are rarely about data. They’re identity decisions that were made implicitly — or not at all — months earlier. Some of them are cheap to change during the project and very expensive to change afterwards.

Here are the ones I now force onto the agenda in week one.

1. When does the domain move?

A custom domain can be verified in one Entra tenant at a time. Before you can add contoso.com to the target, you have to remove it from the source — and Entra won’t let you until nothing references it anymore: no UPNs, no proxy addresses, no group mail addresses, no app identifier URIs.

That has consequences people underestimate:

  • The cutover is a hard window. Between removing the domain from the source and verifying it in the target, mail for that domain has nowhere to land. Plan the DNS TTLs, the MX switch and the verification as one scripted sequence, not a checklist.
  • Every object in the source needs a new identity first. Users get renamed to their onmicrosoft.com address (or a temporary domain) before the domain can go. Anything you forget blocks the removal at 2 AM.
  • Coexistence usually means a second domain. If both organisations need to send as the same brand during the project, you need a routing design, not just a migration tool.

Decide early which domains move, in which order, and who owns the DNS changes on the night.

2. What anchors the identity?

If the users are synchronised from on-premises Active Directory, the question is which on-prem object ends up linked to which cloud object in the target — and by what.

In a hybrid setup the link between the AD object and the Entra user is the source anchor (ms-DS-ConsistencyGuid in current deployments, surfacing as onPremisesImmutableId in Entra). If the same AD forest will sync to the target tenant, get this right before the first sync cycle runs against the target:

  • Pre-created cloud users in the target that don’t carry the right anchor will either not match (and you get duplicates) or match on SMTP address in ways you didn’t intend.
  • Once an object is hard-matched, un-matching it is a manual clean-up exercise per user.

If the source is cloud-only, the question changes: are you creating new cloud users, or are you taking the opportunity to move to a synchronised model? Don’t let a migration tool’s default decide that.

3. Credentials don’t move

This one is obvious once said out loud, and still regularly forgotten in the communication plan:

  • Passwords don’t migrate between cloud-only tenants. There’s no export of password hashes.
  • MFA and passwordless registrations don’t migrate. Authenticator, FIDO2 keys, Windows Hello for Business — users register again in the target.

So the real question is: how does a user sign in for the very first time in the target tenant, securely, on Monday morning? A Temporary Access Pass per user, issued through a process your service desk can actually run at scale, is usually the cleanest answer. Test that flow end to end with pilot users, including the device side.

4. Object IDs change — and a lot of config points at them

Every user, group, app registration and service principal gets a new object ID in the target. That breaks anything that references IDs rather than names:

  • Conditional Access policies reference groups, users, roles and named locations by ID. Exporting policies from the source via Graph is easy; importing them without remapping every ID gives you policies that silently target nobody.
  • App registrations get a new application (client) ID. Every app, script and integration that authenticates with the old one needs to change. SAML apps need new metadata on the service provider side.
  • Group-based licensing, access packages, role assignments — all of it needs to be rebuilt or mapped.

Build the ID mapping table early (source ID → target ID, per object type) and make every configuration export go through it. That table becomes the most valuable artefact in the project.

5. Devices start over

There is no supported way to move an Intune-enrolled device from one tenant to another in place. In practice:

  • Devices are re-enrolled into the target, typically via a reset or a fresh Autopilot run.
  • Windows Autopilot registrations have to be removed from the source before the hardware hash can be imported into the target.
  • Compliance-based Conditional Access in the target will block devices that aren’t enrolled yet, so sequence the device wave and the CA policies together.

The device plan is where the user experience is made or broken. Decide per population — frontline shared devices, knowledge workers, BYOD — rather than one approach for all.

The week-one list

If you take one thing from this: before anyone talks about mailbox throughput, get written answers to these five questions.

  1. Which domains move, in which order, and what is the cutover sequence?
  2. What is the source anchor, and how will objects match in the target?
  3. How does every user sign in for the first time in the target?
  4. Where is the object ID mapping kept, and who maintains it?
  5. What is the device path per user population?

None of these is hard to answer on day one. All of them are hard to change on day ninety.