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.
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.
The first question that arises is how do the existing Active Directory & Azure Active Directory structures look like.
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.
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.
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.
|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|
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.
|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
|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|
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.