If you have in excess of 500 users to migrate or a large amount of SharePoint data to migrate, it’s a smart thought to work with an Office 365 partner.
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
If using a third party migration tool to migrate your users, purchase the needed licenses for your migration.
Client considerations
For Outlook 2010 or above, you just need to remove the Outlook user profile and create it again.
For Outlook 2007 and Outlook 2010, when you are restarting the client, auto-discover will configure the client and modify the .OST file.
For the skype for business client, once migration is complete, since the process creates a new profile, you will need to add contacts.
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.
Increase licenses in Target Office 365 tenant to accommodate all mailboxes that will be migrated from the source tenant.
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.
Room, resource, distribution gathering, and user object creation in the target tenant
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 protected] 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.
End-user communications
To communicate the migration to the end users in your organization:
Create a communication plan and begin to notify users of the upcoming migration and service changes.
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.
Make users aware of how to connect to Outlook Web App with their new sign on information in case they have an issue after migration.
Preparation and pre-migration activities: Three days before you migrate
Domain preparation
To prepare the domain for migration, complete the following steps.
Begin domain verification process on target (Contoso) tenant for the Fabrikam.com email domain.
In the contoso.com Microsoft 365 admin center, add the Fabrikam.com domain and create TXT records in Domain Name Systems (DNS) for verification.
The verification will fail because the domain is still in use in the other tenant.
Performing this step presently will allow the DNS record time to propagate as it can take as long as 72 hours. Final validation will occur later in the process.
Migration scheduling
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
Next, you’ll schedule the 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
These are the steps you’ll need the day you perform the migration.
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.
Tip
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.
Verify your MX and DNS changes if necessary. Nslookup or a service like MxToolbox can be utilized to verify MX and DNS changes.
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.
Remove all Lync licenses from the users in the source tenant using Lync admin portal. This will remove the Lync Sip address connected to Fabrikam.com.
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.
Remove all secondary email (proxy addresses) from user objects that are still using @fabrikam.com.
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.
For common domain removal issues, see You get a blunder message when you try to remove a domain from Office 365.
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.
Begin mailbox activation in the contoso.com tenant > Assign licenses to all of the new user accounts.
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.
