Quick summary: what can be migrated between Microsoft 365 tenants

In one sentence: Microsoft 365 can be moved to another tenant, but the real project combines native migration, identity mapping, specialized tools, Microsoft Graph, PowerShell, recreation and, where appropriate, redesign.

Complete table: what can be migrated between Microsoft 365 tenants

The following table provides an initial reference for assessing a migration. “Can be migrated” does not necessarily mean that the object will be identical in the new tenant. Some services preserve content and metadata; others require the destination container to be created first, identities to be remapped, or part of the configuration to be rebuilt.

Microsoft 365 capabilities, licensing requirements, limits and availability may change. The final strategy should always be verified against current documentation and the actual characteristics of the source and target tenants.

What does it really mean when a workload can be migrated?

The fact that a service can be migrated does not necessarily mean that its entire history, configuration, permissions, identifiers and dependencies will appear identically in the new tenant.

In a Microsoft 365 migration, it is useful to distinguish between five different scenarios:

Can Exchange Online be migrated between tenants?

Yes. Microsoft provides Cross-Tenant Mailbox Migration to move Exchange Online mailboxes between tenants. Exchange is also one of the workloads that Microsoft 365 Migration Orchestrator can coordinate as part of a multi-workload migration.

The process moves mailbox content, but it does not move the Microsoft Entra ID identity. Before the migration starts, the corresponding user must exist and be prepared correctly in the target tenant.

What Exchange content can be moved?

Within the supported scope, the content users work with every day can be migrated, including:

• email;
• folder structure;
• contacts;
• calendar;
• tasks;
• notes and other supported items.

The technical details of the migration depend on the scenario, the identities that have been prepared and the configurations present in both tenants.

Can Shared Mailboxes be migrated?

Yes. Shared mailboxes can be included in a cross-tenant strategy, but two concepts should be considered separately: mailbox content and delegations.

A shared mailbox can have Full Access, Send As, Send on Behalf, aliases, rules and relationships with users who may be migrated in different waves. It should therefore not be considered complete simply because its email content already appears in the target tenant.

What happens to Online Archive?

Archive mailboxes must be explicitly included in user preparation and identity mapping. Attributes such as ArchiveGuid, licensing, archive configuration and retention policies can affect the move.

Holds and compliance

Holds can block cross-tenant moves. This check should be carried out before migration waves are created. Discovering an active retention configuration during the cutover window is not a good migration strategy.

Removing a Hold is also not merely a technical decision. Any change must be coordinated with the organization’s compliance stakeholders and legal obligations.

Do aliases, groups and delegations move with the mailbox?

You should not assume that every object associated with a mailbox travels with it. Distribution Lists, Microsoft 365 Groups, mail-enabled security groups, transport rules, aliases and certain delegations require separate handling.

Official source: Microsoft Learn — Cross-tenant mailbox migration.

Can OneDrive be migrated between tenants?

Yes. Microsoft provides Cross-Tenant OneDrive Migration, and OneDrive can also be included in batches coordinated by Microsoft 365 Migration Orchestrator.

The migration uses Cross-Tenant Identity Mapping to associate users and groups in the source tenant with their equivalents in the target tenant. This allows permissions belonging to correctly mapped identities to be transformed.

Are permissions and links preserved?

Permissions can be preserved when the identities involved have been correctly prepared and mapped. Microsoft can also create redirects from the previous location to the new one.

This is especially useful when old links still exist in emails, documents or applications.

The major limitation: native OneDrive migration is one-and-done

This has a direct impact on cutover planning. If the chosen strategy requires copying data initially, allowing users to continue working and then running several differential synchronization passes, the native mechanism may not be the most appropriate method for that particular project.

Holds and Customer Key

A OneDrive account subject to certain retention configurations can be blocked from moving. Microsoft also documents restrictions related to Service Encryption and Microsoft Purview Customer Key in the source tenant.

These conditions should form part of the technical assessment performed before migration.

Should the target OneDrive already exist?

The identity and licensing must be prepared correctly, but provisioning of the target site must follow the requirements of the migration mechanism. Creating target structures without first checking how the migration will be performed can make the move more difficult later.

If you need a deeper look at this workload, see our Microsoft 365 cross-tenant OneDrive migration guide.

Official source: Microsoft Learn — Cross-tenant OneDrive migration.

Can SharePoint Online be migrated between tenants?

Yes, with conditions. Microsoft provides Cross-Tenant SharePoint Migration, a dedicated capability for moving SharePoint sites between tenants. This process operates separately from Microsoft 365 Migration Orchestrator.

The tool uses identity mapping to transform permissions and can maintain redirects to certain locations in the new tenant.

What types of sites can be included in a migration?

Microsoft documents support for different types of SharePoint sites, including modern scenarios and sites connected to Microsoft 365 Groups, provided the corresponding prerequisites are met.

Is it incremental?

No. Like Cross-Tenant OneDrive Migration, the native SharePoint process is designed as a one-and-done move rather than as a continuous delta synchronization tool.

Can the target site already contain content?

Cross-Tenant SharePoint Migration should not be understood as a merge mechanism between two existing sites. The destination must be prepared according to the documented requirements before the move begins.

What happens to Power Apps, Power Automate and workflows?

Moving a SharePoint site does not guarantee that related automations will automatically continue working in the target tenant.

Among other things, you need to review:

• Power Automate flows;
• Power Apps;
• connections;
• connection references;
• owners;
• URLs;
• web parts;
• external integrations;
• legacy workflows.

You can also find more detail in our complete SharePoint tenant-to-tenant migration guide.

Official source: Microsoft Learn — Cross-tenant SharePoint migration.

What can be migrated from Microsoft Teams between tenants?

Different components of Microsoft Teams can be moved, but Microsoft Teams does not migrate as a single unit. Microsoft 365 Migration Orchestrator includes user chats and meetings within its scope, while Teams, Channels and shared SharePoint sites require separate handling.

The reason is simple: several different Microsoft 365 services sit behind the name “Teams.”

Teams Chats

Chats are part of the current Microsoft 365 Migration Orchestrator scope. Even so, the result must be understood within Microsoft’s documented limitations for participants, identities and threads.

A migration should aim to preserve supported history and user continuity rather than promise that every conversation will behave exactly as it did in the previous tenant.

Teams Meetings

Meetings can also form part of the process coordinated by Microsoft 365 Migration Orchestrator and have dependencies on Exchange Online.

For this reason, Exchange and Teams Meetings should not be designed as two completely independent migration projects.

Teams and Channels

The shared Team and its Channels require a dedicated strategy. Creating the target structure, its members, groups, SharePoint sites, applications and other components must be coordinated separately from the simple movement of user chats.

Channel conversations

Microsoft Graph provides migration APIs for importing historical messages into Teams and channels in supported scenarios.

These APIs can preserve historical properties such as the author and timestamp when the scenario and content are supported. However, importing messages does not automatically move the entire Team.

Teams files

Channel files are stored in SharePoint. The Teams strategy must therefore be coordinated with SharePoint. Files shared in private chats also depend on OneDrive.

Planner

A Team may use one or more Planner plans. These plans should not be assumed to have moved simply because an equivalent Team has been created in the target tenant.

OneNote, Lists, tabs and applications

These also need to be inventoried individually. Some tabs are simply references to another resource; others contain applications or configurations that depend on IDs belonging to the previous tenant.

Meeting recordings

Modern meeting recordings are generally stored in OneDrive or SharePoint. The file itself may be included in the migration strategy for those workloads, but its relationship to the original meeting and the subsequent user experience must be validated separately.

For a deeper explanation, see our complete Microsoft Teams tenant-to-tenant migration guide.

Official sources: Microsoft 365 Migration Orchestrator · Microsoft Graph — Teams migration APIs.

Can Microsoft Planner be migrated between tenants?

Partially. Microsoft Graph can work with basic plans, buckets and tasks, but Microsoft Planner does not provide a tenant-to-tenant migration equivalent to Cross-Tenant Mailbox Migration or Cross-Tenant OneDrive Migration.

Copy Plan is not Tenant Migration

The plan-copying capability can be useful in certain scenarios, but it should not be confused with a complete migration between organizations.

A real Planner environment can include:

• plans;
• buckets;
• tasks;
• assignments;
• dates and priorities;
• descriptions;
• checklists;
• labels;
• attachments;
• comments;
• relationships with the Microsoft 365 Group or Team.

Microsoft Graph can read and recreate different elements, making it possible to design a programmatic migration. However, the properties that have a genuine equivalent in the target environment must be assessed.

Planner Premium

Premium plans require a separate assessment. A strategy designed for Planner Basic should not automatically be assumed to work for every type of Planner plan.

Conclusion: Planner can be included in a complete migration, but it generally requires recreation, Microsoft Graph or specialized capabilities rather than a simple “Move plan” operation.

Official source: Microsoft Graph — Planner.

Can Power BI be migrated between tenants?

Partially. Microsoft documents several patterns for moving Power BI and Fabric artifacts between tenants, but also warns that the process can require significant manual effort.

Power BI needs to be assessed component by component. Counting reports alone usually underestimates the real complexity.

The report is only the visible part

A report may open correctly in the target tenant and still be incomplete because its semantic model does not refresh, credentials are missing or the gateway still belongs to the previous tenant.

A serious inventory should therefore include:

• workspaces;
• reports;
• semantic models;
• dataflows;
• gateways;
• datasources;
• credentials;
• refresh schedules;
• RLS;
• capacities;
• Power BI Apps;
• Fabric artifacts.

You can also read our Power BI migration guide for workspaces, reports and semantic models.

Official source: Microsoft Learn — Power BI tenant migration patterns and strategies.

Can Microsoft Intune be migrated between tenants?

Partially. Certain Microsoft Intune policies and configurations can be exported, automated or rebuilt using Microsoft Graph and PowerShell, but devices must be enrolled again in the target tenant.

Policies and Configuration Profiles

Microsoft provides guidance and examples for exporting and importing part of the Intune configuration, but this is not the same as copying the entire endpoint management tenant.

The following should be reviewed separately:

• Configuration Profiles;
• Compliance Policies;
• Endpoint Security;
• applications;
• assignments;
• scripts;
• remediations;
• certificates;
• Wi-Fi;
• VPN;
• BitLocker;
• Windows Autopilot;
• Company Portal;
• Defender;
• Conditional Access.

Devices must be enrolled again

This is the main difference compared with an email or file migration.

The endpoint has a management relationship with the source tenant. To manage it from the target tenant, a new relationship with Microsoft Entra ID and Intune must be established.

The procedure can vary depending on:

• Windows;
• macOS;
• iOS / iPadOS;
• Android;
• device type;
• enrollment method;
• corporate ownership or BYOD.

Autopilot, Entra Join and BitLocker

These components require a dedicated runbook. It must clearly define how the device will move to the new tenant, what happens to Autopilot, which recovery keys need to be retained and when the endpoint will become compliant again.

Official source: Microsoft Learn — Intune migration guide.

Can Power Apps, Power Automate and Dataverse be migrated between tenants?

Yes, in certain scenarios. Microsoft provides tenant-to-tenant capabilities for moving certain Power Platform environments between organizations, although not every environment type or component is supported.

Production and Sandbox

Microsoft documents movement scenarios for certain Production and Sandbox environments with Dataverse. Other environment types require a different approach.

Dataverse

The environment and its data can be included in the supported process, but directory dependencies and post-migration tasks still exist.

For example, you need to review:

• users;
• Security Groups;
• Application Users;
• connections;
• connection references;
• custom connectors;
• environment variables;
• Managed Environments;
• triggers;
• external integrations.

Power Apps

An application may be present after the move and still require changes because its connection points to an old resource, user or tenant.

Power Automate

Flows require particular validation. Connections, credentials, triggers and connection references are among the components that may need to be reconfigured.

Security Groups and Application Users

These objects belong to the directory and must be prepared or recreated in the target tenant where required by the scenario.

Official source: Microsoft Learn — Move an environment from one tenant to another.

Are Microsoft Entra ID users and groups migrated?

Not in the same way as content. Cross-tenant migrations move data and services, while identities need to exist in the new directory and be mapped to their source-tenant identities.

Users receive a new Object ID

A user may ultimately keep the same name and corporate email address, but the Entra ID object belongs to a different directory and therefore has a different identifier.

This change affects:

• permissions;
• groups;
• Enterprise Applications;
• App Registrations;
• Conditional Access;
• Power Platform;
• Power BI;
• applications that store references to Object IDs.

Cross-Tenant Identity Mapping

Microsoft uses identity mapping to associate source users and groups with the new target objects. This mapping is particularly important for workloads such as Exchange, OneDrive and SharePoint.

Microsoft 365 Groups, Security Groups and Distribution Lists

Groups should be inventoried according to their type:

• Microsoft 365 Groups;
• Security Groups;
• mail-enabled security groups;
• Distribution Lists;
• Dynamic Groups;
• objects synchronized from Active Directory.

They do not all have the same recreation process or the same dependencies.

Hybrid objects and on-premises Active Directory

Where synchronized users exist, the project must determine the future source of authority, how matching will be performed and what the future Microsoft Entra Connect or Cloud Sync configuration will look like.

Enterprise Applications

Enterprise Applications contain tenant-specific service principals. SSO, assignments, provisioning, certificates, claims and consent must all be reviewed.

App Registrations

These also require separate analysis. Client IDs, redirect URIs, secrets, certificates, API permissions and admin consent may require a new configuration in the target tenant.

Official sources: Cross-Tenant Identity Mapping · Application objects and service principals.

Can you keep the same domain when moving to another tenant?

Yes, but it requires a controlled cutover. The corporate domain must be released from the source tenant before it can be added to the target tenant and used normally again.

Why can’t you simply change DNS?

Because the domain may be used by many internal objects:

• user UPNs;
• ProxyAddresses;
• aliases;
• shared mailboxes;
• Distribution Lists;
• Microsoft 365 Groups;
• mail contacts;
• Teams;
• administrative accounts;
• applications and integrations.

As long as incompatible references remain, Microsoft can prevent the domain from being removed from the previous tenant.

MX, SPF, DKIM, DMARC and Autodiscover

Once the domain has been moved, mail flow and DNS configurations must also be checked:

• MX;
• SPF;
• DKIM;
• DMARC;
• Autodiscover;
• connectors;
• third-party gateways;
• SMTP relays;
• applications that send email.

Official source: Microsoft Learn — Remove a domain from Microsoft 365.

Are Conditional Access, Purview and Defender migrated?

Not automatically with the content. Security and compliance policies belong to the tenant and must be inventoried, rebuilt and adapted to the new identities, groups, applications and devices.

Conditional Access

Microsoft Graph can be used to retrieve and create Conditional Access policies, making it possible to automate part of the reconstruction.

However, copying a policy literally does not guarantee that it will work in the target tenant because the following may have changed:

• users;
• groups;
• roles;
• applications;
• Object IDs;
• exclusions;
• Intune dependencies.

Microsoft Purview

DLP, retention, sensitivity labels, eDiscovery and other configurations must be assessed as part of the project. Migrating the data does not mean that compliance policies will automatically be configured in the new tenant.

Holds

In addition to their compliance function, Holds have a direct impact on migration: certain Exchange, OneDrive and SharePoint moves can be blocked while an incompatible retention configuration remains in place.

Microsoft Defender

Defender includes multiple products. Defender for Office 365, Defender for Endpoint and other capabilities must be reviewed according to what the organization actually uses.

An opportunity not to copy historical technical debt

A tenant migration is also a good opportunity to review configurations that have accumulated over many years.

It does not always make sense to reproduce:

• old temporary exclusions;
• groups without owners;
• duplicate policies;
• rules created for systems that have already been retired;
• exceptions that nobody can justify.

Official sources: Microsoft Graph — Conditional Access policy · Microsoft Purview.

What changes for users after a tenant-to-tenant migration?

The goal is to minimize the impact on day-to-day work, but a tenant-to-tenant migration involves new identities, new service endpoints and, in some cases, new authentication prompts. The exact user experience depends on the workloads included and how the cutover has been designed.

The most common changes can affect:

Can it be done without downtime?

It is not advisable to promise absolute “zero downtime.” The right goal is to minimize disruption through advance preparation, pilots, migration waves, coexistence where possible and a well-designed cutover window.

Can data loss be avoided?

A professional migration should use validation and acceptance criteria to confirm that the expected content is present in the target tenant. It is also important, however, to identify in advance which elements do not have a 1:1 equivalent so that a known limitation is not mistaken for a migration failure.

What happens to Forms, Loop, Viva, Bookings, Lists and other services?

They need to be assessed separately. Microsoft 365 includes many more services than Exchange, OneDrive and Teams, and several of them do not provide a 1:1 tenant-to-tenant migration mechanism.

Depending on the organization, the inventory may uncover:

• Microsoft Forms;
• Microsoft Loop;
• OneNote;
• Microsoft Lists;
• Stream on SharePoint;
• Viva Engage;
• Viva Connections;
• Bookings;
• Project;
• Power Pages;
• Copilot Studio;
• Teams Phone;
• SaaS applications integrated through Entra ID.

The fact that a service does not provide a direct move does not necessarily mean it has to be lost. It may be possible to export it, rebuild it, leave it temporarily in the source tenant or design a different solution in the target environment.

The important thing is for that decision to be explicit before cutover.

Why don’t Microsoft’s native tools cover an entire Microsoft 365 migration on their own?

Because Microsoft 365 is not a single application. It is an ecosystem made up of independent services that share identity and interact with one another but use different data models, APIs and management mechanisms.

Microsoft provides several important native capabilities:

• Microsoft 365 Migration Orchestrator to coordinate specific user-scoped workloads;
• Cross-Tenant Mailbox Migration for Exchange Online;
• Cross-Tenant OneDrive Migration;
• Cross-Tenant SharePoint Migration;
• Cross-Tenant Identity Mapping;
• Microsoft Graph for multiple objects and configurations;
• Power Platform tenant-to-tenant environment migration.

However, different approaches are still required for shared Teams, Planner, Power BI, Intune, identity, domains, applications and security.

This is not an unusual deficiency of Microsoft 365. A mailbox, a managed device, a Power BI workspace and an App Registration are fundamentally different types of objects.

The challenge arises when people expect a single “Migrate tenant” button capable of reproducing the entire environment identically.

How does MSAdvance handle a complete Microsoft 365 migration?

MSAdvance acts as the project orchestration layer. The customer does not need to decide which tool to use for each workload or manually coordinate several independent processes.

Our approach starts with the final outcome the organization needs to achieve:

1. Assessment: we analyze the source tenant, target tenant and project constraints.
2. Inventory: we identify data, objects, workloads and dependencies.
3. Architecture: we define how the target tenant should be structured.
4. Identity mapping: we prepare the required mappings.
5. Method selection: native Microsoft capabilities, specialized migration tools, Graph, PowerShell or a combination.
6. Pilot: we test the design using representative users and workloads.
7. Migration: we move the elements that support migration.
8. Recreation: we rebuild objects without a direct migration path.
9. Redesign: we improve components when copying the previous architecture provides no value.
10. Validation: we verify content, permissions and functionality.
11. Cutover: we coordinate identities, domain, email and access.
12. Hypercare: we resolve issues that arise after the transition.

It would not be technically accurate to promise that “absolutely everything can be copied identically.” Some objects do not have a 1:1 migration path.

What matters is something different: we take responsibility for achieving the complete outcome. When an element cannot be moved literally, we define in advance how it should be preserved, rebuilt or redesigned.

The goal is not simply for a migration platform to show every job in green. The goal is for the new tenant to be operational and for users to be able to continue working.

What information do we need to quote a Microsoft 365 tenant-to-tenant migration?

To estimate a migration accurately, we need to understand the environment by workload, not simply the number of users.

The employee count is a useful reference, but it does not by itself reflect the volume of data, dependencies or recreation work involved.

With this information, it becomes possible to determine which workloads will use a native path, which require a specialized platform and which elements need recreation or automation.

In what order should Microsoft 365 workloads be migrated?

There is no universal order, but identity and architecture should be prepared before content, while the corporate domain is generally reserved for the cutover phase.

A typical sequence for an enterprise environment might be:

1. Discovery and inventory.
2. Scope definition.
3. Target tenant design.
4. Licensing and administrative permissions.
5. User and group provisioning.
6. Identity mapping.
7. Application preparation and baseline security.
8. Technical pilot.
9. Pre-staging where the selected technology supports it.
10. SharePoint and collaboration components.
11. Teams and channels.
12. Planner, Power BI and Power Platform.
13. Intune and device preparation.
14. Identity, Exchange, domain and DNS cutover.
15. Endpoint re-enrollment where applicable.
16. Functional validation.
17. Hypercare.
18. Controlled retirement of the source tenant.

Microsoft 365 Migration Orchestrator already understands certain dependencies between the workloads it coordinates. The rest of the ecosystem still requires overall project planning.

Is it better to use Microsoft’s native tools or a specialized migration tool?

It depends on the workload, data volume and cutover model. A well-designed migration should not begin by selecting a particular tool vendor and then forcing the entire tenant to fit that tool.

A third-party tool can improve automation, reporting, coexistence, pre-staging or coverage for certain workloads. However, no platform can bypass a fundamental limitation in a Microsoft API or service that does not expose the necessary information.

This is why the best strategy may use one method for Exchange, another for Teams and custom automation for certain configurations.

For a more detailed comparison, see our guide to tools and scripts for Microsoft 365 tenant-to-tenant migration.

What are the most common mistakes in a Microsoft 365 tenant-to-tenant migration?

The most common mistake is treating Microsoft 365 as if it were only email and files. The most expensive problems usually appear in dependencies that were never inventoried.

1. Assuming that all of Microsoft 365 can be moved using a single tool.
2. Counting Teams without analyzing the associated SharePoint sites.
3. Forgetting Teams chats and meetings.
4. Forgetting Planner inside Teams.
5. Counting Power BI only by the number of reports.
6. Leaving Intune until after cutover.
7. Failing to detect Holds and retention policies.
8. Ignoring Enterprise Applications and Single Sign-On.
9. Failing to prepare identity mapping correctly.
10. Attempting to release the domain without removing all references to it.
11. Assuming that all permissions will automatically be preserved.
12. Promising an absolutely identical user experience.
13. Failing to perform a representative pilot.
14. Starting to use target locations that need to remain unprovisioned for the selected native migration strategy.
15. Migrating groups, Teams and sites that have not been used for years.
16. Validating only item counts rather than actual functionality.

A good migration is not about copying more things. It is also about understanding what is worth moving and which historical technical debt is better left behind.

Scope checklist for a Microsoft 365 tenant-to-tenant migration

Before finalizing the scope, the following areas should at least be reviewed:

If one of these components exists in the source tenant but is not included in the scope, an explicit decision should be made on whether it will be migrated, recreated, archived, left temporarily in the source tenant or retired.

Official sources for verifying Microsoft 365 migration capabilities

Microsoft 365 evolves continuously. Before carrying out a migration, the applicable official documentation should always be reviewed against the current state of the platform at the time of the project.

• Microsoft 365 Migration documentation — Microsoft’s general documentation for migrations.
• Microsoft 365 Migration Orchestrator — coordination of user-scoped workloads.
• Cross-Tenant Mailbox Migration.
• Cross-Tenant Identity Mapping.
• Cross-Tenant OneDrive Migration.
• Cross-Tenant SharePoint Migration.
• Microsoft Graph — Teams migration APIs.
• Microsoft Graph — Planner.
• Power BI tenant migration patterns and strategies.
• Microsoft Intune migration guide.
• Power Platform tenant-to-tenant environment migration.

Related MSAdvance guides

• Complete Microsoft 365 tenant-to-tenant migration guide.
• Microsoft 365 cross-tenant OneDrive migration.
• SharePoint tenant-to-tenant migration.
• Microsoft Teams tenant-to-tenant migration.
• Power BI migration.
• Tools and scripts for Microsoft 365 tenant-to-tenant migration.

Conclusion: what can be migrated between Microsoft 365 tenants?

A very large part of Microsoft 365 can be migrated, but there is no single path that moves an entire tenant from end to end. Exchange Online, OneDrive and SharePoint have dedicated cross-tenant mechanisms. Microsoft 365 Migration Orchestrator coordinates specific Exchange, OneDrive and Teams user data. Shared Teams workloads, Planner, Power BI, Intune, Power Platform, Entra ID, applications, domains and security require additional handling.

The complexity is rarely in moving a single mailbox. It lies in making sure that all dependencies still make sense after the change: permissions, groups, Teams, documents, applications, devices, gateways, automations and the corporate domain.

MSAdvance coordinates the complete migration so that the customer does not have to manage a different tool for every service. When Microsoft provides an appropriate native migration path, we use it. When the scope requires more, we incorporate specialized tools, Microsoft Graph, PowerShell or controlled recreation processes.

And when an element does not have a 1:1 migration path, we define before execution how it should be preserved, rebuilt or redesigned.