A tenant to tenant migration is a complex and often challenging process. From the very decision of which tenant will become the new host, every step is critical to achieving success. In the case of a tenant to tenant migration, the devil really is in the details.

In the first part of this series on tenant to tenant migration, I focused on the many considerations prior to starting the migration process. One that I didn’t cover is around the existing tenants’ naming convention. Each tenant already has an individual name so when one tenant moves to the other, they adopt that tenant name.

In some situations, this may not be ideal. For example, a customer might see the tenant name when sharing files, which the company might not want. Or, if the company wants to take a particular marketing approach, they may not want to expose the tenant name –– they might want it to be more generic.

In this instance, the two entities might not migrate to one tenant or the other but instead choose to create a third tenant, known as a greenfield tenant. In this scenario, both companies must migrate their data to this new tenant, essentially starting from scratch.

While taking a greenfield approach can be more complicated than migrating one tenant to the other, there are some significant benefits to doing so. For example, if a holding company is in the business of acquiring and selling companies, a tenant with a generic name is easier to roll a company into and migrate into their organization.

One of the most important migration activities is properly transitioning email from two domains to one. Ideally, to migrate email from one tenant to the other, we use specific tools to scan the source tenant and create mail-enabled contacts and create coexisting calendars between both tenants.

Unfortunately, this is often a step that becomes complicated by an eager IT person at one of the two organizations. Because email is so critical to a business, it’s one of the first considerations when thinking about a tenant to tenant migration, so that helpful IT person might proactively start creating new email accounts in the target tenant before the users are properly prepared to be migrated over.

While it is always done with good intentions, the problem with this scenario is that it can become a “gotcha” when completing the actual migration. Implementing something like new email addresses without consultation can cause complications for smoothly transitioning one company’s email to the other’s, often leading to a loss in email data, either from the existing account or from the newly created account.

Another common complication is discovering third party integrations during the process. For example, in Outlook, some departments may have implemented third-party add-ins that do certain things to benefit their work. A marketing or finance department may have added in tools to help with invoicing or email distribution. The problem with these add-ins, from a tenant to tenant migration perspective, is that they have the potential to break the client while doing the migration if they’re not addressed properly.

The best way to avoid these kinds of surprises is to have a good handle on who’s using what within the tenant. While this can be a challenge for large organizations, it’s something that we delve into during the assessment phase of the migration process.

A tenant to tenant migration is much more than a lifting and shifting of applications and data from one cloud to another. It requires precision, attention to detail, and covering every possible scenario.

 

In Part 3 of my series on a tenant to tenant migration, I covered some of the post-migration considerations as well as how to handle the reverse scenario –– a divestiture. You can read part 3 here. 

 

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