Tenant-to-Tenant Microsoft 365 Migrations

25 Jul Tenant-to-Tenant Microsoft 365 Migrations

Posted at 07:00h in Migrations by Simon Spencer

Organizations that are undergoing a merger, acquisition, divesture, or rebranding will need to migrate their Microsoft 365 infrastructure to a new “tenant”. That is where Tenant-to-Tenant Microsoft 365 Migrations come in.

T2T Migrations make the process of moving the resources, information, and accounts of one organization to a new entity. Migration can, however, be long and complex – especially if two large-scale M365 infrastructures need to be merged into one single cloud platform.

What is a Tenant-to-Tenant Migrations in Microsoft 365? In what scenarios and situations should your business consider them? What are some common challenges of T2T migrations, and what process should your business follow when embarking on a migration?

In this article, we will teach you all you will need to know about Tenant-to-Tenant migrations in Microsoft 365.

What is a Tenant-to-Tenant migration?

In Microsoft 365, tenant-to-tenant migration refers to the process of migrating your information from one Microsoft 365 tenancy to another.

What is a tenant in terms of Azure & Microsoft 365? It simply refers to the set of services that make up your organization.

Typically, a tenant is associated with one or more of your public DNS domain names – and they function as a central container for your Microsoft 365 licenses.

Tenant-to-Tenant migrations are commonly required during mergers, acquisitions, rebrands and divestitures. When an organization merges or otherwise changes its structure, a new tenant may be needed or the subscription, services, users, domains etc. may need to be merged with an existing tenant.

For instance, if a business has been acquired or merged with another organization, a tenant-to-tenant migration may be needed to migrate both organisations into a new conglomerate tenant.

What are the different approaches to migration?

Microsoft sets out a range of different migration architectures depending on the scenario and circumstance of the tenant-to-tenant migration.

Let us briefly explore the options available to you:

Single Event Migration

Intuitively, a single event migration is the most straightforward tenant-to-tenant migration. Here, all accounts, services and domains are migrated into one single event. These migrations tend to complete faster but are also inherently riskier – as all data is going to one, single repository.

You can mitigate this risk by establishing an Exchange hybrid coexistence or using a phased migration.

Why would your business opt for a single event migration? For acquisitions where there is no rebranding – e.g., the DNS remains originalbusiness.onmicrosoft.com and user@originalbusiness.com – a single event migration may be a suitable option.

In practice, you should avoid this migration architecture if you are managing over 15,000 users or 7 TB of site content. Many medium-sized digital businesses will find that site data volume limitations too constraining.

Phased Migration

A phased migration involves gradually moving users, services, and data from one tenant to another – as opposed to the “Big Bang” tactic of single-event migrations.

With this migration architecture, however, source domains cannot be transferred, and users assume new target domains. This method is useful if the migration is needed due to rebranding – i.e., you have sold your business and the organization will adopt the target company’s branding.

Due to the phased nature of the data migration, this is less risky – but takes much longer. Phased migration requires a certain level of coexistence – and the limitations of this approach (especially for scaling resources) can cause issues. Employees may need to sign in with multiple identities and may require duplicate licensing over the migration period.

Tenant Move or Split

If users need to be split between two target tenants – for example where a subsidiary splits from a parent organization – a tenant move, or split is needed.

Here, identities remain in the source tenant, but all users and workloads are moved to a new cloud tenant. This method is fairly similar to single-event migration, but accounts are not moved to a new event.

Common Tenant-to-Tenant Migration Considerations

A Microsoft 365 tenant-to-tenant migration is a complex procedure – and most M365 customers work with a Microsoft partner to migrate tenants.

Microsoft has listed some common considerations that organizations need to make during this process:

Before migration:

Communicate fully with users – notifying them of the impacts of the migration. Avoiding this or not communicating effectively may lead to data loss, and lost productivity.
Ensure that files, mailboxes, and other cloud content is put into read-only mode to eliminate any overwriting issues.

During & after migration event:

Enable target accounts, if needed.
Complete the final data migration & ensure all data has been moved correctly
Set up any new accounts needed and circulate logins
If adopting a phased migration, communicate which identities are needed at which stage of the migration

Get your tenant-to-tenant migration right with a Microsoft Partner

Most businesses use a Microsoft Partner to help them embark on a tenant-to-tenant migration. This is because this is a complex, and risky procedure – with lots of considerations and requirements to proceed correctly.

Using a third-party migration tool is key to making sure the tenant-to-tenant migration goes smoothly. Undergoing a merger, rebrand or divesture and need to undergo a tenant-to-tenant migration?