This article explains how to migrate mailboxes and service settings from one Office 365 tenant to another Office 365 tenant in a business-merger scenario
The scenario in this article is based on two fictional companies – Contoso.com and Fabrikam.com – using two separate Office 365 tenants. Contoso has purchased Fabrikam and is moving the Fabrikam users and data to the contoso.com Office 365 tenant.
Scenario: Migrate using a third party migration tool
This scenario assumes that user, gathering and other objects from the Fabrikam Company will be manually created in Office 365, imported into the portal via script, or converged into the Contoso Active Directory through Active Directory Domain Services (AD DS) consolidation.
Whenever complete, all Fabrikam accounts will exist in the Contoso.com Office 365 tenant, and will all utilization @fabrikam.com for the UPN. The final addressing scheme was chosen for simplicity and brevity but can of course be modified to meet your requirements.
Planning: Two weeks before you migrate
For Outlook 2007 and Outlook 2010, when you are restarting the client, auto-discover will configure the client and modify the .OST file.
Tenant preparation and licensing
The source tenant is the Fabrikam Office 365 tenant from which you are migrating users and data. The target tenant is the Contoso Office 365 tenant to which you are migrating.
Create Administrator accounts in source and target tenants for use in migrating from Office 365 to another Office 365. Some migration tools may require more than one admin account in the source tenant to optimize the data throughput.
To create the resources in the target (Contoso) tenant:
If the Azure AD Connect tool will be utilized to sync all objects from the Contoso Active Directory Domain Services (AD DS), the objects from the source (Fabrikam) tenant AD DS must be created in the target tenant (Contoso) AD DS through consolidation.
AD DS consolidation can be done using various AD DS tools. Consolidation can take extra time and planning depending on what number of objects are being moved, so it can be completed ahead of the migration project.
Verify that all new users and groups are synced to the Contoso.com target tenant via directory synchronization. The objects should appear as email@example.com in the new tenant since the Fabrikam domain has not been moved over at this time. The primary email address for the users and groups can be updated to @fabrikam.com after the domain move is complete.
If directory synchronization will not be utilized, or if any Rooms, Resources, Groups or Users are managed in the Microsoft 365 admin center of the source tenant; these objects must be created in the target tenant. Objects can be created manually in the Microsoft 365 admin center or for larger numbers import a CSV file by using the mass add feature in the Microsoft 365 admin center, or by using Windows PowerShell.
To communicate the migration to the end users in your organization:
After migration, the Auto-Complete List (also known as the nickname cache) will have to be cleared on all Outlook clients. To remove all recipients from your Auto-Complete list in Outlook 2010 later, see Manage suggested recipients in the To, Cc, and Bcc boxes with Auto-Complete.
Preparation and pre-migration activities: Three days before you migrate
Begin domain verification process on target (Contoso) tenant for the Fabrikam.com email domain.
The verification will fail because the domain is still in use in the other tenant.
To schedule the migration:
Create master list of user mailboxes you want to migrate.
Create mailbox mapping .CSV file for the third-party migration tool you are using. This mapping file will be utilized by the migration tool to match the source mailbox with the target tenant mailbox when migration occurs. We recommend that you utilize the *.onmicrosoft.com ‘initial’ domain for mapping the source accounts since the custom email domain will be constantly changing.
Mail exchanger record (MX record) time to live (TTL) test
In DNS, change the TTL value on the MX record for the primary email domain you wish to transfer to a small number (for example 5 minutes). If the TTL cannot be brought down to 5 minutes, make note of the lowest value. Example, if the lowest value is 4 hours, the MX record will have to be changed 4 hours before your migration begins.
Mx Lookup can be utilized to verify MX and DNS changes.
Disable directory sync in source tenant
In the source tenant Microsoft 365 admin center, disable directory sync. This process can take 24 hours or all the more so it must be done ahead of the migration. Once disabled in the portal, any changes to the source tenant AD DS will never again sync to the Office 365 tenant. Adjust your existing user and gathering provisioning process accordingly.
Migration: The day you migrate
MX record change – Stop inbound mail stream
Change your primary MX record from Office 365 to domain that is not reachable, for example “unreachable.example.com”. Internet mail servers attempting to convey new mail will line the mail and attempt redelivery for 24 hours. Using this method, some email may return a non-conveyance report (NDR) depending on the server attempting to convey the email. If this is an issue utilize a MX record backup service. There are many third party services that will line your email for days or weeks. Once your migration is complete, these services will convey the lined mail to your new Office 365 tenant.
If your TTL is short, for example, five minutes, this step can be done at the end of the work day to cause less disruption. If you have a larger TTL, you must change the MX record ahead of time to allow the TTL to lapse. Example, a four hour TTL must be changed before 2 PM if you plan to begin migrations at 6 PM.
Source tenant preparation
The primary email domain, fabrikam.com, must be removed from all objects in the source tenant before the domain can be moved to the target tenant.
If you had also set up your domain with a SharePoint Online public website, then before you can remove the domain, you first have to set the website’s URL back to the initial domain.
Reset default email addresses on Office 365 source mailboxes to the initial domain (fabrikam.onmicrosoft.com).
Reset default email addresses on all Distribution Lists, Rooms and Resources to the initial domain (fabrikam.onmicrosoft.com) in source tenant.
Set default domain in source tenant to fabrikam.onmicrosoft.com routing domain (in the admin portal, click your company name in the upper right corner).
Use Windows PowerShell command Get-MsolUser – DomainName Fabrikam.com to retrieve a list of all objects that are still using the domain and blocking removal.
Target tenant preparation
Complete the verification of the Fabrikam.com domain in the contoso.com tenant. You may have to wait one hour after removing the domain from the old tenant.
Configure auto-discover CNAME (internal/External) optional.
If you are using AD FS, configure the new domain in target tenant for AD FS.
Set the Fabrikam.com email domain as the primary address on the new users. This can be done by selecting/editing multiple unlicensed users in the portal or by using Windows PowerShell.
If you are not using the password hash sync feature, pass-through authentication or AD FS, set password on all mailboxes in the target (Contoso) tenant. If you are not using a common password, notify users of the new password.
Once mailboxes are licensed and active, transition the mail routing. Point the Fabrikam MX record to Office 365 target (Contoso) tenant. At the point when the MX TTL expires, mail will begin to stream into the new empty mailboxes. If you are using a MX backup service, you can release the email to the new mailboxes.