Why Microsoft 365 tenant-to-tenant migrations fail and how to avoid the most common risks

Tenant-to-tenant migrations are complex processes that can take weeks or even months. During the switch, IT teams have to move thousands of assets, reassign domains across multiple systems, and manage endless user permissions.

This complexity is why, when migrations stall, the culprit is rarely a single technical glitch. Rather, the issue often comes down to identity misalignment, dependency gaps, and incomplete discovery. Each workload—SharePoint, Exchange, Teams, and OneDrive—relies on Entra ID objects. When those aren’t identified, mapped, or recreated correctly, access breaks.

This guide breaks down how to migrate Microsoft 365 tenants to another tenant. We’ll lay out which failures to expect during the move and how to prevent them.

Why can’t you just merge tenants?

Each Microsoft 365 tenant is a separate Entra ID directory with its own user objects, groups, and licensing. Because Entra ID (formerly Azure AD) defines these boundaries, you can’t simply merge two tenants. 

Rather than conducting a simple transfer, you’re reworking tools across the M365 ecosystem. You’ll need to:

• Discover, remap, and recreate OneDrive and SharePoint assets and permissions.
• Set up email users in the new tenant to transfer mailboxes.
• Transfer channels, channel content, and connected services in Teams and M365 Groups.

Microsoft provides some native M365 migration capabilities—but they haven't made the overall tenant-to-tenant migration process easier in any meaningful sense. The built-in tools are scattered, requiring two licensing add-ons to manage user and shared data. Teams migrations are a challenge, too, as there’s no native software designed to move Teams conversations. Instead, you can transfer Teams content to the new tenant, but it won’t preserve the original channel structure. For broader workloads that include complex SharePoint site structures or Teams environments with connected services, you’ll likely need to use third-party migration tools. 

Even with the help of these platforms, failures might happen. That’s why creating a migration plan is so essential—preparing for common errors means IT teams will know what to do if an issue comes up during the move.

‍

Why Microsoft 365 tenant-to-tenant migrations fail

Most tenant-to-tenant migration problems trace back to the same root causes: discovery that didn’t go deep enough, weak identity and access planning, and dependencies that weren’t identified before execution began. These aren’t unpredictable technical failures—they’re consistent, recognizable patterns that show up across projects, environments, and tools. But with the right approach, they’re also preventable.

Incomplete inventory leads to inaccurate planning

Scoping a migration based on storage size alone is one of the most reliable ways to end up with a plan that falls apart mid-project. Storage volume tells you one thing: how many gigabytes (or terabytes) of data exist. It doesn’t tell you how many items need to be moved, where that data is stored across Microsoft 365 workloads, or what dependencies exist—factors that directly impact migration complexity and throughput. 

For example, migrating a single 50GB file is very different from moving 50GB of emails, attachments, and list items spread across dozens of mailboxes, SharePoint sites, and Teams channels. It’s the same storage number, but the second scenario requires far more API calls because the item count is much higher. Each workload also uses different APIs and has different service limits (where you’ll run into throttling), so the same storage footprint can represent very different migration timelines. It depends on both the number of items and how that data is distributed across workloads. 

This also applies to interconnected services. Rather than just being folders, Teams and M365 Groups are a web of SharePoint sites, group mailboxes, and chat histories. Accurately mapping them will help you understand the migration’s complexity.

‍

Identity misalignment breaks access and ownership

Every permission in Microsoft 365—file access, site and team membership, mailbox delegation—is bound to an identity object in Entra ID: user accounts (including guest accounts), groups (including security groups and Microsoft 365 groups), devices (registered or joined devices using Entra ID for access), and applications (app objects and service principals). In a tenant-to-tenant migration, those objects don’t move with your data. They have to be recreated in the target tenant as new objects with new object IDs—and without an explicit mapping between source and target identities, the permissions that referenced those objects in the source can’t be reapplied in the destination.

When identity mapping isn’t properly documented and reestablished, these access failures can surface after the move:

• Users locked out of migrated content: If existing permissions aren’t mapped correctly in the target tenant, users can’t access content in their new Microsoft 365 environment, even when the content itself is migrated successfully.
• Unresolved group memberships: SharePoint permissions and Teams membership depend on Microsoft 365 group and security group objects. Identity gaps or mismatches result in users getting excluded from resources they should have access to—or having access to resources they shouldn’t.
• Guest user access lost: Guest accounts are Entra ID objects specific to the source tenant. They don’t exist in the target until explicitly provisioned there as new objects with new object IDs—meaning any guest access that isn’t accounted for and re-established in the destination is lost after migration.
• Conditional Access policy gaps: Because Conditional Access policies are tightly coupled with Entra ID user objects, IDs, and applications, they cannot be natively “moved” as part of a content migration, but instead must be recreated and mapped in the new environment. If they aren’t in place before the move, users can face unexpected authentication failures or be locked out entirely.

Undiscovered dependencies derail timelines

During a domain cutover, the following dependencies often get missed:

• SharePoint inheritance: Permissions that break from parent to child at the library, folder, or item level require individual permission assignments to be read, mapped, and re-applied in the target. The volume of that work often isn't visible until migration is underway.
• Connected services: Third-party Teams apps, embedded Power BI reports, and custom Power Automate flows all have tenant-specific dependencies that break when content moves to a new tenant.
• Managed metadata: Term stores and managed metadata columns are tenant-specific—content that relied on them might arrive in the target with empty or unmapped fields.

‍

12 M365 tenant-to-tenant migration best practices

These best practices are key to a successful move. We’ve broken each into a three-phase structure: before migration, during, and after.

Before a tenant-to-tenant migration

Locking in a timeline before establishing the migration’s scope will put you behind. Teams will feel pressured to move everything over all at once, making migrations more expensive and complicated than they need to be. Instead, spend time pre-migration defining your scope by doing the following.

1. Build a complete inventory scoped by workload

Audit item counts and dependencies across Exchange (including archives), SharePoint, OneDrive, and Teams. Each has a unique API constraint and storage volume, both of which affect potential throttling and can affect your timeline.

2. Clean up data before migration

Identify what you need to move by deciding:

• What migrates as-is
• What needs remediation before it can migrate (broken permissions, unsupported file names, path length issues, ownerless sites/Teams/groups that need to move over to the target)
• What gets archived (retained but not moved to the new tenant)
• What gets decommissioned entirely

3. Document and map identity objects

Conduct a gap analysis by creating an inventory of all in-scope identity objects, creating an explicit source-to-target mapping, and looking for gaps where target objects don’t yet exist. Based on this information, provision and recreate identity objects in the new tenant before the migration begins.

4. Pre-create users and activate licenses

Before triggering the migration, sign up for a license for the new tenant, and create user profiles in the target.

5. Choose your migration approach and tooling

Decide whether a higher-risk all-at-once migration or lower-risk batch migration suits your needs better. The decision comes down to the amount of data you need to move. Smaller organizations might have better success with migrating all at once since they have fewer files, permissions, and users to manage. Larger enterprises might opt for a slower move to minimize errors and data loss. 

After choosing an approach, pick which migration tool to use. Microsoft has some native options, but they won’t do it all. You’ll need multiple add-on licenses to migrate SharePoint, OneDrive, and M365 Groups, and there’s no built-in tool that manages 1:1 Teams transfers. Third-party tools address these issues under one system rather than scattered platforms. More than that, third-party migration software solves often support phased migrations, reducing throttling risk.

‍

During a tenant-to-tenant migration

Once the migration begins, shift your focus from planning to executing, monitoring, and controlling phases. Microsoft throttling and service limits will constrain the move, so IT admins need to work within these boundaries. Third-party tools help by batching API calls, scheduling work during off-peak hours, and automatically retrying throttled requests. 

To further streamline the execution stage, try these techniques.

6. Run a pilot

Run a test migration before the full cutover. Validate data fidelity, permission construction, compliance configuration, and user access end-to-end across all workloads. Use findings from the pilot to identify and remediate issues before proceeding with the immigration.

7. Migrate in controlled waves

Moving users by department, business unit, or workload allows you to isolate issues and adjust your strategy without disrupting the entire organization’s workflows. Monitor your migration in real time, identifying failures like mapping errors, throttling events, and items that failed to migrate before they cascade into project-wide delays.

8. Monitor migration progress in real time

Many purpose-built migration tools (like SG Migrate) provide reporting and diagnostics as the migration runs—use them. Failed items, throttling events, and permission errors that aren't caught during execution compound into larger remediation work post-migration. Monitoring progress at the workload level across SharePoint, OneDrive, Teams, and Exchange means issues get identified and addressed while the migration is still active, not after final cutover.

‍

After a tenant-to-tenant migration

Completing the migration doesn’t mean the process is complete—validating that everything is working properly finalizes the move. Below are some tips on doing so.

9. Validate access and ownership

When identity mapping isn’t done properly, permissions fail to resolve correctly in the target. Audit your environment to confirm whether users can access their SharePoint and OneDrive content.

10. Confirm collaboration continuity across all workloads

Carry out tests to make sure the following work correctly:

• Teams and M365 group memberships
• Shared channels
• Mailboxes
• External sharing
• Connected functionality across collaboration-focused workloads

11. Review compliance configuration in the target tenant

Most migration tools don’t transfer the existing compliance state into the new tenant. So after the move, IT teams need to recreate, validate, and test compliance in the new environment. This involves reviewing permissions, policies, sensitivity labels, and eDiscovery holds. Companies that skip this task put themselves at risk of exposing sensitive data or facing regulatory fines.

12. Don’t decommission source until everything has been confirmed and validated in the target

Only remove the legacy tenant once you’ve confirmed the new tenant is functioning properly and verified that all content migrated successfully. Premature decommissioning can lead to permanent data loss if you discover an incomplete transfer too late.

‍

How ShareGate supports tenant migrations

Choosing the right Microsoft 365 tenant-to-tenant migration tool is as much about visibility as it is about moving assets and aligning identities. ShareGate audits your source and target environments and provides the predictability you need to migrate to a new tenant with confidence.

Here’s how ShareGate Migrate supports your tenant-to-tenant move:

• Assess your source environment and identify scope: Know exactly what you’re moving and what needs attention before timelines slip. ShareGate’s source analysis report gives you a full inventory of sites, lists, libraries, workflows, and custom code, with complexity scores that highlight risky SharePoint sites and easy CSV export for project plans and key stakeholder sign-offs.
• Fix permissions before they become access risk problems: Prevent post-migration surprises and reduce the risk of Copilot surfacing permissions gaps by fixing access issues in bulk. ShareGate Migrate’s permissions matrix report shows every user, group, and role in one view, while its auto-mapping feature helps streamline the identity mapping process.
• Migrate data fast to keep end users working productively: ShareGate’s easy-to-use UI is quick and easy to set up, while concurrent migrations and support for multi-machine throughput help bypass throttling and keep migration projects on track. You can also schedule incremental Microsoft 365 migrations and use delta mode to copy over only what’s changed since your last run, helping you save bandwidth and allowing users to stay productive while you sync in the background.
• Maintain visibility during execution and get clarity for post-migration validation: Use ShareGate Migrate’s pre-built and custom reports to monitor your migration progress, see any issues that arise along with suggested fixes, and gain valuable insight into post-migration validation.
• Enable controlled, multi-workload execution: Manage OneDrive, Exchange Online, SharePoint, and Teams migrations from a single platform.

‍

Access, map, and validate your M365 migration with ShareGate

ShareGate Migrate brings visibility, mapping, execution, and validation together so IT teams can manage tenant-to-tenant Microsoft 365 migration as a deliberate operation—not a blind transfer. 

To see how ShareGate Migrate makes tenant-to-tenant migrations simple and secure, request a demo today.