A merger, acquisition, or divestiture inherently triggers change across not only one, but potentially multiple organizations. It requires a multitude of decisions — from staffing to branding to capital consolidation. One of the most challenging decisions, for many organizations, involves a tenant to tenant migration.

A tenant to tenant migration, in its simplest terms, is moving one company’s cloud contents to another, so that both entities can access all, not just some of the data, applications, and tools stored there.

While that might sound like a minor task, tenant to tenant migrations are in actuality a complex process that involves data-based decision making, and a deep assessment of both cloud environments. Why? Because the decision to move content from one tenant to another doesn’t necessarily default to the bigger brand, the larger company, or the organization doing the acquiring. If done properly, it’s based on facts.

The first step in the assessment is to get an accurate snapshot of each tenant and assign scores to each. During the assessment, we look at a number of different elements, including who is using what applications within each organization. We tabulate the active workloads and then determine both the usage and the productivity for each of these workloads.

For example, we might hone in on the usage of Microsoft Teams within a tenant. How many people are using it? Which departments are they in? What are they using it for? What other workloads are they using with it? How much time do they spend on Teams per day? Per week? Per month?

We also find commonalities and differences between the tenants. If one uses multi-factor authentication and the other doesn’t, we may have to enable it on the tenant that isn’t using it if the decision was made to migrate to that tenant in order to allow for a smoother transition. The same might go for Yammer or any other number of workloads or tenant configuration settings.

By breaking each tenant down into individual workloads, we’re able to take an objective approach, versus a subjective one, when determining which tenant should become the new host. Sometimes that decision isn’t expected or even welcomed by the organizations involved, but having the data to make the case for the move in one direction or the other is often necessary and makes the decision difficult to dispute.

Once that decision is made — and it should happen within the first few weeks of the pre-migration period — it’s time to dig in and begin prep work. This includes a number of tasks such as resolving any issues that were discovered as part of the tenant assessments, creating a master list of users and mailbox mappings, recording all accepted domains, purchasing migration tool licenses, running Health Checks for Office 365, and planning for domain cutover, just to name a few.

Having a pre-migration checklist is critical to a successful tenant to tenant migration. I have trained as an instrument-rated pilot and preparing for a tenant-to-tenant migration reminds me of my flying days. Before you ever get off the ground, you need to go through an extensive flight checklist one item at a time to make sure that all systems are ready to go, and you’re prepared for take-off.

In Part 2 of this series, I’ll talk about what cutover day looks like, and the process of moving Office 365 mailboxes from one tenant to another.

Click here to learn more about the On-Ramp to Microsoft 365: Tenant to Tenant Migration program.