Migrating between Microsoft 365 tenants: a complete guide

How to order a migration between tenants by dependencies

A migration between Microsoft 365 tenants must relate people, data, and services before choosing the sequence. A user can use mail, documents, Teams, and apps with the same identity. Treating each component as a separate copy can leave some of the work on the destination and another still linked to the source, with no clear way to use them together.

The project map should show which account each person will have, where each resource will reside, and what relationships will be maintained during the transition. In a departmental migration, it is also checked how users who have already moved will collaborate with those who remain in the other tenant. That coexistence requires your own decisions and testing, rather than relying on it to appear automatically when you copy data.

The tool is selected from that design. The result must be described by workload and property, including limitations and reconstruction tasks. A single product name doesn’t explain what a delegated mailbox, a library with metadata, or a future meeting will look like. The pilot must demonstrate those cases and allow the business to understand the differences they will see.

How to approve the result with a full work cycle

Acceptance is prepared before migrating. Each department identifies the journeys it needs to maintain: logging in, opening information, communicating and using its applications. For each one, it is defined who will test it and what result will allow it to be approved. The technical team adds the transfer, error, and configuration checks that support those tests.

The closure combines both evidences and leaves an operational delivery. The data may have been moved correctly and a dependency is still pending that prevents work; There may also be a known difference that the controller accepts with an alternative. Documenting these situations, those responsible for them, and their follow-up allows you to decide the closure judiciously and organize support without depending on verbal agreements.

What is a Microsoft 365 tenant-to-tenant migration?

A Microsoft 365 tenant is the logical environment in which an organization manages its users, identities, domains, licenses, and cloud services. Exchange Online, OneDrive, SharePoint, Teams, Microsoft Entra ID, Intune, Defender, Purview, and Power Platform are linked, directly or indirectly, to that tenant. When a company needs to move users and data to another Microsoft 365 environment, we talk about a tenant-to-tenant migration or cross-tenant migration.

Microsoft expressly contemplates these projects for scenarios of mergers, acquisitions, divestitures and internal reorganizations. The particularity is that information is not being moved between two folders in the same organization, but rather between two independent administrative, identity and security boundaries. This explains why a user who apparently “is the same” in both environments is not technically the same: his Microsoft Entra ID object, his identifiers, his groups, his permissions and many of his relationships with other services change from one tenant to another.

Official documentation: Microsoft – Plan a Microsoft 365 tenant-to-tenant migration.

When a migration between tenants is usually necessary

The most well-known scenario is an acquisition. One company buys another and, for a time, both continue to work from independent tenants. Later it was decided to consolidate mail, files, Teams and users in a single environment. The reverse scenario is also common. In a split or carve out, a business unit must abandon the current tenant and build its own environment. The difficulty here is not only in deciding what moves, but also what should remain in the original organization.

Why a tenant-to-tenant migration is more complex than it seems

The problem is that Microsoft 365 is deeply interconnected. A Microsoft Teams team can have a Microsoft 365 Group behind it, a SharePoint site, Exchange calendars, personal files stored on OneDrive, a Planner plan, and multiple connected apps. If each service is analyzed in isolation, it is easy to break these relationships. For example, moving a mailbox does not mean that its delegated permissions are automatically resolved. Copying a SharePoint site does not guarantee that all users in the new tenant maintain exactly the same permissions. Migrating a Team does not necessarily imply that Planner, tabs, bots, apps or chats have the same behavior at the destination.

Therefore, the migration architecture must consider dependencies between workloads and establish the correct order to move them.

What can be migrated between Microsoft 365 tenants

The following table summarizes the main workloads. The term “migrate” must be understood with some caution: some services are moved using native mechanisms, others are copied using third-party tools, and others require recreation or reconfiguration.

What Microsoft currently offers for inter-tenant migrations

A few years ago, the usual answer for a tenant-to-tenant project was to use a third-party tool. This is changing. Microsoft now has several native capabilities that cover a growing portion of the landscape. However, we should not talk about “a native tool” as if all of Microsoft 365 was migrated with a single button. There are different mechanisms, with different requirements and licenses.

Migration Orchestrator: a coordination layer

Microsoft 365 Migration Orchestrator aims to solve one of the classic problems of these projects: coordinating the different workloads of a user. Microsoft indicates in its general documentation that the orchestrated model can be used for multiworkload movements and manage the order of dependencies. The service’s detailed documentation continues to distinguish different types of content and specifically mentions Exchange, OneDrive, Teams chats, and Teams meetings in its processes and estimates. At the same time, Microsoft’s general planning documentation already considers SharePoint within the coordinated migration model.

The practical conclusion is simple: Product scope is evolving rapidly. Before committing to a project architecture, it is a good idea to check the current documentation for the exact workload you intend to migrate. Official documentation: Microsoft – Migration Orchestrator overview.

Cross-tenant SharePoint Migration

The arrival of a specific native capability for SharePoint is one of the most relevant changes. Microsoft currently allows you to move sites using SharePoint Online PowerShell without moving the data out of the Microsoft cloud. But the behavior is very different from that of many traditional tools. The destination site must not previously exist, it cannot be merged with an existing one, and the move is one-and-done: There is no pre-migration followed by delta passes.

Microsoft currently documents a maximum of 5 TB or 1 million items per site. Additionally, up to 4,000 sites can be scheduled for migration, and Shared Data Migration functionality supports specific business requirements, including availability for Enterprise Agreement customers and data volume licensing. Therefore, just because a native capability exists does not necessarily mean that it is the best option for any project.

Official documentation: Microsoft – Cross-tenant SharePoint migration.

How to choose the migration strategy

Microsoft differentiates several models. The decision must be conditioned by the size of the environment, the dependencies and the margin of change that the company can assume.

Phased migration is usually more manageable, but introduces an additional difficulty: users in the source and destination tenants may coexist for several weeks. This requires designing email, calendars and cross-tenant collaboration before starting waves.

The assessment: the phase that avoids the most problems

A good assessment answers a seemingly simple question: what do we really have? The answer usually surprises. It is common to find shared mailboxes that no one had included in the project, Teams without owners, abandoned SharePoint sites, applications that send mail using a historical account, Power Automate flows created by employees who no longer work at the company or guest users with access to sensitive information.

The inventory must serve to convert that messy environment into a concrete scope.

Not everything should be migrated

A migration is also an opportunity to clean up. Moving information that no one uses only increases time, cost and complexity. In the assessment, elements should be classified into four broad categories: what is migrated, what is archived, what is deleted and what must be reconstructed at the destination. This is especially useful in SharePoint and Teams. It is common to discover teams that have been inactive for years, duplicate sites, inherited permissions that are too broad, or owners that no longer exist.

Microsoft Entra ID: the real starting point

Before talking about mail or files we have to talk about identity. The data needs to know which user in the target tenant it belongs to and what permissions that new identity should receive. Microsoft currently has Cross-Tenant Identity Mapping (CTIM), a tool designed to map source and destination users one by one and prepare the attributes needed for migration.

In the orchestrated method, Microsoft sets this mapping as a requirement. Additionally, there is one particularly important detail: STEM must be run before assigning certain workload licenses to target users to prevent objects, such as a mailbox, from being provisioned prematurely. This sums up one of the fundamental rules of these projects: do not provision services at the destination without first checking how it will affect the chosen migration method.

Official documentation: Microsoft – Cross-Tenant Identity Mapping.

Domains, UPN and DNS: the most delicate moment of the cutover

A corporate domain like empresa.com It cannot simply be “copied” from one tenant to another. First you have to eliminate the dependencies that it maintains in the source and, then, add and validate it in the destination. This process affects both login and email. That is why it is common to previously prepare accounts with temporary domains onmicrosoft.com or routing domains and reserve the movement of the corporate domain for the outage window.

Before removing the domain from the origin, users, administrators, contacts, groups, Teams, shared mailboxes, resources and any other object that still uses that namespace must be reviewed. Official documentation: Microsoft – Remove a domain from Microsoft 365.

Licenses required for a cross-tenant migration

The Microsoft 365 licenses that the user typically uses do not necessarily cover movement between tenants. Microsoft has specific add-ons. For Exchange Online and OneDrive, Microsoft documents the license Cross Tenant User Data Migration, which is assigned per user and is purchased as a one-time payment for that migration. It can be assigned at source or destination depending on the scenario. SharePoint Shared Data Migration currently uses a different model. Microsoft documents specific availability for Enterprise Agreement customers and licensing in migrated 100 GB blocks.

It is always a good idea to confirm the current business model before closing a quote, because these capabilities are evolving rapidly.

Migrate Exchange Online between tenants

Exchange Online usually marks the perception of the project. If a user can access their documents but cannot send mail, the migration has failed for them. The native Microsoft solution allows you to move mailboxes between tenants using Exchange Online PowerShell and the MRS service. The user must be correctly prepared in the target tenant as MailUser with the necessary attributes to identify the source mailbox.

After the move, the source mailbox is no longer a mailbox and Microsoft retains a MailUser with a routing address to the destination. This can facilitate the temporary coexistence of mail.

What content is moved

Microsoft indicates that the native migration moves the user’s visible content, including mail, contacts, calendar, tasks and notes. However, it should not be interpreted as a complete copy of all Exchange settings.

The holds problem

This is one of the points that must be detected in the assessment. Microsoft currently states that mailboxes subject to any type of hold are blocked for native cross-tenant movement. That means that a project with Litigation Hold, eDiscovery, or retention policies should be discussed with the security and compliance team before making changes. Removing a hold simply to be able to migrate can have legal implications, so it should never be done without validating the requirement that gave rise to it.

Official documentation: Microsoft – Cross-tenant mailbox migration.

OneDrive migration between tenants

OneDrive seems simpler because it essentially contains files. However, it also contains shared links, external permissions, content synced across devices, and files used indirectly by other apps. Microsoft offers native cross-tenant migration using SharePoint Online PowerShell. You can schedule up to 4,000 OneDrives for movement, keeping the data within Microsoft 365 and leaving a redirect to the old location after the operation is complete.

During the move there is a brief window in which the OneDrive is in read-only mode. Microsoft speaks of a few minutes under normal conditions, although it should not be used as a contractual guarantee. One fundamental difference: there is no delta. Native OneDrive migration is one-and-done. Content moves; there is no first pass followed by incremental syncs.

This characteristic has a direct consequence on the design of the project. A tool that allows pre-stage can copy much of the data days before and only synchronize changes during the cut. The native OneDrive method works differently and should be planned with this in mind. Do not provision the destination OneDrive. Another critical detail is that the user’s OneDrive must not previously exist on the target tenant when using this native migration. If the user enters OneDrive and causes it to be provisioned prematurely, the operation may fail because Microsoft does not allow merging the content with an existing OneDrive.

Official documentation: Microsoft – Cross-tenant OneDrive migration.

SharePoint Online Migration

SharePoint probably requires the most in-depth document analysis. Two sites of the same size can have completely different complexity if one contains simple documents and the other uses single permissions, metadata, Power Automate, Power Apps, external sharing, and a connection to Microsoft Teams. Before deciding how to migrate it, it is important to understand the actual structure of the environment.

The new native option from Microsoft

Cross-tenant SharePoint Migration allows you to move sites directly between tenants. Like OneDrive, it’s a one-and-done operation. It does not allow you to pre-create the target site, overwrite it, or run delta passes. Current documentation limits each individual site to a maximum of 5 TB or 1 million items. Additionally, if the source tenant uses Service Encryption with Microsoft Purview Customer Key, native migration may not be supported.

An interesting advantage is that when finished, Microsoft leaves a redirect in the old location to help maintain links to the new site. Official documentation: Microsoft – Cross-tenant SharePoint migration.

Microsoft Teams Migration

Teams deserves its own chapter because it is where expectations are most easily confused. For the user, a Team is a single application. Technically, it may contain information distributed between Teams, Exchange Online, SharePoint, OneDrive, and other services. That is why “migrate Teams” must become a much more concrete list of requirements.

Migration Orchestrator currently includes capabilities related to Teams chats and Teams meetings within its user workloads. For a broader migration of teams, channels and applications, review the functionality available at the time of the project or use a specialized platform. The rule of thumb is to never sell “Teams migration” without specifying which Teams elements are included.

Coexistence between tenants while the migration lasts

In a phased migration, one part of the workforce may already be working on the destination tenant while another continues to use the source. During this period, both groups must be able to communicate reasonably. Coexistence can encompass email, free/busy, document access, Teams and applications. Microsoft also has tools such as Cross-Tenant Access Settings, B2B Collaboration, B2B Direct Connect, Cross-Tenant Synchronization, and Multitenant Organization for certain scenarios.

Coexistence should not become a permanent state. The longer both tenants remain connected through workarounds, the more difficult it will be to manage identities, permissions, licenses, and support. Mail and calendars. Exchange allows you to maintain mail routing between users located in different tenants. Furthermore, through Organization Relationships Availability information can be shared to facilitate meeting planning during the transition.

Teams and collaboration. Depending on the scenario, External Access, B2B users, Shared Channels and other cross-tenant configurations can be combined to allow teams to continue collaborating while the consolidation is completed.

Microsoft Purview, retention and compliance

A migration between tenants can become a legal issue if compliance is treated as a secondary consideration. Before moving information, you must understand what content is subject to retention policies, what users have holds, what information is classified, and what obligations the destination tenant must continue to comply with.

Purview settings should not be assumed to be transferred automatically. In many projects, the source tenant model is documented and an equivalent or improved configuration is built in the destination.

Power Platform in a tenant-to-tenant migration

Power Platform deserves its own analysis. A seemingly simple flow may depend on a specific account, a SharePoint connection, a mailbox, Dataverse, or an external application. Microsoft has a specific procedure to migrate certain Power Platform environments between tenants. Currently Production and Sandbox environments are the main types supported by this mechanism; others, such as Developer, Trial or Teams, have limitations.

Changing tenants does not eliminate the need to review subsequent connections and dependencies. Power Apps, Power Automate, Power Pages, Microsoft Copilot Studio, and certain Dynamics 365 workloads may require additional steps. Official documentation: Microsoft – Power Platform tenant-to-tenant migrations.

Applications are the great forgotten

A migration can successfully complete Exchange, OneDrive, and SharePoint and still cause a serious issue the following Monday if a business application stops authenticating. This occurs because many applications store tenant-specific references: Tenant ID, Application ID, Object ID, redirect URI, secrets, certificates, service principals, Graph permissions, SharePoint URLs or accounts used for SMTP and automation.

Therefore, the inventory must identify not only which applications exist, but also who owns them, how they authenticate, and what dependencies they have.

What tool to use for a tenant-to-tenant migration

The answer depends entirely on the project. Microsoft is covering more and more scenarios natively, but a specialized platform continues to provide advantages when advanced coexistence, multiworkload migration, centralized reporting, premigration or greater control over Teams and SharePoint is needed.

Quest On Demand Migration. Quest On Demand Migration is especially interesting when you need to work with multiple workloads from a single console. It allows discovery, user mapping, migrations and certain coexistence scenarios. For organizations with Exchange Online, OneDrive, SharePoint and Teams, the ability to centralize operations and reporting can significantly simplify project management. Official reference: Quest – On Demand Migration.

ShareGate, BitTitan and Cloudiway

ShareGate tends to have special interest in projects with a strong presence of SharePoint and Teams. BitTitan continues to be a well-known reference for mail and other data migrations, while Cloudiway offers solutions for different multi-workload and cross-platform scenarios. None of these platforms should be selected solely based on a list of trading functionalities. Before purchasing licenses, it is a good idea to validate what specific elements the current version supports, what permissions it requires, how it manages deltas, what it does with permissions and links, and how it presents the migrated content to the user.

Recommended methodology for a tenant-to-tenant migration

A well-organized migration usually goes through the same phases, regardless of the tool chosen.

Why the pilot is much more than “migrating two users”

A pilot only adds value if he represents reality. Choosing two users with small mailboxes, no delegations, no Teams, and few documents can give a false sense of security. The pilot should include different profiles: a user with a large mailbox, another with an online archive, someone who manages shared mailboxes, a Teams owner, a user with a large OneDrive, users with external access and, if they exist, profiles with critical applications.

The full experience should also be tried. It is not enough for the tool to indicate “Success”: the user must log in, open Outlook, check the calendar, access OneDrive, open Teams and use the applications they need to work.

The cutover: where all the decisions meet

The cutover is the window in which changes that cannot be brought forward are made. It can include domain, DNS, mail, identity, Outlook profiles, OneDrive sync, and apps. Instead of an impromptu to-do list, use a cutover runbook with those responsible, order, validations and decision criteria.

The migration does not end when “Completed” appears

This is probably the most important idea after planning. A job can complete successfully and still have a permissions issue, an unconfigured application, or a broken link. Validation should be done by workload and, when possible, combine technical controls with a functional check performed by users or business owners.

Hypercare

After the change, it is advisable to reserve a period of reinforced support. Many incidents do not appear immediately. A user may discover three days later that they have lost access to a shared mailbox they only use once a week, or that a SharePoint link used by a third-party provider has changed.

The goal of hypercare is not only to respond to tickets. It is also used to find patterns, correct configurations, and confirm that the environment can transition to normal operation.

Errors that generate the most problems

Tenant-to-tenant projects often fail because of prior decisions rather than the copying process itself.

Frequently asked questions about Microsoft 365 tenant-to-tenant migrations

Where should a migration between tenants start?

You should start with the goal and inventory of identities, data, services, and dependencies. The project needs to know who will move, what information corresponds to them and how they will work at the destination. This basis allows you to design the sequence, check requirements and choose tools with a specific scope before setting the change window.

Can Microsoft 365 workloads be migrated as independent projects?

Tasks can be organized by workload, but their dependencies must be coordinated. Identity, mail, documents, and collaboration can share users and resources. The design should check how they will function during each phase and what relationships are needed between tenants. Independent copying of data alone does not guarantee operational continuity.

What should the pilot of a migration between tenants include?

It must represent the profiles and resources that can affect the result: differentiated permissions, delegations, external collaboration, meetings or relevant applications. Origin data, expected result and test at destination are documented. Differences are resolved or expressly accepted before extending the procedure to the rest of the organization.

When is the project considered completed?

When the included workloads and processes have been validated, differences have been explained and there is an operational delivery to manage the destination. Pending issues need responsibility and follow-up. The decision on origin is made after reviewing dependencies and retention; A completed transfer status does not by itself constitute closure of the project.

Final recommendations: a good migration is decided before starting to copy data

A Microsoft 365 tenant-to-tenant migration It is a project of identity, data, collaboration and security. The technology that moves content is important, but it’s only part of the job. Microsoft currently offers many more native capabilities than a few years ago: Exchange Online, OneDrive, SharePoint, Migration Orchestrator and Identity Mapping already form a much more complete ecosystem of cross-tenant tools. However, each has its own behavior, licenses and limitations.

In certain projects, these capacities will be sufficient. In others, tools such as Quest On Demand Migration, ShareGate, BitTitan or Cloudiway may offer a more suitable model, especially when there are multiple workloads, need for pre-migrations, advanced coexistence or specific requirements on Teams and SharePoint. The correct decision always starts the same: know what is in the two tenants, define what should remain in the destination and build a plan that includes identity, domains, data, applications, security and users.

Then come the tool, the pilot, the waves and the cutover. And only when users can work correctly and validations have finished can the migration be considered closed.

Recommended official documentation

Cross-tenant capabilities are evolving rapidly. Before executing a migration, it is always a good idea to consult the current documentation for the corresponding workload. Microsoft 365 and Migration Orchestrator.

• Microsoft – Plan a Microsoft 365 tenant-to-tenant migration
• Microsoft – Microsoft 365 migration overview
• Microsoft – Migration Orchestrator overview
• Microsoft – Migration Orchestrator planning and prerequisites
• Microsoft – Migration Orchestrator FAQ

Identity.

• Microsoft – Cross-Tenant Identity Mapping
• Microsoft – Cross-tenant synchronization

Exchange Online.

• Microsoft – Cross-tenant mailbox migration

OneDrive.

• Microsoft – Cross-tenant OneDrive migration
• Microsoft – OneDrive cross-tenant migration steps

SharePoint Online.

• Microsoft – Cross-tenant SharePoint migration
• Microsoft – Cross-tenant SharePoint migration FAQ

Domains.

• Microsoft – Remove a domain from Microsoft 365

Power Platform.

• Microsoft – Power Platform tenant-to-tenant migrations

Microsoft Graph.

• Microsoft Graph – Cross-tenant Migration API

Specialized tools.

• Quest – On Demand Migration
• Quest – On Demand Migration User Guide
• ShareGate – Tenant-to-Tenant Migration
• BitTitan – Microsoft 365 to Microsoft 365 migration guide
• Cloudiway – Documentation