Entra ID migration: How to move users between Microsoft 365 tenants

TL;DR: Entra ID migration is the non-negotiable first step in any tenant-to-tenant migration—get identity staged, mapped, and validated before anything else moves, or you'll spend weeks untangling broken permissions and orphaned accounts on the other side.

‍

When companies merge, restructure, or divest, Microsoft 365 tenants have to follow. And before you touch a single mailbox or SharePoint site, you need to get identity right.

Users, groups, memberships, licenses. That's Entra ID migration, and it's the first step in any tenant-to-tenant project. Skip it or rush it and everything after breaks; permissions fail, mailbox moves orphan data, and you're doing manual cleanup for weeks. We've seen it. It's not fun for anyone.

Here, we'll walk you through what Entra ID migration involves, the proper sequence, how tools compare, and how to plan it so the rest of your migration doesn't fall apart.

Here's everything you need to not break it.

‍

What is Entra ID migration?

Entra ID is Microsoft's cloud identity platform. It manages user accounts, security groups, and access across Microsoft 365. Every mailbox, SharePoint site, Teams channel, and OneDrive belongs to a user identity that lives in Entra ID.

When two organizations merge or a company restructures, those identities need to move from one Microsoft 365 tenant to another. That's Entra ID migration: copying users, security groups, Microsoft 365 groups, group memberships, and license assignments from a source tenant to a target tenant.

It's not a one-click operation. Users need to exist in the target tenant with the right attributes before anything else can move like mailboxes, files, and Teams data. Identity is the prerequisite for all of it.

‍

Why identity migration must come first

Every Microsoft 365 workload depends on user identity. For example:

• Mailboxes belong to users
• SharePoint permissions are assigned to users and groups
• Teams channels have owners
• OneDrive is tied to a user account

Before any content can move to a target tenant, the users it belongs to need to exist there. Skip this step and you'll spend days untangling broken permissions and orphaned accounts after the move.

Bottom line: Get identity right first and every workload migration that follows has a solid foundation.

Want MVP advice? Check out our webinar, How to sequence tenant-to-tenant migrations, with Microsoft MVP Denis Molodtsov

‍

What gets migrated (and what doesn't)

For a user to work correctly in the target tenant, you're migrating these identify objects from one tenant to another:

• Users and their attributes
• Security groups and memberships
• Microsoft 365 groups and memberships

What doesn't move and must be handled separately:

• Passwords
• MFA settings
• Licenses
• Devices
• Conditional access policies
• Application registrations

One thing to plan for before you run: if your source and target tenants use different domains, UPNs will change. That affects how users sign in and how their accounts map to existing content. Be sure to get your mapping right before anything moves.

‍

How to choose an Entra ID migration tool

Entra ID migration tools copy identity objects from the source tenant to the target and let you review and control every mapping decision before anything runs. The right one depends on your migration scope, how much manual work you can absorb, and whether you need identity and content migration handled in the same place.

What to look for in any tool:

• Scope. Does it cover the identity objects you need? Users, security groups, M365 groups, memberships, licenses?
• Re-run support. Can you safely re-run the migration without creating duplicates?
• Pre-migration validation. Does it check for conflicts before you execute?
• User mapping. How does it match source users to target users? UPN? Manual CSV? Deterministic logic?
• Identity and content in one workflow. Or do you need separate tools for identity and content migration?
• Licensing. What does it cost, and does pricing scale with your user count or data volume?

‍

Microsoft's native tooling

Microsoft's Cross-Tenant Identity Mapping (CTIM) is a PowerShell-based tool that maps source users to target users and stamps the right attributes before mailbox migration runs. It works, but you'll need to coordinate between both tenant admins across multiple steps. Also, it covers identity only. Content migration is a separate process.

If you're comfortable with PowerShell and your migration is straightforward, native tooling is a viable option. If you want less manual work and more visibility, a third-party tool is worth the investment.

‍

ShareGate Migrate

ShareGate Migrate (in preview) handles identity and content migration in one place. No external tools. No switching context between scripts and a separate migration console.

Entra ID migration covers users, security groups, Microsoft 365 groups, and group memberships. You review identity data before anything runs, create users in the target tenant, assign licenses, and set auto-generated passwords. Conflicts are visible before execution, not after a failed wave at 2 am. And because real migrations run in multiple waves (late joiners, missed accounts, last-minute org changes), it's safe to re-run at no extra cost. Learn more about ShareGate's Entra ID migration. Or see how it works.

Getting identity and access right during migration also sets you up for Copilot rollout. Oversharing in the source tenant follows content into the target if nobody cleans it up first. Clean it up now. Copilot will surface everything, including the stuff nobody was supposed to see.

‍

Planning your Entra ID migration step by step

A successful migration follows a clear sequence. Here's what that looks like in practice.

Step 1. Inventory everything (source and target)

Before anything moves, document both tenants. Users, groups, licenses, shared mailboxes, distribution lists, storage, Teams, SharePoint sites. The target tenant is rarely empty, especially in M&A scenarios. Know what's already there before you stage anything.

Step 2: Build your identity mapping

Create a single source of truth: a mapping file that defines source UPN to target UPN, source group to target group, and license SKUs to assign.

Watch for collision risk—common surnames and shared group names like Finance, HR, or All Hands often appear in both tenants and need deliberate mapping, not assumptions.

Step 3: Stage users and groups early with sign-in disabled

Provision users and groups in the target tenant weeks before cutover. Keep sign-in disabled. This lets content migration run against destination identities before anyone touches the new tenant. Provisioning and handing out credentials are two separate events. Keep them weeks apart, don't compress them.

Step 4: Validate your mappings before you run

Review every mapping. Catch conflicts before they become production problems. A mismatch caught here is a five-minute fix. The same mismatch after cutover is a much bigger problem.

Step 5: Run a real pilot

A lab test with sample users on a staging UPN isn't a real pilot — it doesn't validate the riskiest piece. Buy a throwaway test domain, put 5-10 users on real devices, run a full DNS swap, and validate on iPhone, Android, and laptop. That's how you find what breaks before the weekend cutover.

Once identity is validated, you're ready to move mailboxes, SharePoint, OneDrive, and Teams.

For a deeper look at how the full sequence connects, watch our webinar, How to sequence tenant-to-tenant migrations, featuring Microsoft MVP Denis Molodtsov.