The below article is a teaser from MVP Jeff Guillet’s chapter “Overview of Tenant to Tenant Migrations” in “Everything you need to know about Tenant to Tenant Migrations”, you can download the eBook for free here.
Businesses have always changed. Over time, companies merge and separate. In the recent past, these would be treated as domain or forest migrations. There are many products and tools available to help admins with this process, including built-in Microsoft tools such as the Active Directory Migration Tool (ADMT), forest trusts, GAL sync, and directory synchronization tools.
The wild popularity of Office 365 has created some interesting challenges for these types of moves. The guaranteed logical separation of business tenants hosted on the same physical platform makes it challenging to combine or separate tenants.
There is no notion of a forest or domain trust within Azure Active Directory, and the lack of native migration tools for Tenant to Tenant migrations makes it that much more difficult.
There are several reasons why organizations may wish to perform a Tenant to Tenant migration:
- Mergers and acquisitions
- Divestitures
- Business realignment
Mergers and acquisitions can include migrating objects from one tenant to another (users in the Fabrikam tenant are migrated to the Contoso tenant), or it can involve migrating both tenants to a brand new third tenant (Contoso and Fabrikam users are migrated to a new MegaHoldings tenant).
Divestitures occur when a business unit is spun off as a new company into its own tenant. For example, a company that develops software may want to create a wholly-owned and operated service and consulting company.
Tenant to Tenant migrations also may occur when an organization wants to realign the business due to regulatory or data residency reasons. An example might be a North American manufacturing company that has an arm of the business in Germany, where there are more restrictive data sovereignty regulations.
In this document, I will cover some important items to consider when performing a Tenant to Tenant migration. I’ll discuss planning the migration, directory synchronization, authentication, DNS domains, autodiscover, and mail flow design. Let’s get to it.
Planning the Tenant to Tenant Migration
As with any important project, planning the migration is the most important step, and may take the longest amount of time. The more effort you put into planning, the smoother the migration should go and the less impact and surprises for your end users and the business.
You should know all the business and technical requirements before starting this endeavor. Every migration is different so it’s impossible to make a completely comprehensive list of questions that should be asked, but some important things to know are:
- What are the business requirements?
- Where are the tenant geos currently located?
- Where will the target tenant be located? Is the goal to migrate A to B, or A and B to C?
- Are there any legal requirements, laws and regulations that affect the migration?
- Who are the key stakeholders?
- What is the project timeline?
- Are there any language, culture, or time zone considerations that will affect the migration?
- What is the expected end state? Operate as one organization or independent organizations in the same single tenant?
- How will directory synchronization be configured?
- What are the authentication requirements?
- Where are the end-users located?
- What Office 365 licenses will be used?
- Which SMTP domains will be used post-migration?
- How will mail flow work?
- How will distribution and mail-enabled security groups be handled?
- Consider Office 365 groups
- Consider Teams
- Which email clients and access protocols will be used?
- Who will manage the migration?
- Who will manage the AD domain(s) and tenant(s) post-migration?
- What is the communication plan?
Before starting, there are two key things to know: the business and legal requirements, and the technical requirements.
Sometimes these are at odds with each other. For example, in a global Tenant to Tenant merger, there may be a business desire to host all data in a North American tenant, but the General Data Protection Regulation (GDPR) European privacy law may have a major impact on collecting and reporting data.
It is imperative that you know and understand the laws and regulations that apply to data and users involved in the migration. This information will drive some of the answers to the questions above. You may need to meet with business leaders and key stakeholders to explain how this affects the merger or divestment, and consequently the migration itself. Once you know this, you can choose the proper migration tools and strategy.
Preparation
There are several things you should do before you start any part of the Tenant to Tenant migration.
Read through the migration documentation for the migration tool of choice prior to starting the migration. You should have a clear understanding of all the steps of the migration, and the order in which to run them. If you have any concerns or confusion, get it sorted out with the vendor and/or the business. Make sure you have correct contact information for migration tool support, Office 365 support, and key stakeholders. Have phone numbers for each contact, in case email is not available.
Create Administrator accounts in both the source and target tenants for use in the migration. Some migration tools use dedicated migration accounts or may require more than one account in the source tenant to optimize the data throughput. Check with your vendor of choice.
You should create test accounts in both the source and target tenants. In a directory synchronization environment that means creating the account in AD and having them sync to Azure AD. License these accounts to ensure you can access email and other Office 365 services. Be sure to add some email, calendar, and contact items to each account. You can use these test accounts for test migrations.
Ensure the administrator can run remote PowerShell in both tenants.
- Install the Azure Active Directory PowerShell for Graph module. See https://docs.microsoft.com/en-us/powershell/module/Azuread/?view=azureadps-2.0 for installation instructions.
- Install the Microsoft Exchange Online PowerShell Module. This module includes all the latest Exchange Online PowerShell cmdlets and supports multi-factor authentication (MFA). It can be installed from the Hybrid pane of the Exchange Online Admin Center at https://outlook.office365.com/ecp.
There are two ways that the migration tool can access the source and target mailboxes to perform the migration. Most migration tools use a dedicated service account or accounts for the migration work.
Delegation works by assigning full access permissions for the migration account(s) to each mailbox. Normally, this is done by running PowerShell scripts in the source and target tenants.
Impersonation is an organization-wide elevated access mode which has several benefits for migrations:
- Impersonation does not require setting explicit permissions on the source and target accounts.
- With impersonation, each connection that the migration tool makes uses a separate throttling quota. With delegation, throttling quotas are based on the migration service account. Because of this, impersonation can greatly speed up migration rates.
- Impersonation allows more concurrent migrations.
- Impersonation does not require assigning Office 365 licenses to the migration service account(s).
- Impersonation is configured at the organization level in both tenants using remote PowerShell. Here are the commands to enable it in a tenant.
- You should take an inventory of both the source and target tenants. This can be done using the Office 365 portal, the Azure portal, the Exchange Admin Center, and/or remote PowerShell.
- Record all the accepted domains for each tenant.
- Create a report of all mail-enabled objects in each tenant, including all their email addresses.
Enable-OrganizationCustomization New-ManagementRoleAssignment -Role ApplicationImpersonation -User
You should take an inventory of both the source and target tenants. This can be done using the Office 365 portal, the Azure portal, the Exchange Admin Center, and/or remote PowerShell.
- Record all the accepted domains for each tenant.
- Create a report of all mail-enabled objects in each tenant, including all their email addresses.
- Get mailbox statistics for users that will be migrated, such as number of items and mailbox sizes for each mailbox.
- Create a report of mailboxes that allows other users to access them (delegates).
Having this information can be invaluable later in the migration when you configure the new users in the target tenant. Most third-party tools don’t take secondary and tertiary email addresses into account, so you’ll need to remember to add those to the target users post-migration.
Want to find out more about Jeff’s chapter on Tenant to Tenant Migrations? Then download the free eBook here for his expert advice and more from the MVP community.
