Whether due to a merger and acquisition, rebranding, or a divestiture, companies that use Office 365 may find the need to migrate their mailboxes from a tenant that will soon be out of use to another tenant. This newly moved-to tenant will serve as the backbone of both their custom email domain and their Office 365 initial domain. The following dives into the specifics of how to achieve tenant to tenant migration.
The Scenario
The source tenant and target tenant both exist separately in the Microsoft Cloud, both using Microsoft Office 365. The target tenant acquires or rebrands as the source tenant. All of the source tenant’s users, groups, and objects in Office 365 need to be either manually created in the target tenant’s Office 365 tenant, merged into their active directory via Active Directory Domain Services (AD DS) consolidation, or imported with a script into the portal.
The Planning Phase
This phase should take place two weeks before a migration. And it needs to take into consideration whether or not a third-party migration tool should be used. If it is, the IT team needs to buy all necessary migration licenses.
Additionally, during the planning phase of the migration process, IT teams should map out four other areas:
1. The Client
Depending on the client that is being used, The target tenant may need to adjust their migration approach. Therefore, the first step is identifying which client the source tenant is using:
- Outlook 2007: During the restart, the client will be configured and the OST file will be rebuilt by auto-discover.
- Outlook 2010: Falls under the same restart situation as Outlook 2007. However, all the IT team must do is delete the Outlook user profiles of the source tenant.
- Outlook 2013: As with Outlook 2010, all that is necessary is the deletion of all the source tenant’s Outlook user profiles.
- Lync: When the migration is complete, the IT team must add contacts.
2. The Tenants
Before the migration process, it is important to differentiate between the source tenant and the target tenant. For this scenario, the source tenant is where users and data is migrating from. The target tenant is the tenant where users and data is migrating to. To accommodate this process, two steps need to be taken in regards to these tenants:
Step 1: The IT team needs to make room in the target tenant’s Office 365 for all of the source tenant’s mailboxes that are being migrated. This means obtaining additional licenses.
Step 2: In order to facilitate the migration process, the IT team must open administrator accounts for both the source tenant and the target tenant. For the best data throughput, the team may need to create additional admin accounts in certain migration tools.
3. Resource Creation
Next, the IT team must plan their strategy for creating the necessary resources in the target tenant. This includes accounting for everything from room to distribution group to user object creation.
Step 1: If the objects in the target tenant’s AD DS are being synced with the Azure AD Connect tool, the source tenant’s AD DS objects need to be created with consolidation in the target tenant’s AD DS.
Step 2: This consolidation should be done before the actual migration starts. The fact is that the process of consolidation usually takes additional planning and time—the more objects there are to move, the more time it will require. To accomplish this AD DS consolidation, the IT team can use a number of different tools.
Step 3: After consolidation, the team should confirm that the directory synchronization has effectively synced every new user and group to the target tenant. The source tenant’s domain should not have been moved over before the new users and groups were synced. This will be evident through the fact that all objects will appear as user@targettenant.onmicrosoft.com. Once this is verified, the IT team can move the source tenant domain, allowing user and group primary emails to be updated to @sourcetenant.com.
Step 4: IT will need to create objects in the target tenant when the source tenant’s Office 365 admin center manages groups, resources, rooms, or users or if IT is not using directory synchronization. This can either be done manually, by using a CSV file in Office 365 admin center’s bulk add a feature or with Windows PowerShell.
4. Organizational Communication
Both the source tenant and the target tenant must clearly communicate with their workforces about the migration and how it will affect them. The IT team should create a communication plan that includes:
- Early notification about the migration and service changes.
- A guide for end users to clear their nickname and auto-complete caches in Outlook.
- A guide for end users to connect to Outlook Web App with their new sign-in credentials.
The Preparation Phase
Close up of male IT professional working on a project.
This phase should take place three days before the migration. It includes:
1. Domain Prep: The DNS record needs up to three days to propagate. Therefore, IT must start verifying the source tenant’s email domain within the target tenant. IT needs to add the source tenant’s domain in the target tenant’s Office 365 admin center. Then they can allow for verification in the DNS by creating TXT records. IT should expect verification to fail initially—the source tenant is still using the domain.
2. Migration Prep: IT must schedule the migration, create a complete list of user migratable mailboxes, and develop a .CSV file for mailbox mapping by the third-party migration tool. Because the email domain will change multiple times, it is best to use .onmicrosoft.com as the domain for mapping source accounts.
3. TTL Test Prep: The IT team must schedule the TTL test. This includes changing the TTL value on the DNS’ primary email domain’s MX record to the lowest possible time (i.e. 10 minutes, 2 hours, etc). The MX record will need to be changed to match the time inputted as the TTL value. To verify this, IT can use MX Lookup.
4. Source Tenant Prep: It can take as long as 24 hours for the directory sync to be disabled. Since this must be done to the source tenant’s admin center before migration, IT needs to plan ahead. It also means that any syncing that needs to be done between the source tenant AD DS and the Office 365 tenant must be completed prior to this step.
The Migration Phase
These steps take place the day of the tenant to tenant migration. They include:
1. Change the MX Record
IT needs to stop inbound mail from coming through by changing the Office 365 MX record to an unreachable domain—some incoming mail will be returned as undeliverable. Alternatively, they can employ an MX record backup service, which will queue incoming emails for several days. When the migration is finished, the queued mail can be delivered to the target tenant emails.
2. Prepare the Source Tenant
In order to move the domain to the target tenant, IT needs to disconnect the primary source tenant email domain from all of the source tenant’s objects. To do this, IT must:
A. Reset the website’s URL to the starting domain—this is only if a SharePoint Online public website was used to set up the domain.
B. Delete the source tenant domain’s Lync Sip address (In the Lynch admin portal, the source tenant’s users need to be disconnected from their Lync licenses).
C. Make the initial source tenant domain the default email address for all of the source tenant’s Office 365 mailboxes, as well as the source tenant’s Distribution Lists, Resources, and Rooms.
D. Delete any user objects’ secondary emails that are still listed as @sourcetenant.com.
E. Make sourcetenant.onmicrosoft.com the routing domain for all source tenants’ default domains.
F. Collect a list of any objects that are still on the domain and blocking removal with Windows PowerShell command Get-MsolUser -DomainName sourcetenant.com.
G. For additional help with domain removal, see this page.
3. Prepare the Target Tenant
It may take up to an hour after disconnecting the old tenant and its domain, but IT needs to verify the sourcetenant.com domain in the targettenant.com tenant. To accomplish this, the IT team must:
A. Setup auto-discover CNAME optional.
B. Setup AD FS, if necessary, with new domain configuration in the target tenant.
C. Provide licenses for each new user account in the target tenant.
D. Use Windows PowerShell or select and edit unlicensed new users to have sourcetenant.com email domain as their primary address.
E. Set the password for mailboxes in target tenant (Only applies to IT teams that are not using AD FS, the password hash sync function, or pass-through authentication).
F. Either point the source tenant MX record to the target tenant’s Office 365 or release the MX backup service to make inbound mail operational (only possible when all mailboxes are licensed and active).
G. Verify mail flow in target tenant.
H. Reset connectors, transport rules, etc in the target tenant (Only applicable to teams using Exchange Online Protection).
4. Initiate Migration
There are two different methods for migration. For migrations with less than 500 users, IT should use a cut-off date to limit the amount of data that is migrated (i.e. migrating only contact and mail calendar data from the last six months). For migrations with more than 500 users, IT can use a multi-pass approach. The initial migration can migrate calendar, contact, and email data from the last week. Then, over the next few weeks, they can migrate older data.
IT can use vendor-provided tools to monitor the migration progress. Progress updates should be sent to management and others involved in the migration efforts. While Outlook 2007 and 2010 will sync every users’ entire mailbox, Outlook 2013 can be configured with a cut-off date to limit bandwidth use.
5. After the Migration
When the migration is complete, it is important to ensure that users have cleared their nickname and auto-completion caches. This is not only for their convenience, but also to prevent them from continuously receiving NDRs when replying to emails that were migrated.
Learn More About Tenant to Tenant Migration
Agile IT has migrated over 1,500,000 accounts to the cloud. If you want a painless, fixed price tenant to tenant migration, request a quote today:
Published on: .
Sales@AgileIT.com