Choosing between Microsoft Entra Connect Sync and Cloud Sync

The names invite the assumption that Cloud Sync is simply the modern replacement for Connect Sync, and that the decision is about how current you want to be. It is not. They are different architectures with different capability sets, and Connect Sync can still do things Cloud Sync cannot.

The right question is not “which is newer” but “does my environment need anything only Connect Sync provides”.

The problem

You are either deploying hybrid identity for the first time or considering moving an existing deployment. Both engines synchronise users, groups and contacts from Active Directory to Microsoft Entra ID. Both support password hash synchronisation, password writeback and device writeback scenarios to varying degrees. The differences are in where the logic runs, what transformations are possible, and which topologies are supported.

Design choice one: where the configuration lives

Connect Sync runs a full synchronisation engine on a server you own. It holds a local SQL database — LocalDB by default, or a full SQL Server instance for larger directories — containing the metaverse and connector spaces. Configuration lives on that server as synchronisation rules.

The consequence is power and responsibility in equal measure. You can express almost any transformation, and you own a stateful server that must be patched, backed up and recovered. Losing it without a staging server means rebuilding and re-establishing the sync relationship.

Cloud Sync moves the provisioning logic into Microsoft Entra ID. What you run on premises is a lightweight provisioning agent with no database and no configuration. The agent makes outbound connections only; the configuration and the transformation logic are in the cloud.

The consequence is a much smaller operational footprint and a much narrower transformation capability.

Design choice two: resilience

This is the difference I would weigh most heavily for a mid-sized environment.

Connect Sync is active on one server at a time. A second server in staging mode holds a current copy and can be promoted, but promotion is a manual operation and the staging server must be maintained. Many organisations never build one, which leaves directory synchronisation as a single point of failure sitting on a server nobody has patched since the deployment.

Cloud Sync supports multiple active agents across different servers. If one becomes unavailable the others continue, and there is no failover step to perform or rehearse. For an organisation without the appetite to maintain a staging server, that difference alone can decide it.

Design choice three: what you can transform

This is where Cloud Sync’s limits bite, and where most “we cannot move” answers come from.

Connect Sync gives you declarative provisioning: custom synchronisation rules, arbitrary attribute flows, expression-based transformations, attribute-based filtering, and the ability to join objects across forests on attributes you choose.

Cloud Sync gives you attribute mapping and expressions, scoping by organisational unit or security group, and per-forest configuration. What it does not give you is the complex cross-forest object relationships Connect Sync can express. In a multi-forest Cloud Sync deployment, references such as manager must resolve within the domain — you cannot join a user in one forest to a manager in another.

Two further limits are worth knowing before you commit:

• Group membership synchronised through organisational-unit scope filtering is supported up to 50,000 members.
• When scoping by security group, nested objects beyond the first level are not included. A group of groups will not expand the way people assume.

Design choice four: topology

Both support multiple forests and a single tenant, which is the common enterprise case.

Cloud Sync’s multi-forest support covers disconnected forests — forests with no trust between them — which is genuinely useful after an acquisition, and it does so by deploying agents in each. Connect Sync also handles multiple forests but expresses the joins in its own rules.

Neither supports multiple tenants from one directory object. And Cloud Sync is not supported over NAT, because it depends on Active Directory, which does not support it.

The decision, stated plainly

Choose Cloud Sync when:

• Your transformations are attribute mappings and organisational-unit scoping.
• You have a single forest, or multiple forests without cross-forest object relationships.
• You want multiple active agents rather than a staging server you must maintain.
• You would rather not own a stateful synchronisation server at all.

Choose Connect Sync when:

• You need custom synchronisation rules or complex attribute-based filtering.
• You have cross-forest object joins — the classic case being a resource forest with an Exchange organisation and account forests elsewhere.
• You depend on a Connect Sync feature that has no Cloud Sync equivalent in your scenario.

Microsoft publishes a decision guide that evaluates this against your actual configuration, and it is worth running rather than reasoning from a feature table. Capability moves, and a comparison written today ages.

Trade-offs worth being explicit about

Cloud Sync trades expressiveness for operational simplicity. That is a good trade for most organisations and a bad one for a few. The bad case is usually a resource forest topology or a directory carrying two decades of custom rules that encode business logic nobody has written down.

Connect Sync trades operational burden for capability you may not use. I have reviewed several deployments running Connect Sync with entirely default rules, on an unpatched server, with no staging server. That is the worst of both: the operational burden without the capability.

“Which is newer” is the wrong axis, but “which is being invested in” is not. Cloud Sync is where Microsoft’s development is going. If your requirements fit it, it is the direction of travel.

Implementation considerations

Audit your existing rules before assuming you need them. Export the synchronisation rules from a Connect Sync deployment and check which are custom. Many organisations find the custom rules are one or two attribute flows that Cloud Sync’s expressions handle.

Migration is supported, and it is a project. Moving from Connect Sync to Cloud Sync is a defined path rather than a reinstall, but treat it as a change with a pilot scope and a rollback plan. Microsoft’s guidance identifies the conditions under which an immediate migration is reasonable — broadly, fewer than 150,000 objects per domain, organisational-unit filtering rather than complex attribute rules, and no disconnected-forest requirement you cannot meet.

Both engines can run side by side during a migration, with distinct scopes. Overlapping scope is where damage occurs, so define the boundary carefully and verify it before enabling.

The deletion threshold and scoping cautions apply to both. Everything in hybrid identity failure modes about objects leaving the sync scope is engine-independent.

Whichever you choose, the provisioning server is a Tier 0 system. It holds credentials that can write to your tenant and read your directory, and it belongs inside the boundary described in administrative tiering. This is as true of a lightweight Cloud Sync agent as of a full Connect Sync server.

Before you decide anything

Run the assessment in your own environment rather than from this article. Specifically: count objects per domain, list your custom synchronisation rules, confirm your forest topology and any trusts, identify cross-forest references, and establish which authentication method you use. Those five facts determine the answer, and four of them take an afternoon to collect.

Verification and limits

Architectural differences, Cloud Sync’s group-member and nesting limits, multi-forest and disconnected-forest support, NAT non-support, agent resilience and the migration conditions were checked against current Microsoft documentation on 20 September 2026.

No deployment or migration was performed in a lab for this article. Both engines’ supported scenarios change as Cloud Sync gains capability, so confirm against the decision guide and current documentation at the time you decide rather than relying on this comparison. Running two engines with overlapping scope will produce conflicting writes; define and verify the boundary before enabling the second.

References

• What is Microsoft Entra Cloud Sync?
• Migrate from Microsoft Entra Connect to Cloud Sync: decision guide
• Microsoft Entra Cloud Sync supported topologies and scenarios
• Microsoft Entra Cloud Sync FAQ