Office 365 has become one of the top hosting platforms for SaaS for companies of all sizes.  The traditional Microsoft Office Product Suite has been the go-to desktop productivity set for many decades and as Microsoft has adjusted their (often confusing) bundled Office 365 licensing packages and pricing models, it is becoming increasingly attractive for managing licensing and reducing infrastructure costs by moving services from on-premises to Office 365.

I know that Stuff.  Why are We Talking about Office 365 Tenant to Tenant Migrations?

As more companies adopt Office 365 for their services, we see an increase in requests for migrating data and services from one Office 365 tenant to another Office 365 tenant when a company acquires or divests from another company.  This is an interesting situation as the standard Office 365 tenant is in a shared hosted platform on the Microsoft network.  Even though most Office 365 tenants are essentially on the same shared Microsoft platform, the data is completely separated out per-tenant.  While this separation exists, there is still the ability to setup different levels of sharing and federation (free/busy, forced TLS encryption, etc.) between two separate Office 365 tenants.

The big issue here is there are limitations on collaboration platforms between tenants; think about two people from different tenants trying to work on the same document in OneDrive for Business or SharePoint Online. Also, a company is still left with having to try and manage users, licenses, and security policies in two Office 365 tenants as well as typically two separate Active Directory Forests.  Not fun.

What are the Options to Fix this?

Typically, a company in an acquisition or divestiture situation does one of four things:

1.      Consolidate Office 365 Tenants and Active Directory Forests

1. Typical approach
2. Use 3^rd-party tools to migrate all Office 365 data and objects to the Target company tenant
3. Use scripting and 3^rd-party tools to migrate AD Forest objects to the Target company AD Forest
   1. All legacy network shares and applications etc. in the Source AD Forest are still available over a two-way domain trust until migrated, decommissioned, or otherwise remediated

2.      Consolidate Office 365 Tenants and Leave Active Directory Forests Separate

1. If you need a quick and dirty way to get both Source and Target users in the same Office 365 tenant
2. Use 3^rd-party tools to migrate all Office 365 data and objects to the Target company tenant
3. Install a Two-Way Domain Trust between the Source and the Target AD Forests
4. Leverage existing Azure Active Directory Connect (AADC) in the Target AD Forest to connect through the Two-Way Domain Trust to replicate Source AD objects to the Target Office 365 Azure AD

3.      Consolidate Office 365 Tenants and Create Net-New AD User Objects

1. Usually smaller acquisitions or divestitures
2. Use 3^rd-party tools to migrate all Office 365 data and objects to the Target company tenant
3. Target company issues new hardware on their domain for the acquisition users
4. Legacy Source AD forest data and/or services are either:
   1. Available via a two-way Domain Trust
   2. Left to “die on the vine” in favor of the Target company’s existing services doing the same thing and usually would be archived after a period of time

4.      Migrate Nothing, Net-New Everything

1. This is not common but some Legal and Government companies require this for security compliance
2. All Source Office 365 and on-premises data and services are left behind
3. Net-new hardware and AD User objects created in Target company AD Forest
4. Legacy Source data and services might still be available for select Information Security teams for a period of time before either being archived or deleted

What does an Office 365 Tenant to Tenant Migration Look Like?

Here are example diagrams of a scenario for implementing Option 1 from above

Existing Separate AD Forests and Office 365 Tenants

Here we can see the original setup of two completely separate AD Forests and Office 365 tenants.  There is nothing connecting the two environments in any way.

Unleash the Potential of Power Platform With a Center of Excellence

Business innovation often comes from within. Discover how to empower innovation from non-traditional developers with the Microsoft Power Platform.

Learn More

AD Forests and Office 365 Tenants During Migration and Staging

During the migration and staging phase, we can see a Two-Way Domain Trust has been setup to facilitate migrating the Source AD Objects to the Target AD and to allow Azure Active Directory Connect (AADC) to replicate the Source AD Forest objects to the Target’s Office 365 tenant Azure Active Directory.  We also have a Hosted Migration Service staging the Office 365 data from the Source Tenant to the Target Tenant.

AD Forests and Office 365 Tenants After Cutover to Target Office 365 Tenant

Here we can see the Office 365 data and the AD Forest object migration has been completed.  The Two-Way Domain Trust remains in place to allow for access to legacy applications and data. All Source End-Users can also leverage this Two-Way Trust to join their existing hardware to the Target AD Forest and connect to their newly migrated data in the Target Office 365 Tenant.

This is a highly simplified example of a Tenant to Tenant migration process.  There are many big discussion items (like whether to bring your Source Domain suffix to the Target Office 365 Tenant) that are not accounted for here.  We will be following up this blog with some of those topics and update accordingly.

Please reach out to Perficient at the very bottom of this page If you find this interesting and would like to know more information.

Jesse Wimberly
Cloud Foundations Solutions Architect