Migrating an existing domain user profile to an Entra ID user profile when moving from Hybrid Join to Entra Join

What you are seeing is expected - Microsoft Entra joining a PC does not automatically convert or reassociate the existing on-premises AD user profile with the Entra ID sign-in identity. Windows treats the Entra ID sign-in as a different Windows security identity, so it normally creates a new profile under C:\Users.

I'd advise against manually copy the old profile into the new Entra profile and hoping that everything continues working. A domain account and an Entra ID account have different SIDs, authentication context, profile registrations, credential material, application registrations, and other identity-dependent information. Simply changing the ProfileImagePath or changing ACLs so that the new account owns the old profile can leave applications, credentials, OneDrive, Microsoft 365 authentication, and other components in an inconsistent state.

For a migration where you want to preserve the existing Windows environment, Microsoft's User State Migration Tool (USMT) is the traditional Microsoft-supported mechanism for migrating user state. USMT is part of the Windows Assessment and Deployment Kit (Windows ADK) and is designed to capture user files and Windows/application settings from an existing Windows installation and restore them to another user/environment. It can therefore be incorporated into an automated migration process rather than having IT manually rebuild every workstation.

However, keep in mind that USMT is primarily a user-state migration technology, not a tool that magically converts a domain profile into an Entra profile. You need to design the migration so that user data and supported settings are captured from the existing domain profile and restored into the user's new Entra-associated profile. Application installation itself is generally handled separately through Intune, Configuration Manager, Microsoft Store, Win32 app deployment, or whatever software-distribution system you use.

There are also third-party profile migration utilities commonly used for this particular domain-to-Entra transition. Tools such as ForensiT User Profile Wizard can reassign an existing Windows profile to a different Windows account/SID and are frequently used for domain-to-Entra migrations. This can be considerably faster than rebuilding the profile, particularly when you have hundreds or thousands of existing PCs. However, that is a third-party migration solution, not a Microsoft-provided utility, so it should be evaluated separately from the Microsoft-supported USMT approach.

For a large migration, I would generally avoid the "remove from domain, join Entra ID, and then let the user start over" approach unless the workstations are already being replaced or rebuilt. A better architecture is to separate the device migration from the user-state migration. First inventory the existing applications and user data, establish how applications will be deployed through Intune or another management platform, ensure OneDrive Known Folder Move and Microsoft 365 application configuration are appropriately planned, and then migrate the Windows identity/profile as part of the device transition.

One important consideration is OneDrive. If OneDrive is already being used with the user's Microsoft 365 identity, you should not assume that copying the old OneDrive profile directory is the correct migration mechanism. OneDrive has its own account registration and authentication state. After the Entra sign-in, OneDrive should be configured to sign in with the user's Entra/Microsoft 365 identity and, where appropriate, Known Folder Move can ensure Desktop, Documents, and Pictures are protected and synchronized. This also makes the migration much less dependent on physically copying user data between profiles.

Outlook should be treated similarly. Modern Outlook/Microsoft 365 authentication and profile configuration are identity-aware, so copying an old Outlook profile wholesale is not necessarily desirable. The user's mailbox data is in Exchange Online, while cached OST data can be recreated. With appropriate Microsoft 365 and Intune configuration, Outlook can generally be provisioned for the user's Entra identity rather than attempting to preserve every piece of the old authentication state.

Browser profiles and application-specific settings require more attention. Microsoft Edge, for example, can synchronize favorites, passwords, extensions, settings, and other supported browser data when the user's organizational account is configured for synchronization. Other applications may store settings under AppData or in the registry and may require USMT, application-specific migration procedures, or testing to determine whether those settings can safely follow the user.

If the existing workstation is going to remain in place, one strategy is to migrate the existing Windows profile to the Entra account rather than creating a completely new profile. This is where a profile/SID migration tool can be useful. The existing profile remains physically in place, and the profile's association is changed so that the Entra user uses it. This can preserve considerably more of the user's existing desktop, AppData, registry-based application settings, and configuration than starting with a clean profile. Nevertheless, this needs to be tested carefully because some applications and stored credentials are explicitly tied to the original domain identity.

Another strategy, particularly if you are moving toward Windows Autopilot and Intune, is to treat the migration as a controlled device reprovisioning process. Applications are redeployed automatically, user data is protected/synchronized through OneDrive, browser and Microsoft 365 settings are synchronized where supported, and only settings that genuinely need to be migrated are transferred. This produces a cleaner long-term Entra/Intune environment, although it can require more preparation than simply converting the existing workstation.

For an organization doing this at scale, I would build a pilot migration around three approaches: first, test an existing-profile reassignment approach on representative PCs; second, test USMT for capturing/restoring the required user state; and third, test a clean Entra join with Intune application/configuration deployment and OneDrive/Edge synchronization. Measure which approach preserves the applications and settings your users actually depend on. There is no single Microsoft process that guarantees that every existing domain profile can be converted into an identical Entra profile without side effects.

I would also not make "domain unjoin -> Entra join -> user signs in -> manually configure everything" your production migration procedure. For an existing fleet, that creates exactly the downtime and support burden you are concerned about. A staged migration using Intune/Autopilot for device configuration, OneDrive Known Folder Move for user data, Microsoft 365/Edge synchronization for cloud-backed settings, and either USMT or a carefully tested profile-migration solution for settings that cannot otherwise be recreated is a much more practical approach.

If your goal is to eliminate the domain controllers entirely, I would also migrate the devices and identities in stages rather than attempting to make the AD-to-Entra transition and the workstation rebuild happen simultaneously. Get the Entra-only device management, application deployment, OneDrive, Microsoft 365 authentication, Windows Hello for Business, and required access to on-premises resources working first. Then migrate groups of users while the existing AD environment remains available as a fallback. Once the workstation population and dependent applications have been successfully transitioned, you can proceed toward retiring AD DS.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin