Lifecycle of a User Identity During a Migration  

Avoiding Identity Confusion

When measuring the success of a migration, a common metric is verifying whether users maintained seamless access to their resources throughout the migration project or whether they encountered issues caused by user identity confusion.   

If you are simply consolidating resources from one domain to another in the same forest, then you might avoid changing user identities during the migration. You can simply re-grant access to the migrated resources and help users update their shortcuts. 

However, most migrations require you to create separate user identities in another environment. This can result in user confusion with juggling multiple identities and different passwords and can cause uncertainty about which identity to use for each resource. 

Performing A Big Bang Migration 

For smaller migration projects, one method to reduce the impacts on user identities is to perform a big bang migration, where you migrate everything in the same event, including Microsoft 365 resources, user devices, and possibly the domain itself that is assigned to the user identities.  In a big bang migration, users are primarily impacted during the final migration event and do not have coexistence challenges. 

A big bang migration with a domain move results in the following user experience: 

• Easy-to-find resources: When users log into their target account, they quickly find all their resources since all content is migrated during a single event. 

• Consistent GAL: When users open the global address list, they see all their contacts in one place since everyone is migrated together. 

• Same identity: Users still have the same username they had before the migration. 
  • From the end user’s point of view, their user identity will not have changed. 
  • From a technical point of view, you will have provisioned new user identities in the target, assigned a placeholder domain to the target accounts during pre-migration prep, and then updated the domain on the target accounts during the domain move. 

However, not all big bang migrations include a domain move, especially migrations driven by company acquisitions. These migrations still provide the benefits of consolidated resources and contacts, but users will have a different username than they had before the migration. 

• User Education: Communicate new account details ahead of time to minimize productivity impacts while users adjust to their new user identities. 

• Resource Management: Update access controls on migrated resources to ensure users have the same permissions with their new user identities. 

A big bang migration does not eliminate all possible user impacts, and you must still provide guidance to improve the end-user experience: 

• MFA Setup: If users require multi-factor authentication on their new user identities, they can do this ahead of time or during their first login after migration. 

• Application Access: Users may need to reauthenticate some applications when they open them for the first time after migration. 

• Password Changes: If you do not synchronize passwords from source to target, provide users with their new password and include instructions for changing it in the target. 

Performing Phased Migrations

For larger migration projects, you may need to migrate users and resources in batches and consider how to manage the coexistence between migrated and non-migrated users and resources. The following examples describe common user identity challenges that occur in a phased migration. 

Different Identities for Different Microsoft 365 Resources 

Many tenant-to-tenant migrations are phased by resource type, migrating personal data first and shared data later. This results in migrated users juggling two user identities during the coexistence period: 

• Migrated Personal Data: You will provision new user identities in the target environment, provide the new credentials to the users, and instruct them to access their migrated mailboxes and OneDrive content with that new identity. 

• Non-Migrated Collaboration Data: Migrated users must access non-migrated Teams and SharePoint sites with their source user identity. Alternately, you can provision B2B accounts for their target user identities and provide guidance on cross-tenant collaboration. 

• Non-Migrated Shared Mailboxes: Migrated users can only access non-migrated shared mailboxes using their source user identity. They must remember not to use their source mailbox for any other purpose besides accessing non-migrated mailboxes. 

Different Identities for Microsoft 365 Resources vs. Network Resources 

Once you have migrated all personal and shared Microsoft 365 resources to the target environment, users will be juggling two user identities if you did not perform an Active Directory migration. 

• Computer Login: Migrated users will log into their end-user devices with their source user identity and access their Office applications with their target user identity. 

• VPN Connections: Migrated users may require multiple VPN connections to access source and target network resources once you start the AD migration. 

Switching Identities with a Domain Move 

Migrated users will adjust to their new user identity during the coexistence period, but you may impact them once more when you move the domain. 

Reassign the Original Username: When you move the domain to the target environment, you may choose to reassign the domain to the usernames on the target user identities. 

• Communicate the change ahead of time to minimize productivity impacts while users adjust to switching back to their original usernames. 
• Users may need to reauthenticate to some applications when they open them for the first time after their identity switches. 
• Users will keep their existing passwords. 

Continue Using the New Username: If you move the domain to the target as a secondary domain without changing their target usernames, users should not notice any impact. 

Notify users when all migrations are complete, communicating that they no longer need to juggle multiple identities and that they can use a single user identity moving forward. 

Assigning Passwords on New Identities

When provisioning user identities in the target environment, you must determine how you will assign their passwords. 

Active Directory migrations 

One method for assigning passwords during an AD migration is deploying a solution that synchronizes passwords from one AD to another. This option impacts users the least since they have the same password on both user identities. However, you may be unable to implement a password sync due to security or cost concerns: 

• Elevated Privileges: Most password sync solutions require a service account that belongs to the built-in Domain Admins group. 

• Legacy Encryption Algorithms: Password sync solutions either write the password directly to the target account or copy the hash to the target account. If you synchronize passwords using a copy-the-hash method, you may need to keep RC4 enabled in the target environment.  Many companies are disabling RC4 in favor of AES per Microsoft’s recommendations. 

• Software Cost: If you are performing migrations using native tools, then you can consider ADMT’s Password Export Server from Microsoft. If you are using third-party migration tools, many also include password sync functionality. 

Provisioning User Identities in Microsoft 365 

When migrating from Active Directory to a cloud-only environment, you may be able to utilize Azure AD Connect or Azure AD Cloud Connect.  Both solutions can provision user identities in Entra ID and support password sync from Active Directory. 

Converting from hybrid to cloud-only: If you are converting an existing hybrid environment to cloud-only, then you do not need to provision new user identities.  

• Convert the existing user identities in Entra ID from hybrid to cloud-only. 
• Converted identities will retain their existing passwords, licensing, group membership, and Microsoft 365 resources access. 
• Provide user education on accessing resources using their Entra ID instead of their domain sAMAccountName. 
• Provide VPN instructions if users require access to network resources. 

Migrating to a Different Cloud-Only Environment: If you are migrating to a tenant that is not connected to your Active Directory, consider temporarily configuring Azure AD Connect or Azure AD Cloud Connect. 

• Provision hybrid accounts in the target tenant along with their passwords. 
• Once the migration is complete, convert the accounts to cloud-only and remove the temporary configuration. 

Assigning New passwords 

If you are unable to configure a password sync between the source and target environments, consider alternate options for assigning passwords to the new target user identities: 

• Administrative Assignment: Manually assign passwords to each target identity, flag them to require a password change on the next login, and supply users with the new credentials. 

• User Self-Assignment: Consider purchasing a third-party solution that allows users to authenticate with their source user identity and set their own password on their target user identity, using the source-to-target account pairing that you configured. 

Next Steps

As you map out your migration plan, consider how your decisions impact the user identity lifecycle by asking yourself these questions:  

Are you planning a big bang migration or a phased migration? Are you going to move the domain itself? What is the expected end-state configuration of the target user identities? How will you assign passwords on the target accounts? Can third-party solutions assist with your migration? 

Remember to educate your users early and often so they can find their resources throughout the migration and clearly understand which user identity to use and when.