What are some Common issues after converting On Premise Users to the cloud?

Question

My team converted a few users to the cloud by changing their OU's, removing them from sync and restoring users from deleted items to make them cloud managed-After the conversion we observed the following

1. Users who are members of a private channels lost access, and they were not auto added
2. Users with assigned team phone numbers lost access to their numbers
3. Users with VDI access in Azure lost access and we have to re-create new profiles for them

I know we have the option of permanently disabling the sync to make all users cloud only but we wanted to access the impact first

Does it make any difference if we decide to permanently disable the sync? Is the behavior the same as compared to migrating individual users by removing them from a sync OU

Your feedback is appreciated

Thanks

Answer 1

When you remove a user from Entra Connect Sync scope by changing their OU and letting the sync engine process the deletion, Entra ID treats that as a hard delete of the synced object. When you later restore the user from Deleted Users, you are not “converting” the original object. You are creating a new cloud-only object with a new Entra ObjectId. Even if the UPN, SMTP address, and display name are identical, it is a different identity internally.

That is why you are seeing private channel access loss, Teams phone number removal, Azure Virtual Desktop access issues, and profile recreation. All of those workloads bind to the Entra ObjectId, not the UPN. When the ObjectId changes, permissions, role assignments, and workload bindings that referenced the original object no longer apply.

If instead you permanently disable Entra Connect Sync at the tenant level, the behavior is different. When you turn off directory synchronization globally, existing synced users are converted in place from “synced” to “cloud-managed.” The objects are not deleted and recreated. Their Entra ObjectId remains the same. Because the identity object is preserved, private channel membership, Teams voice assignments, RBAC role assignments, AVD access, and other bindings remain intact.

So the technical difference is this: removing users from sync scope causes object deletion and recreation, resulting in a new ObjectId. Disabling Entra Connect Sync tenant-wide changes the source-of-authority flag but preserves the same object and ObjectId.

If your long-term goal is to be fully cloud-managed, tenant-wide sync disablement is significantly less disruptive than converting users individually by OU removal. The per-user removal method will consistently produce the identity break you are observing because each user effectively becomes a new Entra object.

Before disabling sync, you should confirm that no attributes still require on-premises authority, such as Exchange hybrid attributes, msDS consistency requirements, or applications depending on on-prem AD. But strictly from an identity continuity standpoint in Entra ID and Microsoft 365 workloads, disabling Entra Connect Sync globally preserves identity integrity, while per-user descope and restore does not.

---

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