How to Convert Hybrid Users to Entra ID Cloud Only (Without Recreating Them)

By David, 2026-11-09

Most organizations that started on-premises still run hybrid identity: users are created in Active Directory, and Entra Connect copies them to Entra ID. That made sense when everything people used lived on-premises. Today it often means every name change, manager update or account disable has to happen on a domain controller, even when the user never touches anything on-premises again.

Microsoft now lets you move a synced user's source of authority from Active Directory to Entra ID, one user at a time, without deleting or recreating anything. This guide explains what the switch changes, what to check first, how to do it with Microsoft Graph or PowerShell, how to do it in Atlas AVD, and how to undo it.

The short version: Setting isCloudManaged to true on a synced user's onPremisesSyncBehavior moves that user's source of authority to Entra ID. The user keeps their account, licenses, mailbox, group memberships and MFA methods, and Active Directory stops updating them. The AD account isn't deleted. You need Entra Connect Sync 2.5.76.0 or later (or the Cloud Sync agent 1.1.1370.0 or later), and users on a federated (AD FS) domain can't be moved. Move on-premises Exchange mailboxes and any HR provisioning off AD first, and pilot with a few users before converting a department. In Atlas AVD, filter the User Directory to Hybrid (synced), select the users and choose Convert to Entra ID cloud only.

A note on wording: people often search for "convert hybrid users to Entra ID joined". Entra ID joined describes devices, not users. Moving devices from hybrid join to Entra join is a separate project. This guide covers users: making a synced user cloud only.

1. What "hybrid" means for a user

A hybrid (synced) user is created and owned by Active Directory. Entra Connect Sync or Cloud Sync copies the account to Entra ID, so the cloud copy is read-only for most attributes. Change a user's department in Entra ID and the next sync puts the AD value back.

A cloud-only user is created and owned by Entra ID. You manage it in the Entra admin center, Microsoft Graph or a tool like Atlas AVD, and nothing on-premises overwrites it.

Until recently the only way from one to the other was to stop syncing the user, which soft-deleted them in Entra ID. You then restored the account from the recycle bin and hoped nothing broke on the way. The source-of-authority switch replaces that with a single property change on the user.

2. What changes and what stays

When you move a user's source of authority to the cloud:

• Kept: the user object and its object ID, licenses, the Exchange Online mailbox, group memberships, MFA and passwordless methods, app assignments and sign-in history.
• Changed: Entra Connect stops writing to the user. You now edit the user in Entra ID.
• Not deleted: the AD account stays where it is. Entra Connect leaves it alone, and you decide when to disable or remove it.
• Password: with password hash sync on, the user's last synced password keeps working in the cloud. Later password changes made in AD no longer reach the cloud.

You can see the switch on the user object in Microsoft Graph:

Microsoft Entra records each switch in its audit log under the activity Change Source of Authority from AD to cloud, and an undo as Undo changes to Source of Authority from AD DS to cloud.

3. Before you convert anyone

Work through this list before you move a single user. Each item is a reason a conversion can go wrong after the fact.

1. Sync client version. Entra Connect Sync 2.5.76.0 or later, or the Cloud Sync provisioning agent 1.1.1370.0 or later. Older clients don't honour the switch.
2. No federated sign-in. Users whose sign-in domain is federated with AD FS aren't supported. Convert the domain to managed authentication (password hash sync or pass-through authentication) first.
3. Password plan. With password hash sync on, users keep signing in with their current password. With pass-through authentication only, a converted user has no cloud password: set one, or issue a Temporary Access Pass, straight after the switch.
4. Exchange. If the user still has an on-premises Exchange mailbox, move it to Exchange Online first. Once AD stops updating the user, Exchange attributes you set on-premises no longer reach the cloud.
5. Provisioning. Stop HR-driven or scripted provisioning that writes the user in AD, and move it to Entra ID (for example, API-driven inbound provisioning). Otherwise those updates quietly stop arriving.
6. On-premises apps. Apps that authenticate users with an LDAP bind or with password-based Kerberos against AD still check the AD account, whose password no longer keeps in step with the cloud. Find those apps before you convert their users.
7. Permissions. To make the change through Microsoft Graph, an app needs User-OnPremisesSyncBehavior.ReadWrite.All. A person needs at least the Hybrid Administrator role.

Pilot with two or three users who are representative of a department, check their sign-in, mail, Teams and desktop for a day, then convert the rest in batches.

4. Doing it with Microsoft Graph or PowerShell

The switch is a single PATCH per user:

PATCH https://graph.microsoft.com/v1.0/users/{user-id}/onPremisesSyncBehavior
Content-Type: application/json

{ "isCloudManaged": true }

With the Microsoft Graph PowerShell SDK:

Connect-MgGraph -Scopes "User-OnPremisesSyncBehavior.ReadWrite.All"

Update-MgUserOnPremiseSyncBehavior -UserId "riley@contoso.com" -BodyParameter @{ isCloudManaged = $true }

# Confirm the switch took
Invoke-MgGraphRequest -Method GET "v1.0/users/riley@contoso.com/onPremisesSyncBehavior"

For a batch, loop over a CSV of UPNs and log each result. Remember that the checks in section 3 are yours to make: Graph accepts the switch for a user whose mailbox is still on-premises or whose apps still bind to AD.

5. Doing it in Atlas AVD

Atlas AVD puts the same switch in the User Directory (Microsoft 365 → User Directory), next to the users you already manage there, and does the tenant checks for you.

Find your hybrid users. The directory's Source column shows where each user is managed: Hybrid (synced), Entra ID (created in the cloud), or Entra ID (converted from AD). Pick Hybrid (synced) from the source filter, or the quick chip, to list only synced users.

Convert a pilot group. Tick the users and choose Convert to Entra ID cloud only. For one user, the same action is in the row's actions menu. Before anything changes, the dialog checks your tenant and tells you what applies to it:

• whether password hash sync is on, and what that means for each user's password;
• that on-premises Exchange mailboxes and AD provisioning have to move first;
• the minimum Entra Connect Sync and Cloud Sync versions.

Users on a federated (AD FS) domain are refused rather than half-converted, and the action isn't offered for them. Tick I understand Active Directory will stop updating these users. and choose Convert to cloud only. Atlas reports each user's result (for example "3 of 3 done"), and their Source badge changes to Entra ID (converted from AD).

Who can do it. Atlas needs the User-OnPremisesSyncBehavior.ReadWrite.All application permission on its app registration, with admin consent. Inside Atlas, the action is limited to roles that can manage users' source of authority, and every conversion is written to the Atlas audit trail with who made it and for which users.

6. Rolling back

A conversion can be undone, but the undo takes more steps than the switch did, which is one more reason to pilot first.

In Microsoft Entra, Microsoft's documented rollback is:

1. Remove the user from any groups whose source of authority you also moved to the cloud, and remove those groups from access packages.
2. Set isCloudManaged back to false on the user's onPremisesSyncBehavior.
3. Allow the sync client to take the user back. By default Entra blocks a synced object from taking over a cloud-managed one by hard match, so turn that block off for the tenant:

PATCH https://graph.microsoft.com/beta/directory/onPremisesSynchronization/{tenant-id}
Content-Type: application/json

{ "features": { "blockCloudObjectTakeoverThroughHardMatchEnabled": false } }

4. Run a sync cycle on the Entra Connect server: Start-ADSyncSyncCycle.
5. Once the user shows as synced again, turn blockCloudObjectTakeoverThroughHardMatchEnabled back on.

When AD takes the user back, AD values overwrite anything you changed in the cloud in the meantime.

In Atlas AVD, a converted user's actions menu offers Hand back to AD. Atlas sets isCloudManaged back to false, reminds you about the group and sync steps, and shows the user as Waiting for AD sync until Entra Connect picks them up. The hard-match block in step 3 is a tenant-wide setting, so Atlas leaves it to you: follow Microsoft's rollback steps for it, and turn it back on afterwards.

7. A note for Azure Virtual Desktop

Converting a user doesn't change their desktop assignment: application group assignments, Conditional Access policies and licenses all follow the same user object. Two things are worth testing with your pilot users before converting a whole host pool's worth:

• Session hosts joined to Active Directory. Users sign in to an AD DS-joined host with their AD account. After the switch that account's password no longer keeps in step with the cloud, so the two passwords can drift. Entra-joined session hosts avoid the problem, because sign-in uses the cloud identity.
• FSLogix profiles on Azure Files. Share access is granted to the user's identity. Sign a converted pilot user in and confirm their profile container mounts before you convert the rest of the pool.

Sources

Checked as of November 2026. Microsoft updates these pages as the feature evolves, so re-check the version numbers and prerequisites before a large rollout.

• Microsoft Learn: Configure user source of authority
• Microsoft Learn: User source of authority overview