Microsoft Entra Cloud Sync vs Connect Sync: choosing the right tool and migrating safely

Microsoft calls Cloud Sync its strategic direction for hybrid identity, and new synchronization features land there first. That doesn't mean every Connect Sync server should be switched off tomorrow: some scenarios still need the classic engine. In this post I'll compare the two architectures, reproduce Microsoft's feature comparison, give you a decision checklist, and walk through the documented pilot-OU migration, including the coexistence rules that changed in 2026.

How it works#

Connect Sync is a full application on a Windows Server you own: a sync engine with its own database, connectors to each forest and to Entra ID, a scheduler running a delta sync every 30 minutes, and a Synchronization Rules Editor for shaping attribute flows in detail. Configuration lives on that server, high availability means a second server in staging mode, and it's a single point of failure while you patch it.

Cloud Sync moves the orchestration into the Microsoft Entra provisioning service. On-premises you install the lightweight provisioning agent (the same technology as Application Proxy and pass-through authentication) on a domain-joined server or a domain controller. The agent keeps an outbound connection through Azure Service Bus, receives SCIM requests from the cloud, reads Active Directory, applies the scoping and attribute mappings you configured in the admin center, and returns the results. Synchronization runs every two minutes, configuration lives in Entra ID, agents update themselves, and several active agents give you failover without configuration. Microsoft recommends three agents, Windows Server 2022 or 2025, 4 GB of RAM, .NET Framework 4.7.1 and TLS 1.2; Server Core isn't supported. The agent runs as a group managed service account (provAgentgMSA$ by default) and the schema must contain msDS-ExternalDirectoryObjectId, present from Windows Server 2016.

Feature comparison#

This table follows Microsoft's published comparison; check the live version before deciding, because Cloud Sync gains capabilities regularly.

When to pick which#

Microsoft's readiness guidance maps onto three groups:

• Migrate now: fewer than 150,000 objects per domain, no group above 50,000 members, OU-based filtering, password hash sync (or PTA and federation you're happy to manage outside the sync wizard), and no dependency on hybrid join device sync, or a willingness to move Windows Hello to cloud Kerberos trust. Most mid-sized tenants fit here.
• Plan for later: you rely on hybrid join device synchronization or on attribute-based filtering beyond the expression builder. Watch the feature announcements and prepare the pilot anyway.
• Stay on Connect Sync for now: very large domains, complex custom sync rules, cross-forest references or a hard requirement for reconciliation. Consider migrating domain by domain or OU by OU.

Mergers are the special case: Cloud Sync is the only supported way to bring a disconnected forest into the same tenant without trusts or a second sync server.

Step-by-step: pilot migration from Connect Sync#

This is the documented path for a forest Connect Sync already synchronizes. It assumes Connect Sync 1.4.32.0 or later with objectGUID or ms-ds-consistencyGUID as the source anchor, and that pilot objects have ms-ds-consistencyGUID populated so Cloud Sync hard-matches them. Connect Sync doesn't populate it for groups by default, so check that first.

1. Back up the Connect Sync configuration (export settings) and pick or create a pilot OU with a handful of users. Count them:
   PowerShell

   Get-ADUser -Filter * -SearchBase "OU=CloudSyncPilot,OU=Users,DC=contoso,DC=com" | Measure-Object

2. Stop the scheduler on the Connect Sync server:
   PowerShell

   Stop-ADSyncSyncCycle
   Set-ADSyncScheduler -SyncCycleEnabled $false

3. Create the no-flow rules in the Synchronization Rules Editor. First an inbound rule for the Active Directory connector (object type user, metaverse person, link type Join, unique precedence) with a scoping filter DN ENDSWITH the pilot OU's distinguished name and a constant transformation setting cloudNoFlow to True. Then an outbound rule for the Entra ID connector with link type JoinNoFlow and the scoping filter cloudNoFlow EQUAL True. Repeat both for group and contact object types. Together they stop Connect Sync exporting adds, deletes and ordinary attribute updates for the scoped objects while still resolving references such as member and manager.
4. Install the provisioning agent from Entra ID › Entra Connect › Cloud sync › Agents › Download on-premises agent, run AADConnectProvisioningAgentSetup.exe, sign in as a Hybrid Identity Administrator, let it create the gMSA, add the domain and confirm. The agent should show as active in the portal, with the Microsoft Azure AD Connect Provisioning Agent and Agent Updater services running.
5. Create the Cloud Sync configuration: Cloud sync › New configuration, select the domain, decide on password hash sync, then under Scoping filters choose Selected organizational units and add the pilot OU. Try Provision on demand on one pilot user before enabling the configuration.
6. Restart the scheduler with Set-ADSyncScheduler -SyncCycleEnabled $true and Start-ADSyncSyncCycle. Verify the pilot users are now provisioned by Cloud Sync, then create a new user in the OU and confirm it appears.
7. Repeat per batch until everything is on Cloud Sync, then stop Connect Sync for the migrated scope, leave the server disabled for a while, and finally uninstall it.

Coexistence rules#

• Keep both sides of a reference in Connect Sync scope while the no-flow rules are active: if a group stays on Connect Sync and its members move to Cloud Sync, keep both in scope.
• Remove a domain from Connect Sync only after migration for that whole domain is complete and no cross-domain references remain.
• The two tools can also run permanently side by side at the domain level, for example Connect Sync for the main forest and Cloud Sync for an acquired disconnected forest, as long as no object is in scope of both.
• If memberships or manager links disappear, re-add the affected objects to Connect Sync scope and run a full synchronization to rebuild the references.

Verify#

• The Cloud Sync configuration shows Healthy, and the provisioning logs under Entra ID › Monitoring & health › Provisioning logs list the pilot users with successful create or update actions.
• Counts match: the on-premises OU count equals the number of synced users whose onPremisesDistinguishedName ends with the OU. Microsoft's sample script does this with Get-EntraUser -All -Filter "DirSyncEnabled eq true" and a match on the DN.
• Group memberships and manager attributes of pilot users are unchanged in Entra ID.
• An on-premises password change reaches the cloud within minutes if password hash sync is enabled.

Tips & gotchas#

• A scoping configuration is limited to about 4 MB of text, roughly 50 separate OUs or groups. Nested OUs are fine; a long flat list isn't.
• Renaming an in-scope OU or group isn't recognised by the Cloud Sync job, and deleting a scoping group doesn't delete its members' cloud accounts.
• Create a cloud-only Hybrid Identity Administrator first, so a sync problem can't lock you out of your own configuration.
• Treat the agent server as a Tier 0 asset: it can reset passwords in Entra ID, so harden it, block NTLM and keep MFA on every privileged account.

References#

• Migrate from Microsoft Entra Connect to Cloud Sync: Decision Guide
• Tutorial: Migrate to Microsoft Entra Cloud Sync for a synced Active Directory forest
• Prerequisites for Microsoft Entra Cloud Sync