In the age of pure on-premises environments, it was rare to have more than a single Active Directory environment. Even when you did, it was merely tied together with a simple Forest Trust. On a rare occasion when two companies merged, an Active Directory consolidation would be necessary. In other situations, the acquired organization was simply assimilated into the parent company’s Active Directory environment. This mindset was primarily due to the cost and/or complexity of Active Directory Consolidations. Microsoft does provide a free utility, Active Directory Migration Tool (ADMT), to assist, but larger, more complex mergers required costly 3rd party tools to manage the migration and maintain coexistence since these types of projects could last up to 24 months.
That leads us to today’s world of the cloud with Azure Active Directory (Azure AD). Active Directory was created for an object-based hierarchy. However, Azure AD is an Identity solution that was created for the cloud, and uses authentication based on user/device objects and web-based services. In Azure AD, you will not be creating forests, but rather tenants. Unlike Active Directory, where a deployment could take weeks or months, an Azure AD tenant can be created in minutes by anyone. Anyone using Office 365 services already has an Azure AD tenant. Anyone that has access to a publicly routable domain and its DNS zone can create an Azure AD tenant and assign that domain to the tenant. As you can see, you can easily find yourself having multiple tenants without proper governance when delving into the cloud.
Why consolidations happen
There are many legitimate reasons why organizations have multiple Azure AD and Office 365 tenants. Some include mergers, acquisitions, and divestiture. Others need to isolate workloads, or rebrand their domain names. Regardless of the reason, many companies find themselves needing to consolidate or migrate to a new Azure AD and Office 365 tenant. Unlike Active Directory migrations and consolidations, where Microsoft provides ADMT, there are no native tools to migrate from one tenant to another. Some tools can aid in the transition, such as Azure AD Connect, while other tools, such as BitTitan or ShareGate, are needed for the individual application and data migrations.
What is involved
There are typically two scenarios for tenant to tenant migrations; consolidations and mergers. Consolidations include acquisitions where the acquired company is migrated to the parent company’s environment. These typically involve two tenants, source and target. If a merger is occurring instead, that adds a third environment to the mix, typically a brand-new tenant to move both source tenants to, but follows the same general flow as consolidations. From a high-level there are three stages to a migration or consolidation for an acquisition. A fourth stage would be necessary if also consolidating on-premises Active Directory.
Stage 1: Current State Discovery
You should start with planning and discovery to determine what needs to be migrated and what the desired end state should look like. While an acquirer typically has the authority to assimilate the acquired company directly into an existing tenant, larger mergers sometimes require a brand new tenant and require two migration projects, one for each organization, into the new tenant. The following depicts a typical starting point for two organizations with completely independent environments.
Stage 2: Migration State
During this stage, you are in full swing of execution mode. If the acquired company has not started using any Office 365 or Azure AD services, identities can be synchronized to Azure AD using a single Azure AD Connect server for all forests involved. After that, you can begin moving to Azure AD and Office 365 workloads. However, if they are using Office 365 services such as Exchange Online, you will have to plan a cutover of the identity and applications involved. Coexistence is possible in this state, but creates a highly complex design and implementation plan.
If at all possible, plan for cutover tenant to tenant migrations. The following depicts a typical state when executing your migration plan. The two environments are connected with an Active Directory Trust for on-premises integration and other tools are being used to transition data over to the target tenant.
Stage 3: Consolidated Cloud
At this stage, the two environments have been consolidated and in the desired end state . However, this has not yet merged with the acquired company’s on-premises Active Directory into the parent’s environment. If this is the desired end, it is better to perform the cloud consolidation first, then focus on the Active Directory consolidation.
Stage 4: Desired End State
The final stage involves consolidating the on-premises Active Directory environment. With the cloud dependencies out of the way, this migration should be much easier to accomplish. If using native tools such as Active Directory Migration Tool (ADMT), or other 3rd party software, a key addition to a typical AD migration is to use and copy the MS-DS-ConsistencyGUID attribute when moving users. If this is not set as the Source Anchor in Azure AD Connect, change to this prior to migrating AD users.
Each stage comes with their own challenges, some similar while others are unique. These challenges can be categorized as follows:
- Non-technical Challenges
- Technical Challenges
In the next parts of this series, we will dive deeper into common, recurring challenges of any tenant to tenant migration that you should anticipate. Enabling Technologies can help you enable secure productivity in the cloud by properly preparing you for moving to Azure AD and Office 365 based on Microsoft best practices. You can check out more in the Cloud section of our website.