Forum Discussion
Migration from Microsoft Entra Connect Sync to Entra Cloud Sync
Hello,
I am migrating my organization from Microsoft Entra Connect Sync to Microsoft Entra Cloud Sync, from On-Premise AD to Microsoft Entra ID only.
I divided the migration (change) into phases, created roles for all synchronized OUs separately, according to this tutorial (https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/tutorial-pilot-aadc-aadccp), everything was going well until I discovered that if the users OU is synced with connect sync and the mail groups OU - with cloud sync, the cloud sync cannot perceive the changes coming from on-premise and, for example, cannot join a specific group to a user who is in one of the groups in on-premise AD. I have licensing groups that automatically assign the appropriate license to a user when they are in this group in Entra. Is there any solution that I can use to avoid or avoid all this? Or do I have to synchronize all OUs at once? Has anyone had a similar incident?
Thanks, I will accept any advice.
3 Replies
Hi, Surya_Narayana
Thank you very much for the comprehensive answer.
Yes, that's exactly how I'm going to migrate, I'll migrate all OUs at once, I'll write rules for all OUs so that delete operations are not sent from the metaverse to the cloud from connect sync, and I'll include the configuration in cloud sync. Should I manually disable the OUs in connect sync or move them directly to staging mode and migrate them that way?
What do you recommend?
hi Ivane99 It’s best not to manually disable the OUs right away. Instead, follow a phased approach using staging mode first:
Set up Cloud Sync in staging mode.
This lets you safely test synchronization — it reads your data but doesn’t export changes to Entra ID.
Validate everything.
Check that your users, groups, and attribute flows look correct in staging mode.
Uncheck those OUs in Connect Sync.
Once validated, disable those OUs in your existing Entra Connect configuration to avoid duplicate sync.
Turn off staging mode.
Cloud Sync will then start syncing those OUs for real.
This method avoids accidental deletions and ensures a smooth handoff between sync engines.
Also refer the site:
https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/tutorial-pilot-aadc-aadccp
hi Ivane99 here are few recommendation you should try - yes, what you’re observing is a known behavior when running Microsoft Entra Connect Sync and Cloud Sync in parallel for different organizational units (OUs). Each synchronization method maintains its own connector space and object anchoring, so dependencies (like group memberships or user-linking between sync types) aren’t shared across the two sync engines.
In your case, since users are synced by Entra Connect Sync and mail groups by Cloud Sync, the Cloud Sync agent doesn’t have visibility into the user objects managed by Connect Sync — which is why it can’t process group memberships or update Entra ID accordingly.
A few recommendations to help you move forward:
Plan a full cutover per OU type (users, groups, etc.)
Avoid splitting dependent OUs between the two sync methods. When possible, migrate all related objects (users, groups, and memberships) together under a single synchronization type — ideally Cloud Sync if that’s your long-term goal.
Use staged migration
You can follow Microsoft’s documented staged approach to transition from Entra Connect to Cloud Sync. It allows gradual migration by disabling sync on the Connect side once the Cloud Sync agent fully manages that OU.
Plan a migration to Microsoft Entra Cloud Sync
Verify attribute flows
Ensure attributes like memberOf and objectGUID are correctly populated and that your Cloud Sync agent is configured with the proper scope filters and join rules.
Licensing and group-based access
Since you’re using dynamic or license assignment groups, confirm those group memberships resolve correctly once objects are fully synced by the same engine.
You don’t necessarily need to sync all OUs at once, but for objects that depend on each other (like users and groups), they should be moved together to the same sync method to maintain relationship integrity.
Hope that clarifies the behavior — you’re definitely on the right track, and once all dependent OUs are migrated to Cloud Sync, the issue should resolve itself.
