Office 365 Tenant to Tenant Migration Identity Planning Part 2
In the first part of the blog series, we took a look at the topic of planning and selecting the migration scenario and developed a long-term strategy based on the business and technical requirements and defined how the tenant migration should be implemented schematically.
This is a multi part article with the following parts:
- Office 365 Tenant to Tenant Migration Fundamentals Part 1
- Office 365 Tenant to Tenant Migration Identity Planning Part 2
This section is about the advanced view of migration scenarios, as there are many more indicators that have an impact on tenant migration. If we take a look at the topic of Office 365 tenant migration, in most cases there is an entire hybrid infrastructure. In this context of hybrid infrastructure there are key components like identity management, device management, exchange hybrid, data management & application management.
These topics are individual sub-projects and should be analyzed, reviewed, and considered based on the strategy established in Office 365 Tenant to Tenant Migration Fundamentals Part 1.
Identity Management
Let's go to the first point and one of the most important in my mind "Identity Management".
If identity management is not planned and implemented correctly, it is not possible to ensure efficient operations.
Analysis of existing identity management
The first question that arises is how do the existing Active Directory & Azure Active Directory structures look like.
Azure AD Tenant Scenarios
Azure AD Identity Management
Does the source & target tenant only use Azure Active Directory? (Exclusive user management via the cloud, i.e. Azure AD or Office 365 Portal / PowerShell)
Hybrid Identity Management (AD Connect)
Is synchronization from the local Active Directory used for user provisioning? (AD Connect User, Groups and Device Sync )
Hybrid and Third-Party Identity Management
Are there third-party tools that map existing identity management processes and integrate as a central identity management?
Azure AD Migration Requirements
Azure AD Identity Management
If, as described in the first scenario, only Azure AD users, groups and devices are used, the migration in the identity part is relative simple, because only users have to be created in the target tenant and there are no significant links / synchronizations from on-premises systems.
Hybrid Identity Management (AD Connect)
In the Hybrid Identity scenario, migration can become much more complex as there are a number of dependencies that need to be considered. First of all, as described in Part 1 of the blog series, the target planning and the future strategic IT infrastructure should be completed. The following options can be considered and are eligible for Identity / Tenant Migration.
1. ###### New user creation in Azure Active Directory
One option is to transfer users to the target Azure Active Directory and create them as Cloud Only accounts in the Azure Active Directory of the target tenant. Furthermore, to include / reset the devices in Intune / Auto-Pilot and therefore create a Cloud Only infrastructure.
::blogImage{src="posts/tenant-to-tenant-migration-identity-planning-part-2/20220703203904.png" alt="New user creation in Azure Active Directory"}
::
| Advantages | Disadvantages |
|---|---|
| Cloud Only Management | Separate double / management of identities |
| Azure AD Integration & Intune Management | No centralized mangaement |
| Minimization of complexity | Access restrictions to legacy systems |
| Legacy systems replacement | LDAP / Kerberos no longer usable |
| Cost savings due to elimination of local identity systems | Application access and identity synchronization |
| Active Directory integration not available | |
| Software Deployment |
New creation of users in the Active Directory of the target environment and synchronization via AD Connect
Another option is to create the users & groups in the target environment in the local Active Directory and then provision them in the Azure Active Directory using AD Connect. This does not allow a complete but mostly a clean integration / transfer of a tenant into an existing hybrid infrastructure.
| Advantages | Disadvantages |
|---|---|
| Central management in Active Directory | Lokales Active Directory Management |
| Active Directory Integration | Infrastructure complexity |
| Use of LDAP / Kerberos | Infrastructure costs (Active Directory, AD Connect etc.) |
| Device Management through Intune or OnPremise systems like SCCM | Azure Active Directory Features (Dynamic Assignment...) |
| Legacy application integration |
Connection of the source local Active Directory to the Azure AD Connect infrastructure of the target environment
An additional way of considering a hybrid / synchronized identity would be to connect the local Active Directory (source) to the AD Connect of the target environment to minimize the impact on the existing source structure (OnPremise Active Directory).
In this scenario, synchronization requirements based on supported Azure AD Connect Sync topologies may need to be checked in advance. More information about this at: https://docs.microsoft.com/de-de/azure/active-directory/hybrid/plan-connect-topologies
| Advantages | Disadvantages |
|---|---|
| Minimal impact on local infrastructures (Active Directories) | Authentication |
| Active Directory Integration | Increased management effort |
| Use of LDAP / Kerberos | If necessary complex sync rules |
| Existing permissions can still be used | Network connection of the Active Directory |
| User / group objects can still be used | Infrastructure costs & operation |
| On- & offboarding processes can still be used | Sync Dupliakte & Sync Errors |
Hybrid and Third-Party Identity Management
Another variant, which is in most cases the most complex, is the migration / consolidation taking into account other third-party identity tools such as SAP or other HR applications. An important role plays the processes in the source & target environment and whether an integration with all requirements of internal employees, external, long-term, short-term etc. can be implemented and whether this fits into the long-term strategy to merge the companies / tenants.
Other options and transitions can also be that a new tenant / Azure Active Directory is set up and that both tenants are transferred to a new infrastructure. This can be the case, for example, with name changes, since the previous names may no longer be used and is usually used as the tenant name (SharePoint) and can not be changed
There is no universal blueprint for migration and merging. It always depends on the requirements and the future strategy. The listed options are only a few excerpts from the possibilities that exist. Depending on the requirements or new features etc. these can be edited and adapted. This list and the blog entry should serve as a basis and impulse to think about the best possible approach to ensure an efficient migration in the long term.
Tenant Migration - Quest on Demand
In situations like mergers, Office 365 tenants often have to be consolidated or migrated. Du to different companies having different requirements to compliance or governance standards. I would like to share my personal experiences in with the Quest's on Demand Migration utilities.
Terraform - create Blocks Dynamically - using the Dynamic Block
Some resources in Terraform allow to pass them a list if multiple values can be set - for instance, DNS servers for the azurerm_virtual_network can be set this way. However, on the same resouce, you can add subnet during the creation and this would not work in the same way, because each subnet requires their own subnet-block in the resource. However, Terraform offers a way to create mutiple blocks of the same kind dynamically - using the dynamic-block.