When Connect Sync Still Wins

Microsoft positions Cloud Sync as the strategic replacement for Connect Sync, and for many organizations the migration is straightforward. But Cloud Sync does not yet have full parity. This page documents the specific scenarios where Connect Sync is still the right tool, so you can make an honest assessment rather than relying on marketing summaries.

This page will need updates as Cloud Sync closes parity gaps. Check the Microsoft feature comparison for the latest status.

Feature Gaps Where Connect Sync Is Required

Device Writeback

Cloud Sync does not support writing device objects back from Entra ID to on-premises AD. If you use Conditional Access policies that depend on hybrid-joined device state, or if you need device objects in on-premises AD for other purposes, Connect Sync is required.

Exchange Hybrid Writeback

Coexistence between Exchange Online and on-premises Exchange requires writing specific Exchange attributes back to AD (mail, proxyAddresses, msExchRecipientTypeDetails, and others). Cloud Sync does not perform this writeback. If you run Exchange hybrid, you need Connect Sync.

Group Writeback

Writing Microsoft 365 groups back to on-premises AD as distribution groups or security groups requires Connect Sync’s group writeback feature. Cloud Sync does not support this.

Complex Multi-Forest Topologies

Cloud Sync handles basic multi-forest scenarios, but advanced cases hit limitations:

Account-resource forest topologies with Exchange resources in a separate forest.
Full mesh forests with GALSync where identity matching uses objectSID or msExchMasterAccountSID.
Topologies requiring custom join rules across forests.

If your multi-forest environment needs anything beyond simple user consolidation by mail attribute, evaluate carefully whether Cloud Sync supports your specific matching requirements.

Custom Sync Rules and Expressions

Connect Sync’s declarative provisioning engine supports a full expression language, custom attribute flows, arbitrary scoping filters, and precedence-based rule ordering. Cloud Sync’s attribute mapping and scoping filter capabilities are more limited.

If you depend on custom sync rules - for example, transforming attributes with complex expressions, merging multi-valued attributes from multiple sources, or implementing custom provisioning logic - Connect Sync gives you the control you need.

For details on the expression systems, see the sync rules deep dive. Cloud Sync’s expression builder is covered in Cloud Sync expression language.

Password Writeback with PTA

Both Cloud Sync and Connect Sync support password writeback. However, if you combine password writeback with pass-through authentication agents on the same server, that deployment path currently requires Connect Sync.

Directory Extensions

Syncing custom AD attributes to Entra ID via directory extensions is a Connect Sync feature. Cloud Sync has limited support for extension attributes. If you rely on custom directory extensions, verify Cloud Sync covers your specific attributes before migrating.

When Cloud Sync Is the Better Fit

For balance, here are scenarios where Cloud Sync is preferable:

Simple single-forest or multi-forest topologies with straightforward user/group sync.
Environments that prioritize lightweight agents over managing a dedicated sync server.
Disconnected forest topologies where Cloud Sync’s per-agent-per-forest model simplifies deployment.
Organizations wanting automatic agent updates and cloud-managed configuration.

See the Cloud Sync topic for a full treatment.

The Deprecation Trajectory

Microsoft has stated that Cloud Sync will eventually replace Connect Sync entirely. The timeline depends on Cloud Sync achieving full feature parity, which is progressing but not yet complete.

What this means for operators:

New deployments should evaluate Cloud Sync first. Only fall back to Connect Sync if you need a feature Cloud Sync does not support.
Existing Connect Sync deployments can continue running. Microsoft has not announced an end-of-support date contingent on Cloud Sync parity.
Migration tooling exists for moving from Connect Sync to Cloud Sync. Microsoft provides a migration guide that handles the switchover for supported scenarios.
Hybrid coexistence (running both Connect Sync and Cloud Sync) is supported for phased migrations, with specific constraints on which engine manages which objects.

Decision Framework

Requirement	Connect Sync	Cloud Sync
Basic user/group sync (single forest)	Yes	Yes
Multi-forest (simple matching)	Yes	Yes
Multi-forest (account-resource, GALSync)	Yes	Limited
Device writeback	Yes	No
Exchange hybrid writeback	Yes	No
Group writeback	Yes	No
Custom sync rules	Yes	Limited
Directory extensions	Yes	Limited
Automatic agent updates	No	Yes
Cloud-managed configuration	No	Yes
No on-premises server required	No	Yes (agent only)

If your requirements fall entirely in the “Yes/Yes” rows, Cloud Sync is likely the better path. If you need anything in the “Yes/No” or “Yes/Limited” rows, Connect Sync is your tool until Cloud Sync catches up.