How to Perform Office 365 Tenant to Tenant Migration?

|Updated at August 08, 2025

Migrating an organization from one Office 365 Tenant to another is challenging but important when organizations merge, acquire new entities, or restructure. 

It is not like moving mailbox accounts between tenants; any data migration can create confusion if not methodically planned, as there are users, data, and services that must be migrated without impacting users. 

The real challenge is deciding on the migration method, using either native tools such as SharePoint for migration, or using third-party methods for bulk transferring users, content, etc., that enables you to manage security and permissions during the transfer.

Based on my use of pre-migration audits, record retention and emails for auditing purposes, I can reduce the number of surprises, especially with shared mailboxes or Teams data. 

In this blog post, we are going to explore more about this segment, giving valuable insights to the readers

Let’s begin!

Why would you migrate from one Office 365 Tenant to Another?

There are several key reasons why you would migrate part or all the resources from one Microsoft 365 tenant to another. Some of the common reasons include:

  • Company Restructuring: To merge multiple organizations and companies into one single Microsoft 365 tenant for easy management and consolidation.
  • Business Acquisitions: To move all the resources from the acquired company to the new parent tenant.

Prerequisites for Tenant to Tenant Migration

Here, we will be looking at what is required before starting the migration. 

1 – Licensing and Inventory

Before migrating the data, the first thing you need to do is get an inventory of all the mailboxes, archives, shared mailboxes, and public folders, along with their respective email addresses and sizes. You need to also check if these would need to be licenced on the target tenant. After this is done, you need to purchase and provision the licenses on the target tenant.

2 – Domain and DNS Prerequisites

The domain, which is associated with the mailboxes and public folders, would need to be removed from the source tenant and configured in the target tenant after the migration. You must make sure to have full access to the DNS zone of the domain/s to change the DNS records.

3 – User Identity and Authentication

On the target tenant, you must ensure the compliance of the company. This involves the setup or additional configuration on the Entra ID Connect where the local AD users are synchronized with Entra. You should also configure multi-factor authentication (MFA) and go over the security policies.

4 – Data Backup and Security

Before migration, you must ensure that all the data on the source tenant has been backed up and also the target tenant is also backed up. This will ensure compliance with security policies and other regulatory requirements.

Stepwise Process to Migrate from One Office 365 Tenant to Another

After fulfilling the prerequisites, you can start the migration process. Here is the stepwise process:

Step 1 – Preparation of the Target Tenant

You need to first prepare the target (destination) tenant for the migration. For this,

  • Sign in to the entra.microsoft.com and under Manage Microsoft Entra ID, click on View. 
  • On the navigation pane, select App Registrations and then New Registration. Enter a name for the application. 
  • Open the Register an application page and under Supported account types, click on Accounts in any organizational directory (Any Microsoft Entra directory – Multi-tenant).
  • Enter https://office.com in the Web, under Redirect URI. Once done, click on Register.
  • Open the page of Microsoft Entra ID and click on App Registrations.
  • Open the Owned applications and click on the newly created application. From Essentials, copy the Application (client) ID as this would be needed later.
  • On the navigation pane, click on API Permissions. By default, the User.Read permission is assigned which you can remove since it is not needed. 
  • Click on Add Permission. Search for and select Office 365 Exchange Online from the list of APIs used by my organization in the new window.
  • Click on Application permissions and expand Mailbox, under Select permissions. 
  • Select Mailbox.Migration and click on Add Permissions. 
  • Click on Certificates & Secrets and then click on New Client Secret, under the Client secrets.
  • Now, enter the description and the expiration settings. It is important to copy the password and any secrets in a secure vault. 

Step 2 – Grant the Consent to the Application 

To grant consent to the application, open Entra ID, click on Enterprise Application, and find the application you have created. To grant admin consent for <your tenant>, select API Permission and click Accept.

Now, go back and ensure that the acceptance is showing. Below is the URL which needs to be configured on the source tenant to accept the application.

https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=<application_id_of_the_app_you_just_created>&redirect_uri=https://office.com

Replace the Application ID with the one you have just created.

Step 3 – Create Relationship and Migration Endpoint

From the target Exchange Online tenant, connect with Exchange Online PowerShell and run the below script:

$AppId = “[GUID copied from the migrations app]”
$name = “[Enter a name for the migration endpoint]”
$remote = “<your domain>.onmicrosoft.com”
$secret = “[This is your secret password you saved in step 1]”
$dehydrated = Get-OrganizationConfig | select isdehydrated
if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}

$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $AppId, (ConvertTo-SecureString -String $secret -AsPlainText -Force)
New-MigrationEndpoint -RemoteServer outlook.office.com -RemoteTenant $remote -Credentials $Credential -ExchangeRemoteMove:$true -Name $name -ApplicationId $AppId

Next, you need to create a new organization relationship object by using the below script.

$sourceTenantId = “[Tenant ID of the source tenant]”
$orgrelname = “[Name of your new organization relationship]”
$orgrels = Get-OrganizationRelationship
$existingOrgRel = $orgrels | ?{$_.DomainNames -like $sourceTenantId}
If ($null -ne $existingOrgRel) {Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound}
If ($null -eq $existingOrgRel) {New-OrganizationRelationship $orgrelname -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound -DomainNames $sourceTenantId}

Step 4 – Prepare the Source Tenant

The next step is to prepare the source tenant. To do so, open and accept the application consent link for the mailbox migration application, created by the target tenant above (Step 2).

https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=<application_id_of_the_app_you_just_created>&redirect_uri=https://office.com

Use the below PowerShell script to create the organization relationship on the source tenant.

$targetTenantId = “[Tenant ID of the target tenant]”
$appId = “[Application ID created on the target tenant]”
$scope = “[The name of the security group that has the migration mailboxes members]”
$orgrelname = “[name of your new organization relationship]”
$dehydrated = Get-OrganizationConfig | select isdehydrated
if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}
if (!(New-DistributionGroup -Type Security -Name $scope)) { Write-Host “Group already exists.”
$orgrels=Get-OrganizationRelationship
$existingOrgRel = $orgrels | ?{$_.DomainNames -like $targetTenantId}
If ($null -ne $existingOrgRel) {Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope}
If ($null -eq $existingOrgRel) {New-OrganizationRelationship $orgrelname -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -DomainNames $targetTenantId -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope}

Step 6 – Migration of Mailboxes

To migrate the data, you need to create migration batches by using the New-MigrationBatch command (see the below example).

New-MigrationBatch -Name <batch name> -SourceEndpoint <endpoint name> -CSVData ([System.IO.File]::ReadAllBytes(‘<csv file of the user list>’)) -Autostart -TargetDeliveryDomain <target domain>.onmicrosoft.com

You can use the commands below to check the status of migration batches:

  • Get-MigrationBatch
  • Get-MigrationUser
  • Get-MoveRequestStatistics

An Easy Way to Migrate Data from One Office 365 Tenant to Another

As you have seen above, there are a number of steps involved when migrating mailboxes from one tenant to another. To simplify the cross-tenant mailbox migration and mitigate the challenges, you can use third-party Exchange migration tool, such as Stellar Migrator for Exchange. This tool offers the following benefits:

  • Reduces the time of migration.
  • Zero-downtime migration.
  • No configuration or scripting required.
  • Incremental (Delta) migration.
  • Automated mailbox matching and other features.

Apart from tenant-to-tenant migration, the tool also supports migration from a local Exchange Server to Office 365, local Exchange to Exchange, and Exchange Online to a local Exchange Server. It is not limited to the migration of mailboxes, as it can also easily migrate public folders. Stellar Migrator for Exchange is the right contender for Exchange migration as it reduces complexity in migration and minimizes points of failure. 

Conclusion

Migrating from an Office 365 (Microsoft 365) tenant to another requires careful planning and the right tools in hand for a seamless migration of data with a peace of mind. Using built-in applications might not always be the best solution as you would need to consider a lot of factors. Also, it would take a long time to migrate the data using the built-in tools. So, you would need to factor in the resources and efforts required. 

To save time and avoid hassles, you can use Stellar Migrator for Exchange – a specialized Exchange migration tool. It seamlessly migrates mailboxes and other data from Office 365 to Office 365, from local Exchange Server to another, and from a local Exchange to Office 365. 365. And vice-versa. 

Ans: Every migration project is unique, and your project’s duration could span weeks or even years.

Ans: For migrations from an existing on-premises Exchange Server environment, you can migrate all email, calendar items, tasks and contacts from user mailboxes to Office 365. The available methods are cutover, staged, and Exchange Hybrid migrations

Ans:  Click the Need Help, or click Support and follow with New service requests. In the search field, search for EWS Throttling. Select Increase EWS Throttling Policy from the list and press Enter. Click on Run Tests.




×