How to Migrate from One Office 365 Tenant to Another Easily?
Are you among those who can’t figure out how to migrate from one Office 365 tenant to another after a recent business change?
Don’t worry this guide will act as the first step in training you to handle the digital infrastructure movement during mergers or company splits
We will start off with the prerequisites you need to complete before any of the actual process can begin.
Pre Requisites for How to Migrate from One Office 365 Tenant to Another
Add the following permission settings
- Move the Mailbox application to Azure.
- EXO Migration Endpoint.
- EXO Organization Relationship.
Keep a mail-enabled security group in the source tenant so that admins can decide which users move and which users stay. In other words, it helps to set the scope of migration.
In case the number of source accounts exceeds 10K then Microsoft recommends that you add more such groups and distribute users in them.
Even though nested groups can be used avoid them if you can.
Obtain the Tenant ID for both source and destination
Login to Microsoft 365 admin center
Visit https://entra.microsoft.com/#view/Microsoft_AAD_IAM/TenantOverview.ReactView.
Then, copy the Tenant ID.
While you are in the Admin center also check that users have their Exchange Online subscriptions active. Moreover, check that users on the source side possess Cross Tenant User Data Migration licenses.
This completes the prerequisites now move on to the Target tenant preparation.
Steps to Prepare Target Tenant to Receive Data During O365 Migration
Log in to the Azure portal (https://portal.azure.com), where you will find the App registrations option inside the View tab of Manage Microsoft Entra ID.
Click on + to register a new one. Ensure that you choose “Accounts in any organizational directory” and set the Redirect URI to https://office.com.
Revert to the main page, click on App Registrations again go to Owned Apps, and select the one you just made.
Here you will fetch the Application (client) ID. You’ll find the ID under “Essentials,”. Doing all this step by step is how to migrate from one Office 365 tenant to another in the most error free manner.
Now, tell the app what it’s allowed to do. It needs permission to move mailboxes(You may see that User.Read is preassigned, we dont need it for migration so revoke it if you wish), so go into API permissions and add the Mailbox.Migration permission.
Get the secret password. This password is only shown once, so copy it and keep it somewhere safe! A secret password is available under “Certificates & secrets.”
Now you need to give your app permission to do its job. This is called granting admin consent. So let’s see how to do this.
Give Application Consent
It’s a two-part process.
First, you need to permit your tenant.
Find the app you just made under Enterprise applications in the Microsoft Entra admin center.
Select it, then choose API Permissions, and then click “Grant admin consent.”
A new window will pop up; just click “Accept.”
Go to the main portal again and hit Refresh just to make sure that acceptance is valid.
Next, you need to share this app with the destination tenant so that two-way permission can occur.
This is done via a special link, that looks something like this:
https://login.microsoftonline.com/partner-domain.onmicrosoft.com/adminconsent?client_id=[application_id]&redirect_uri=https://office.com
Instead of a placeholder URL put in the target domain name. Likewise, replace [application_id] with the alpha-numeric Application (client) ID you got during the creation process earlier.
Send the link via a secure channel and ask them to accept the permissions. With this, both tenants are set up to talk to each other.
Perform Link Acceptance at the Source Tenant
Paste the link sent by the admin on the other endpoint on any browser of your choice.
Replace the domain and app ID part of the URL with your own corresponding details
https://login.microsoftonline.com/your_domain.onmicrosoft.com/adminconsent?client_id=[app_id_you_got]&redirect_uri=https://office.com
Once you open the link with the correct data you will see a pop use it to accept the app. Otherwise, you can log into the Microsoft Entra admin center and look for the app yourself you will find it under the Enterprise applications section.
After this connect to a new Exchange Online PowerShell instance on this tenant and make a new organization relationship object.
If you want you can also alter a current organization relationship object to your target (destination) tenant.
Use the following PowerShell command as a Template.
$destinationTenantId = "[Tenant ID of the Destination]" $applicationId = "[ mailbox migration app ID]" $scope = "[mail enabled security group name with the user list]" $orgRelName = "[New/Edited Organization relationship Name]" # Only Enable customization if you are using a dehydrated tenant $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 }
Here the tenant ID for both source and target is GUID don’t confuse it with the tenant domain name.
Ready Up the User’s Accounts on the Target Tenant
Make sure that the accounts are preset as MailUser in the target tenant for all members whose data you are about to bring in.
Along with that define all specific attributes to enable this Cross-tenant movement.
ExchangeGUID (with ArchiveGUID for archive-enabled accounts) that marks the flow from source to target must match.
LegacyExchangeDN is mandatory on target MailUser with x500: proxyAddress. Copy all such addresses. While you are at it enable reply ability for emails in the mailbox. Otherwise, you may face problems during post-migration user location and new email messages may fail with a 5.1.1 NDR.
UserPrincipalName and SMTP address are both used for aligning the user with the NEW identity or target.
TargetAddress/ExternalEmailAddress uses the MailUser field to link the user’s current mailbox hosted in the source tenant.
Assign Exchange Online and Cross Tenant User Data Migration licenses to target users.
Apply the licenses after setting ExchangeGUID and proxy addresses.
Use Test-MigrationServerAvailability to check the migration endpoint.
Consider using the Cross-tenant mailbox migration validation script.
The batch-level process prescribed here is similar to the one used to Migrate the on-premise Exchange Server 2019 to the Office 365 environment
Post Migration Tasks in Tenant to Tenant Office 365 Migration
Update on-premises MailUsers with the new targetAddress
Revoke migration Endpoints by typing
Remove-MigrationEndpoint inside the PowerShell instance you are using to conduct the migration.
Admins at both endpoints have to perform this. Keep in mind that you should only put this command in when you are confident that the migration is complete.
Also, delete the Organization Relationship link. You can do this with the help of Remove-OrganizationRelationship cmdlet in either the source or destination servers once the migration is done.
Problems with the Manual Way to Migrate O365 Tenant to Another
Despite being a manual method to use organizations have to pay for an extra license. This is on top of the existing M365 subscription required to keep the accounts active and functioning.
None is as concerning as the permanent forced deletion of data that happens during the process. Admins have no way to control it. This is because Microsoft deletes every bit of data that is on the source side once the migration is done. So if by any chance the Migration is not as per plan admins have no way to redo it unless they have a backup at the ready.
You don’t need to rely on such a complex multipart process that is also full of limitations.
Put an end to the mixed migration tactic that involves interaction with both the GUI of the admin center and multiple PowerShell scripts. We have something that is much simpler.
Check out how an automated Migration assistant beats manual self-migration.
Automate Tenant to Tenant Migration Office 365 Step by Step
SysTools Office 365 to Office 365 Migration tool is the perfect solution for all admins looking to transfer mailboxes across tenants.
This tool completely bypasses any PowerShell requirement and condenses the migration process into a simple cursor-only task.
Apart from simplification the tool also provides many filtering options to select the Workload that includes Emails, Contacts, Calendars, and even the documents of the M365 subscription holder.
Admins can define the exact start and stop date to set a specific time period from where the data movement happens.
Here are the steps to use this utility.
Launch the tool and select the Microsoft 365 option in both the Source and Target.
Scroll to the Workload area and select Emails, Contacts, Calendars, and other workloads you are looking to move across the two tenants. Here you can add a date filter next to the workloads that support it. Then press Next
Inside the Source screen, you have to add the Admin ID and an App ID then validate, A green signal indicates successful validation Press Next to continue.
Similarly, on the Destination Screen, you have to Add and Validate the respective Admin emails and App ID.
The Mapping Screen is where you bring in the users. For this, there are 3 options you can Fetch them Directly, Import a premade CSV, or Download a blank template fill it, and upload it with the user list.
Once that is done you come to the Preview area where all the users are arranged in the form of a list. You can use the check box next to each of the names to select, and with the star option set priority to specific accounts. Validate your selections and hit the Start Migration button.
Conclusion
Here readers saw how to migrate from one Office 365 tenant to another in a step-by-step manner. We broke down the series of steps present in the Microsoft guide and also told you the various limitations of that manual procedure. Moreover, as an alternative, we introduced a separate Office to Office migration utility which allows for a much easier transfer.
