Microsoft Entra: convert synced users to cloud-managed

Key insights

• A synchronized user's source of authority determines where the account's properties can be edited.
• The demonstrated change sets isCloudManaged to true on the user's onPremisesSyncBehavior resource.
• The walkthrough checks the user's current status before issuing a PATCH request.
• The presenter recommends moving groups first and testing outside live infrastructure.
• The material does not establish the required licensing or general rollout availability.

Microsoft Entra ID lets administrators convert an eligible synchronized user to a cloud-managed identity by changing the user's source of authority, making the account editable in the cloud. The task matters to identity administrators preparing a staged move away from on-premises Active Directory, not to every hybrid organization by default. Andy Malone [MVP] demonstrates the change with Microsoft Graph Explorer and describes prerequisites for moving users safely.

What's new

In a hybrid setup, a user's source of authority (SOA) identifies the system that controls the account. In the example described, a synchronized user's properties are controlled by Active Directory, so the administrator cannot edit them in Microsoft Entra ID. The demonstrated SOA change switches a selected user to cloud-managed status.

This is an object-level operation: the walkthrough selects an individual user rather than converting every synchronized account at once. After the change, the presenter refreshes the user's page in the Entra admin center and shows that the properties can be edited. This is useful for a phased transition, but it does not by itself remove all dependencies on on-premises AD.

The technical method uses Microsoft Graph. The walkthrough reads the user's resource and then sends a PATCH request with set to . That setting expresses the requested change; admins should verify the resulting user state rather than treating a successful request alone as proof that their broader environment is ready.

Who it is for and what you need

This is an identity-administration task for organizations with synchronized users moving toward cloud-managed identity. The video recommends signing in to Graph Explorer with an administrator account, preferring a Hybrid Identity Administrator role over Global Administrator for the operation. It also recommends using Privileged Identity Management to limit privileged access when performing the change.

Graph Explorer requires consent to the relevant permissions. The demonstration refers to the permission, while its Graph Explorer overview recommends requesting only necessary scopes instead of broad directory write permissions by default. The supplied material does not specify a licensing prerequisite, a tenant-wide availability status, or a general rollout schedule.

Readiness is the larger prerequisite. The presenter says groups should be moved first and warns against trying the process on live infrastructure without preparation. He describes cloud authentication, Password Hash Sync, and Conditional Access-enforced multifactor authentication as part of the desired setup. He also says on-premises Exchange mailboxes should be absent and applications should not rely on AD protocols such as Kerberos.

He further calls for group SOA migration and devices managed through Entra or Intune. These are recommendations in the walkthrough, not a complete Microsoft readiness checklist. Assess actual application, device and operational dependencies before selecting users; the material does not provide a formal eligibility test.

How it works

Use Graph Explorer to inspect and change the selected user's synchronization behavior. The presenter demonstrates the interface; the transcript also includes an equivalent PowerShell example. Treat the following as a process outline and test it in a controlled setting before applying it to production accounts.

1. Sign in to Graph Explorer with an appropriate administrator account, then grant consent for the permission needed to read and change the user's on-premises synchronization behavior.
2. Identify the target user and copy the user's object ID. Send a GET request to the user's resource, selecting to check the current state.
3. Review the result before proceeding. In the demonstrated case the value is , consistent with the user's properties still being controlled by synchronization.
4. Send a PATCH request to the same resource with a request body setting to . The video uses Graph Explorer and selects the beta option for its demonstration; the transcript's example code also shows a v1.0 URI, so confirm the endpoint and applicable API guidance before use.
5. Check the response, query the resource again, and inspect the account in the Entra admin center. The demonstrated verification is that the user can now have properties edited there.

The transcript also includes a PowerShell example that reads the user and checks and , then queries the resource after the change. It says the ImmutableId is retained, but does not give a complete rollback procedure. Do not assume that retained data alone is a tested recovery plan.

Limitations and open questions

The change addresses ownership of a user object; it does not migrate applications, devices, groups, mailboxes, or other infrastructure by itself. The presenter frames user conversion as one part of a broader transition and places group migration first. A successful change therefore should not be read as evidence that the organization can retire its domain controllers or synchronization components.

The source material does not specify licensing, tenant or regional eligibility, a supported scale, or a detailed recovery process. It also does not provide a formal, exhaustive prerequisite list. Confirm current Microsoft guidance and validate permissions and API behavior in a test environment before planning a production migration.

The supplied Microsoft documentation link is about configuring group source of authority, not a dedicated user-conversion procedure. It provides related context but does not independently verify the user steps in the demonstration. For administrators, the main practical takeaway is to treat this as a carefully staged identity change, with dependency checks and explicit verification for each account.

Sources

• Microsoft Learn: Configure group source of authority
• Andy Malone [MVP]: Migrating Users From Hybrid AD to Microsoft Entra Cloud Native

Frequently asked questions

How do I make a synchronized user cloud-managed in Microsoft Entra?

The demonstrated method uses Microsoft Graph to PATCH the user's onPremisesSyncBehavior resource with isCloudManaged set to true. Check the user's current state and verify the result afterward.

Which permission and administrator role are needed?

The walkthrough refers to the User-OnPremisesSyncBehavior permission and recommends an administrator account, preferably Hybrid Identity Administrator rather than Global Administrator. It does not provide a full permissions or licensing matrix.

Can I convert users before migrating groups?

The presenter recommends moving groups first. The material does not establish that this is a universal technical enforcement rule, but it presents group migration as part of preparation.

Does converting a user retire on-premises Active Directory?

No. The change affects the selected user's source of authority. Applications, devices, groups, Exchange dependencies, and other infrastructure may still rely on on-premises AD.