Microsoft Office 365 Tenant to Tenant Migration – Step By Step Guide (Updated 2026-27)

Microsoft Office 365 tenant to tenant migration means moving mailboxes, OneDrive files, SharePoint sites, and user accounts from one Microsoft 365 tenant to another, usually after a merger, acquisition, divestiture, or rebrand. You can do it with Microsoft’s cross-tenant migration tools, which require PowerShell and an add-on license, or with SysTools software that runs through a step-by-step wizard.

In modern times, when business dynamics are changing every moment, organizations often pursue mergers, acquisitions, and rebranding to stay competitive. There are several High-profile names included in these events, such as Twitter rebranded as X, Facebook as Meta, Weight Watchers as WW.  This post solves the problem of migrating data from one Microsoft 365 tenant to another.

With the rapid evolution of the business environment, IT professionals are compelled to perform the complex task of moving or merging the entire digital ecosystem to the destination environment. 

Due to the popularity of Microsoft 365 in the market, most businesses globally have been using it for a long time. In the event of mergers and acquisitions or rebranding, they often find themselves in need of performing Microsoft Office 365 tenant-to-tenant migration and making data available and accessible. 

However, planning for a tenant-to-tenant migration within the Microsoft 365 environment itself is a major decision that can impact the entire digital ecosystem. According to a recent study, around 50-70% of migration projects face delays or fail to meet their initial goals due to inadequate pre-migration planning. 

Therefore, in this write-up, I have outlinеd a detailed overview of the essential aspects of Office 365 tenant-to-tenant migration, including strategic planning and execution.

Whether you’re undergoing a merger, acquisition, or rebranding, I will walk you through the key steps and considerations for the entire process to ensure smooth business workflow with minimum downtime. 

We will start with a thorough analysis of the current tenant environment, as determining the scope of the migration and spotting any obstacles requires a thorough understanding of the current configuration, user accounts, data, and any customizations or integrations. Then we will detail the key procedures involved in tenant to tenant migration of Office 365.

Different Business Scenarios & Architecture Approaches

Let’s discuss the different possible business scenarios, architecture scenarios, and the best possible architecture approach for tenant to tenant migrations in Microsoft 365. Let’s take the example of Contoso being the source tenant and Fabrikam being the target (destination) tenant. 

Based on the above scenario, you can easily identify the scope and approach of migration. Once you have decided on it, move to the next step accordingly. 

Most Important Pre-Migration Stage for Office 365 Tenant to Tenant Migration

Below is the list of the most crucial pre-planning steps. It ensures data integrity and security throughout the Tenant-to-Tenant migration process. Go through it before heading to the pilot migration. 

Get-MgUser -All -Property Id,DisplayName,UserPrincipalName |
Where-Object {
    $_.UserPrincipalName -like "*@abc.com"
} |
Select-Object DisplayName,UserPrincipalName,Id

What Does Microsoft 365 Tenant Include and What to Migrate?

A Microsoft 365 tenant includes a variety of apps, which depends upon the Office 365 subscription plan you choose. For instance, if you have chosen the Microsoft 365 Business Basic Plan, then your Microsoft 365 tenant will include the following apps and services:

• Exchange Online
• SharePoint
• Outlook 365
• OneDrive for Business
• Word
• Excel
• PowerPoint
• Microsoft Teams
• Bookings
• Forms
• Lists
• Planner

Now the point here is, what to migrate since you are migrating the complete data from one tenant to another tenant migration, you should migrate Outlook 365 mailbox, OneDrive for Business, Teams, SharePoint, etc.

With this workload, you have two options whether you perform Office 365 tenant to tenant migration through manual technique, or you choose software. If you choose the manual method, then you have to migrate each software’s data separately. It’s like moving each box in your house one by one. It can take a while, and you’ve got to be careful not to drop anything.

On the other hand, if you choose the mentioned software solution, then you can migrate the entire workload altogether. It’s like hiring movers who can take all your stuff together. This way, it’s faster, and there’s less chance of things getting lost or broken. This reduces human effort and the chances of data loss scenarios. 

Method 1: Perform Cross Tenant Migration Using Microsoft-Native Tools

Utilizing Microsoft-native Exchange Online, OneDrive, and SharePoint cross-tenant migration tools is the standard method to perform Office 365 tenant to tenant migration.

You are required to configure each workload individually using PowerShell. Also, you need to establish tenant relationships. And meet Microsoft’s licensing and technical prerequisites.

The following prerequisites for native Exchange cross-tenant migration (formatted in a table) will help bypass licensing failures. Including identity-mapping and mailbox migration challenges:

Native Migration Limitations and Unsupported Workloads 

Here are the workload-specific limitations and additional administrative requirements you must account for before migrating data from one M365 tenant to another:

• Independent migration workflows: The native cross-tenant migration demands separate configuration and execution of Exchange Online, OneDrive, and SharePoint migrations. So, you have to perform the migration for each workload individually.
• Destination Limitations: When migrating data across M365 tenants, existing destination mailboxes and OneDrive/SharePoint sites can prevent support for native transfers (depending on the workload).
• Unsupported Content: You have to migrate Teams channels and certain shared workloads. Including Power Platform components and other application data.
• Security and Compliance Restrictions: Note that tenant-wide security policies, application configurations, and particular compliance settings are not automatically transferred.
• Migration Challenges: Your mailboxes are subject to holds and can be restricted from migrating. Also, SharePoint and OneDrive migrations have documented limits that concern storage, item counts, and destination compatibility.

Method 2: Migrate Microsoft 365 Workloads Using Migration Orchestrator

Migration Orchestrator is Microsoft’s built-in cross-tenant migration tool. It coordinates supported user workloads via Microsoft Graph-based migration batches. 

You can move forward to transfer Exchange Online, OneDrive, and supported Teams data, all while managing workload dependencies and migration cutover.

Here are the workloads supported by Migration Orchestrator:

• Exchange Online: It can migrate user mailboxes. Including emails, contacts, calendars, and other supported mailbox content.
• OneDrive for Business: It transfers personal OneDrive sites and files between M365 tenants.
• Microsoft Teams: Capable of migrating eligible personal chats and meetings, subject to workload-specific dependencies and restrictions.
• Migration Workflows: Allows single-event, phased, or tenant split migrations based on the organization’s needs.

Limitations and Unsupported Shared Workloads 

Microsoft Orchestrator coordinates multiple M365 workloads. But it does not support complete tenant duplication. The following are its technical limitations and unsupported shared workloads that need to be migrated separately:

• Shared workloads: Microsoft Orchestrator is not capable of migrating Microsoft Teams teams/channels and shared SharePoint sites. You need an enterprise-grade solution to move all workloads simultaneously 
• Identity and configuration: You have to configure or recreate Microsoft Entra ID identities, security policies, and tenant-wide configurations individually.
• OneDrive restrictions: It is noteworthy that existing destination OneDrive sites can block migration. Also, incremental or delta OneDrive migrations are not supported.
• Teams limitations: When transferring chats, keep in mind that migrated chats may produce duplicate threads. And moving Teams meetings requires the connected mailbox and Teams chat workloads.
• Cutover restrictions: Once the configured cutover threshold passes, migration cannot be cancelled.

How to Transfer a Domain Between Microsoft 365 Tenants and Complete DNS Cutover

To transfer a custom domain between M365 tenants:

• Make sure to remove its dependencies from the source tenant.
• Confirm ownership in the destination.
• Update the required DNS records.

So, follow the steps shared below to complete the domain cutover while minimizing email disruption. And preserve user connectivity.

#1: Eliminate Domain Dependencies from the Source Tenant

To bypass domain removal errors and transfer the custom domain successfully, removing all references to it in the source Microsoft 365 tenant is necessary.

• Update user identities: Swap the custom domains in user principal names (UPNs). Also, replace the primary email address and aliases with a supported verified domain.
• Remove domain associations: Make sure to update shared mailboxes. Including resource mailboxes, distribution lists, Microsoft 365 Groups, Teams, and other dependent objects.
• Remove the custom domain: Go to Microsoft Admin Center. Access “Settings”. Click “Domains”. Select the domain. Choose “Remove domain” after resolving all dependencies.

#2: Add and Verify the Domain in the Destination Tenant

The custom domain can be registered and verified in the destination Microsoft 365 environment only after it has been released from the source tenant.

• Add the domain: Access Microsoft 365 Admin Center. Go to “Settings”. Click “Domains”. Select “Add domain”. Enter the existing domain name.
• Confirm ownership: Add the Microsoft-provided TXT verification record via the DNS hosting provider. Then, complete verification after the source tenant releases the domain.
• Configure destination accounts: Allocate the evaluated domain to the appropriate users. Including email addresses and mail-enabled objects. Also, make certain that destination mailboxes are ready before redirecting incoming mail.

#3: Update MX, Autodiscover, SPF, DKIM, and DMARC Records

MX Record: Make sure the mail routing destination for Exchange Online is correct. If required, update MX records at cutover.

• Autodiscover CNAME: Set up autodisocver.outlook.com to support automatic Outlook account configuration.
• SPF record: Check authorized email senders. Also, maintain a single valid SPF TXT record. This must include spf.protection.outlook.com when Microsoft 365 sends email.
• DKIM Records: Use the exact values provided by Microsoft to configure the destination tenant’s two DKIM selector CNAME records. After that, enable DKIM signing.
• DMARC record: Analyse the _dmarc TXT record. Confirm that its authentication policy and reporting settings stay correct.

#4: Confirm Email Delivery, Routing, and Outlook Connectivity

Once the DNS cutover is finalized, test email delivery. Check authentication and user accessibility. These steps will help in figuring out configuration issues before retiring the source environment.

• Check DNS propagation: Confirm that public MX, Autodiscover, SPF, DKIM, and DMARC records resolve as intended. To do so, use nslookup or MXToolbox.
• Test email flow: Attempt to send and receive internal and external emails. Verify shared mailbox delivery. Lastly, assess message traces in the Exchange Admin Center.
• Verify Outlook connectivity: Make certain that users can access not only Outlook Desktop. But also Outlook on the web and the mobile applications via their destination tenant credentials.
• Track post-cutover issues: Review nondelivery reports. Make sure of mail-routing errors, authentication failures, and delayed messages before decommissioning the source tenant service.

How to Verify a Successful Microsoft 365 Tenant to Tenant Migration

A successful Microsoft 365 tenant migration involves cross-checking:

• Data Integrity
• User Accessibility
• Custom Permissions
• Security Configurations 

So, apply the following essential post-migration verification checks to identify discrepancies and ensure no disruption to business operations:

#1: Compare Source and Destination Mailbox and File Counts

Evaluate in detail whether the intended mailboxes, emails, and files have been successfully moved to the destination tenant, with no unexpected data loss.

• Measure mailbox content: Compare the destination mailbox item counts, sizes, and folder statistics against the pre-migration source inventory.
• Inspect migrated files: Match OneDrive and SharePoint file counts. Including storage usage and document inventories.
• Flag inconsistencies in migrated data: Review the migration reports for missing, skipped, or failed items. This will be accounted for in documented migration exclusions.

#2: Validate Folder Hierarchy, Metadata, and Permissions

Confirming the migrated content structure is critical for IT administrators. It ensures that the files, folders, and supported attributes stay consistent with the original environment.

• Inspect folder hierarchy: Make certain that Outlook folders, SharePoint libraries, and OneDrive directories preserve their expected structure.
• Check metadata: Review file names, timestamps, authorship, version history, and other supported properties.
• Review access permissions: Make sure of mailbox delegation, SharePoint permissions, and ownership. This also involves checking internal or external sharing access.

#3: Test Email Flow, Teams. SharePoint, OneDrive, and User Access

Carry out functional testing across migrated Microsoft 365 workloads. This effective practice will confirm that users can access critical resources and collaborate the same as in the original tenant.

• Examine Exchange Online: Send and receive internal/external emails. Then, review calendars, contacts, mailbox access, and mail routing.
• Assess collaboration tools: Validate Teams chats, channels, meetings, and SharePoint/OneDrive files as per the migration method’s supported scope.
• Confirm user accessibility: Check Microsoft 365 sign-ins. Review Outlook connectivity, application licenses, and file-sharing permissions using representative user accounts.

#4: Check Security, Retention, and Compliance Policies

To confirm that the migrated environment fulfills organizational and regulatory requirements, always review the destination tenant’s security and governance configurations.

• Check security controls: Make sure of MFA, Conditional Access, administrator roles, and access restrictions.
• Reconsider compliance configurations: Verify Microsoft Purview retention policies. Sensitivity labels, DLP rules, and applicable eDiscovery requirements also need to be reviewed.
• Verify policy enforcement: Check whether security and compliance controls are operating appropriately on migrated content and user accounts

#5: Document Migration Exceptions and Acceptance Criteria 

Conclude the Microsoft 365 cross-tenant migration by recording unresolved issues. Assessing completion requirements and obtaining stakeholder approval is also a non-negotiable part of the process.

• Inspect migration logs: Document failed items, unsupported workloads, permission mismatches, and corrective steps.
• Define acceptance criteria: Create measurable requirements for data completeness. Also, for available services, security compliance, and user accessibility.
• Obtain final approval: Secure stakeholder sign-off after settling major challenges. This also involves documenting accepted exceptions before decommissioning the source environment.

Can I Roll Back a Microsoft 365 Tenant to Tenant Migration

Yes, you can roll back certain Microsoft 365 migration changes. But a completed migration cannot be undone with a single rollback procedure. Your recovery options depend purely on your:

• Migration method
• Workload
• Cutover status
• Available backups.

What Can Be Reversed Before Cutover?

Until your Microsoft 365 tenant migration finalizes, you can cancel eligible migration activities. Also, correct configuration errors and postpone cutover without reversing completed workload transfers.

• Cancel migration batches: Immediately stop supported Exchange Online migration batches before finalization. Or cancel Migration Orchestrator jobs prior to their configured cutover period.
• Postpone domain cutover: Make sure to keep your existing email routing and source-domain configuration until destination services get active.
• Fix migration configurations: You need to update identity mappings. Including permissions, migration endpoints, and licensing before reinitiating affected jobs.
• Immediately pause pending OneDrive moves: You have to immediately cancel the eligible OneDrive migration jobs. Otherwise, it will escalate to a non-cancellable processing state.

Why Native Mailbox and OneDrive Moves Are Not Simple Rollbacks

As you surely know by now that Micrsoft’s native cross-tenant migration tools execute transfer workloads; instead of copying data only. Therefore, restoring your original environment mandates additional migration of data between tenants. And configuration procedures.

• Exchange Online mailboxes: Once a M365 tenant is successfully moved natively, the source mailbox becomes a MailUser. This means you can restore the original mailbox automatically.
• OneDrive accounts: Since native migration transfers files to the destination environment and leaves a redirect at the source. It does not support incremental or delta migration passes.
• Reverse migration: By configuring a new cross-tenant migration in the opposite direction, you can move eligible mailbox and OneDrive content back.
• Post-migration dependencies: You have to restore supported domain routing individually. This process involves retrieving user access, sharing configurations, and unsupported Teams meeting functionality separately.

Recovery Options, Backup Strategies, and Rollback Planning 

Seasoned M365 administrators and migration specialists always champion establishing a document recovery strategy. Especially before initiating Office 365 cross-tenant migration.

• Maintain recoverable backups: You have to preserve individual backups of important mailboxes. This includes archiving SharePoint sites, OneDrive files, and other supported workloads before migration.
• Prepare a rollback plan: In order to prepare a rollback plan, you need to document alternative mail routing. Including destination-to-source migration requirements, recovery responsibilities, and acceptable downtime.
• Evaluate recovery procedures: During the migration, you are required to test backup restoration, user access, mailbox functionality, and file integrity.
• Establish rollback checkpoints: Defining clear go/no-go criteria before mailbox finalization, domain transfer, and decommissioning of the source tenant is a vital step.
• Delay source decommissioning: To ensure a hassle-free cross-tenant migration, always retain required source services and configurations. This needs to be held until migration outcomes are verified and stakeholders approve completion.

Microsoft Native Cross-Tenant Migration vs. SysTools Office 365 to Office Migration Tool: Which Is Better?

For an optimal and hassle-free Office 365 cross-tenant migration, business owners and IT administrators need to understand the difference between the cross-tenant migration capabilities of both approaches. Microsoft provides native cross-tenant migration functionalities through Exchange Online, OneDrive, and SharePoint Online. Including its modern Migration Orchestrator. 

Users Should Be Aware of These Issues and Challenges While Performing Tenant to Tenant Migration in M365

• The very first concern for business organizations having multiple Office 365 domains is that they require their coexistence at a stretch. Then, it becomes a tough and tedious process to perform a migration between tenants.
• Businesses have tons of data for users, emails, and other mailbox categories. In this scenario, data migration can not be accomplished instantly. Hence, to ensure a smooth data transfer by migration teams, organizational employees need to inform and collaborate with others by scheduling a meeting.
• One of the biggest challenges while performing cross tenant migration in Microsoft Office 365 is to ensure data integrity. They get stuck when they do not ensure the source email data is properly backed up before starting tenant to tenant migration.

The above-listed points are only a few of the issues and challenges that can occur while performing this operation. One can face various issues and complications while performing the above operation without any preparation and planning. 

Best Practices to Follow Before Tenant to Tenant Migration

1. Examine the Actual Need and Scope of the Migration: In situations where an organization needs to undergo mergers and acquisitions, processes and communications become quite limited. Eventually, all the intense pressure goes to the IT department to perform this data transfer as soon as possible. “Hurrying will cause problems.” Remember this famous quote while executing the migration process. It is quite important to take time to plan and execute the whole process more systematically.  Moreover, make sure to make a list of items to migrate, such as emails, contacts, calendars, documents, or everything together depending on the firm’s respective needs.
2. Backup the Current Source and Destination Environments: Backing up your current source and destination environment is vital before proceeding toward Office 365 tenant-to-tenant migration. It always works as an insurance policy, as data migration is a technical and complex process to handle. Therefore, just in case anything goes wrong with the migration operation, it can save your organization’s crucial data. It will ensure a smooth flow of business activity and communication with minimum disruption.
3. Create a Comprehensive Inventory Analysis of Your Source Environment: This is another best practice to create a complete inventory of the source and the destination target environment before migrating from one M365 tenant to another. You should be aware of what to migrate and what to leave behind, including all the user account data sizes they have, including email and OneDrive. Once you complete this step, there is nothing more important left behind.
4. Now It’s Time to Plan Migration: Once you determine the amount of data and user accounts that need to be migrated, then it’s time to plan the migration process. The organization should also be aware of the downtime involved in this process. Mostly, they cannot afford the downtime that it may take. As it can hamper the running of business activities. Therefore, phased migration would be the best option to do hands-on, as you can determine the user’s work productivity throughout the whole migration process. Regardless of whether the user’s data is being migrated or not. They would be able to communicate and continue using their Office 365 email account, keeping the whole migration process invisible (in the background) to users of the organization.
5. Effective Communication Before, During, and After Migration: It is the most important best practice to have effective communication throughout this migration in the Microsoft 365 tenant process to avoid any errors that may occur. Employees must be informed of the different working scenarios that might occur. IT managers need to manage all the licensing requirements that may arise.
6. Make Sure to monitor and Report on the real-time migration process – In the list of best practices for Microsoft 365 tenant-to-tenant migration, this is the 2nd last point to remember and follow. You should ensure an appropriate way to monitor the status of the whole migration process in real time, coordinate with other users and activities, and detect any errors encountered. Moreover, if you want an error-free and efficient migration, you should also check out the complete pre and post-migration checklist for Microsoft Office 365 here.

In Brief

The Microsoft 365 tenant to tenant migration is a complex project that needs to be handled with care; with this guide in place, you’ll get through it with flying colors. If you perform this task using any tool that is not certified, you might end up losing your crucial data.

Hence, to keep the data safe and have an effortless yet successful migration procedure, the above-mentioned tool is the best. It has been recommended by several migration experts and IT professionals for decades now.

Also Read: Understanding Microsoft Office 365 Tenant Switcher: A Complete Guide