What Is a Tenant-to-Tenant Migration?

For organizations considering a tenant-to-tenant migration, there are many technical and business factors to review. In working with CDW customers, we’ve found conversations between IT and business stakeholders can sometimes stall when both teams struggle to articulate goals and challenges.

With that problem in mind, this blog post's goal is to provide both a high-level technical understanding to our business stakeholders and a few decision points for them to consider. For our IT team, these business decision points can be used to zero in on the technical implications.

M365 is a cloud-based service that hosts some popular services such as Exchange Online, OneDrive for Business and Microsoft Teams. It allows licensed users to perform collaboration tasks such as messaging their peers in Microsoft Teams and accessing email via Outlook.

An M365 tenant is your organization’s space inside of the larger M365 service. Inside your tenant, your IT team can customize the experience and settings to meet your organization’s security, compliance and security needs. The tenant also is where all your user mailboxes, shared mailboxes, SharePoint sites and Teams are managed.

Looking at the example above you may also notice there are two domains "Contoso.com" and "Contoso.onmicrosoft.com." Let's first cover the tenant domain "Contoso.onmicrosoft.com."

Each M365 tenant has a unique "onmicrosoft.com" domain that is used to identify the tenant on the backend. This domain cannot be shared or moved to another tenant. In most cases, this domain is hidden from users and only appears in certain scenarios such as SharePoint Online URLs and sharing files using OneDrive.

The vanity domain Contoso.com is the domain your users probably see and interact with every day when they are working. This domain can be transferred between tenants, although doing so might be very difficult and expensive depending how your users are using that domain. Vanity domain transfers are a common part of tenant-to-tenant migrations.

The purpose of a tenant-to-tenant (T2T) migration is to move users, resources and data between two M365 tenants. There are a few reasons customers inquire about T2T migrations:

1. Mergers
2. Divestitures
3. Tenant domain name changes
4. Changing tenant types or geographies

In this merger scenario we have two separate companies with M365 tenants in Contoso and ACME, as shown below. ACME recently acquired Contoso and as a part of the acquisition strategy has elected to combine their tenants. When starting out, you can see there are two M365 tenants, each with their own users, data and supported domains. At the end of the migration, all the users, resources and data that were in the contoso.onmicrosoft.com tenant have been transitioned to the ACME.onmicrosoft.com tenant.

In this divestiture scenario, we have a single M365 tenant supporting two different product lines. To streamline operations, the decision was made to split into two different organizations. The new organizations decided to transition the Contoso users, data and domain to their own tenant. Looking at the example below, you can see the ACME.onmicrosoft.com tenant supports both the ACME.com and Contoso.com vanity domains. In a single tenant, they are split between the contoso.onmicrosoft.com and ACME.onmicrosoft.com tenants.

In this scenario we have a customer who has a tenant domain of ACME.onmicrosoft.com. This customer has been operating under this name for the past five years but recently rebranded to Contoso and would like their tenant domain to reflect that change. Remember, it is not possible to change a tenant domain name once the tenant has been established, so to change ACME.onmicrosoft.com to Contoso.onmicrosoft.com, a tenant migration is required.

Customers considering a migration for this purpose should consider that the tenant domain is hidden to users in most scenarios. Due to the complexity and cost associated with these types of migrations customers typically don’t elect to perform a tenant migration for this reason alone.

Microsoft has recently announced a new process to change SharePoint Domain names without completing a tenant to tenant migration. While not yet widely available, this option may be worth considering if a tenant name is the basis of your organization. 

Some settings and features set when the M365 tenant is created cannot be changed after the fact. Once a region has been selected, the M365 tenant is created in that geographical region and the tenant cannot be moved to a new region (specific workloads can be geographically moved in some cases). For example, say you create an M365 tenant in the United States but your organization HQ moves to Germany. If you need your M365 tenant to reside in Germany for legal/compliance reasons, you would need to perform a tenant migration to transition to the M365 tenant hosted in Germany.

Similarly, you might setup your initial tenant as a consumer tenant, but your organization operates in the education space and you need to take advantage of features available only in the education tenants. Microsoft does not have the capability to add education licenses or education features to a tenant that wasn't created as an education tenant. As a result, a transition to the education tenant may require a tenant migration.

In both examples above, a single tenant could have its users and resources migrated to another tenant with the specific features or geographies required. The tenant domain name would still need to change as a part of this migration.

There are a lot of reasons organizations might decide to consolidate or split their M365 tenants. The most common reason we see multiple tenants is when business or legal reasons require the tenant be managed as two distinct entities. Here are a few common pros and cons we hear from our customers.

Pros:

• All users, resources and groups in M365 can be managed by a single IT team
• Collaboration is seamless
• Settings are consistent for all usesr
• Consolidated license agreements may reduce cost per license
• Third party integrations can be managed in one tenant

Cons:

• M365 administrator permissions cannot be consistently delegated
• Some settings are organization-wide and managing exceptions for users can be challenging

Pros:

• Administrative permissions between tenants are clearly defined
• Each organization can managed its own organizational settings

Cons:

• Administrative access to each tenant needs to be managed independently
• Each tenant needs an M365 admin team
• Separate license agreements may increase the cost per license
• Collaboration between tenants requires additional admin management and tools
• Third-party integrations need to be managed in multiple tenants

This may seem counterintuitive, but just because you are using some of Microsoft Cloud, that doesn't mean all your Microsoft services are being supported from your Office 365 tenant. Your organization may or may not be planning to migrate other services supported by Microsoft products such as Active Directory, file servers, print servers, user accounts and computers at the same time as your tenant migration.

Migrations for these other Microsoft services are distinct from the tenant migration, though these migrations may have dependencies with your Microsoft 365 tenant. To ensure you have the best transition for your business, your IT staff is likely hard at work figuring out which service should be moved and when. We won't dive into the specifics, but keep in mind that there will be some other moving parts to provide some direction to your migration plan.

Story by Ryan Bandel, a Technical Architect focused on Microsoft Collaboration on the Services R&D team at CDW.