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!
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:
Here, we will be looking at what is required before starting the migration.
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.
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.
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.
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.
After fulfilling the prerequisites, you can start the migration process. Here is the stepwise process:
You need to first prepare the target (destination) tenant for the migration. For this,
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.
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}
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}
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:
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:
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.
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.