Office 365 Identity Management in Cross-Tenant Migrations

Perhaps one of the most complicated parts of an Office 365 tenant migration is handling the Identity aspects. Each project is unique, which is why you need proper consultation to decide the best option for you.

This article focuses on the technical aspects of the project, but if you’d like to explore the change management side – and more importantly the ‘people’ aspect of these projects – you can also check out our Method to the MADness series.

Let’s review at a basic level some of the items that people put into the large and deep bucket of identity: 

• Azure AD Guest Users 
• Contacts 
• Distribution Lists 
• Application Registrations 
• Domains 
• User Accounts 
• Service Accounts 
• On-Prem AD 
• Azure AD 
• AD Connect 
• Third-Party Identity Management Solutions 
• Licensing & Entitlements  

O365 Identity Management

There might be some surprises on that list, but many things can fall into the Identity move. In this post, I am going to cover a few of these. 

The ‘Easier’ Items 

Although these items can uncover some larger issues, in general, a discovery process can be done pretty quickly on some of these items. You can then categorize each into a migrate, delete, or research category. 

• Azure AD Guest Users 
• Contacts 
• Distribution Lists 
• Licensing & Entitlements 

The ‘Moderate’ Items 

The main items that are ‘moderate’ effort in my opinion are Application Registrations. You can easily inventory them, but what you find might not be so easy. This is very helpful to discover early in your project. It can be a good hint into some major applications or processes that need to be addressed. When you perform your migration, you will have needed a plan to handle these with either moving the registration, and application, or both. 

The ‘Hard’ Items

This is where things get difficult, and what most people think of as identity issues in a cross-tenant migration. User accounts, on-prem Active Directory, Azure AD, and Domains are the biggest issues. When conducting a project, each one will be different. How these items are handled is very important.   

There are a few factors from my experience that drive the major identity decisions. There is one key question that drives the strategy: 

How Many Users are Migrating Vs How Many are in the Target? 

Simply put, if you are an organization of 50,000 users, and you acquire a company of 200, the new company will need to comply with the new parent company’s policies. In these scenarios, most organizations will provision new accounts in the target and migrate. 

This resolves issues where the acquiring company does not want to remediate the source environment to their standard and, frankly, it is faster and easier to simply bring the users into their security control. 

1. Setup 
   Users will need to enroll and set up their new account as if they were a new employee.  This likely includes setting their initial password and setting up MFA. You can likely re-use new employee documentation with some slight changes. 
2. Tenant Config Challenges
   In these situations, the tenant configuration was likely to be less restrictive than the target. This means functions the users are using may not work or be more restricted. If the business is using some of these items, like anonymous links, they will need to change their ways. Users may need training and communications. These are great items to include in the Weekly Countdown Communications, which we have great templates for here.
3. Turn off the Old
   When using essentially dual accounts, sometimes the old directory remains. This can cause some issues in forcing people into the new directory and company. In these situations, you want to ensure users are forced into the new tenant and their access restricted to the old tenant. THIS INCLUDES EXTERNAL GUEST USERS! 

Merging Tenants

So, we covered when a large organization acquires a small company, but what happens when the cross-tenant migration is more complex? What happens when it is more a merger of users than a takeover? 

This requires much more careful planning. 

1. Discover
   We talked about this briefly, but when combining large amounts of users, this needs serious planning.  In smaller acquisitions, the acquired users are forced into a security policy.  With large amounts of users, this may have major impacts.  Agreeing on a final tenant configuration is very important and was covered in good detail during our expert roundtable on O365 tenant migrations.
2. Plan
   Most in this category will do a form of AD syncing. If you are using native tools, it will likely be a custom AD Connect setup. If you are using a third-party ID management system, then you may have some additional options. You will need to plan these activities and coordinate them with the Domain move – if you’re migrating the domain. This needs careful planning and coordination, and, ideally, practice!
3. Setup
   When using an ID sync process, the user usually keeps the same password they had, but may, or may not, need to set up MFA again. Do keep in mind if you’re moving the domain over, this still isn’t ‘migrating’ the AD account. The account can be set up to look and feel like the old account, but this is still a new identity in a new tenant. This means if they were a guest in another tenant, shared documents links, received shared documents links, and other activity will all need to be addressed.
4. Turn off the Old
   You also need to properly cut off access to the source. This will vary by the solution you choose. Again, you must handle external users as well.

Want to learn more? Quadrotech has a great group of highly-trained and capable Partners that know the intricacies of Office 365 identity management challenges for cross-tenant migrations, and we often collaborate on tenant migration projects.

If you have any questions, please get in touch with us today.