Connect Sync vs Cloud Sync
This page helps you decide which sync engine to use: Connect Sync or Cloud Sync. The short answer is that Cloud Sync is the default for new deployments and most migrations, but Connect Sync is still required for specific advanced scenarios. The longer answer depends on your environment.
For architecture details on each engine, see Cloud Sync architecture and Connect Sync architecture.
When Cloud Sync Is the Right Default
Cloud Sync should be your starting point for new hybrid identity deployments. It is the right choice when:
- You have a single-forest or multi-forest topology with straightforward user/group sync.
- You want lightweight agents instead of managing a dedicated sync server.
- You have disconnected forests (mergers, acquisitions, isolated environments).
- You want automatic agent updates and cloud-managed configuration.
- You need group provisioning from Entra ID to Active Directory.
- Your environment has fewer than 150,000 objects per domain and groups under 50,000 members.
Cloud Sync is also Microsoft’s strategic platform. New features are being built exclusively on Cloud Sync, and Microsoft positions it as the eventual replacement for Connect Sync.
When Connect Sync Still Wins
Cloud Sync does not yet have full feature parity with Connect Sync. The following scenarios require Connect Sync:
| Scenario | Why Connect Sync |
|---|---|
| Device writeback (Hybrid Azure AD Join) | Cloud Sync does not support device objects. Microsoft recommends transitioning to Cloud Kerberos Trust as the modern alternative. |
| Advanced sync rules with precedence | Connect Sync’s declarative provisioning engine supports numbered precedence, complex expressions, and arbitrary scoping. Cloud Sync’s expression builder is simpler. |
| Cross-forest object references | Connect Sync can resolve references between forests. Cloud Sync cannot. |
| Attribute merging from multiple domains | Connect Sync can merge attributes from different AD sources into a single metaverse object. Cloud Sync has limited support (public preview). |
| Large-scale deployments | Over 150,000 objects per domain or groups over 50,000 members exceed Cloud Sync’s current limits. |
| Reconciliation and out-of-band correction | Connect Sync supports manual reconciliation workflows. Cloud Sync does not. |
| Pass-through authentication configuration | PTA agents can be configured through Connect Sync’s installer. With Cloud Sync, PTA must be managed separately. |
For a detailed breakdown of each gap, see When Connect Sync still wins.
Feature Comparison
| Feature | Connect Sync | Cloud Sync |
|---|---|---|
| Users, groups, contacts sync | Yes | Yes |
| Single forest | Yes | Yes |
| Multiple connected forests | Yes | Yes |
| Disconnected forests | No | Yes |
| Multiple active agents (HA) | No | Yes |
| Password hash sync | Yes | Yes |
| Password writeback | Yes | Yes |
| Exchange hybrid attributes | Yes | Yes |
| OU-based filtering | Yes | Yes |
| On-demand provisioning | No | Yes |
| Cloud-managed configuration | No | Yes |
| Automatic agent updates | No | Yes |
| Group provisioning to AD | No | Yes |
| Device sync / writeback | Yes | No |
| Advanced sync rules | Yes | No |
| Cross-forest references | Yes | No |
| Attribute merging (multi-domain) | Yes | Limited |
| Attribute-based filtering | Yes | Limited |
| Directory extensions | Yes | Yes |
| Scale per domain | Unlimited | 150K objects |
| Max group members | 250K | 50K |
Coexistence: Running Both Engines
Connect Sync and Cloud Sync can run side by side in the same AD forest. This is the recommended approach for phased migrations.
The key constraint: an object must be in scope for only one engine. If a user is synced by both Connect Sync and Cloud Sync, you get conflicts. Use OU-based scoping to draw a clean boundary:
- Identify OUs to migrate.
- Create sync rules in Connect Sync to exclude those OUs (using
cloudNoFlowinbound +JoinNoFlowoutbound rules). - Configure Cloud Sync scoped to those same OUs.
- Verify the pilot users sync correctly through Cloud Sync.
- Gradually move more OUs from Connect Sync to Cloud Sync.
See the migration quickstart for the full workflow.
Decision Flowchart
flowchart TD
A[New hybrid identity deployment?] -->|Yes| B{Any Connect Sync-only features needed?}
A -->|No, existing Connect Sync| C{Ready to migrate?}
B -->|No| D[Use Cloud Sync]
B -->|Yes| E[Use Connect Sync]
C -->|Yes| F{Parity gaps affect your environment?}
C -->|Not yet| G[Stay on Connect Sync, monitor parity]
F -->|No gaps| H[Migrate to Cloud Sync]
F -->|Has gaps| I[Coexistence: migrate eligible OUs]
Migration Path
For organizations currently on Connect Sync:
- Assess parity. Check the feature comparison table against your actual usage. Many Connect Sync deployments use only basic features that Cloud Sync fully supports.
- Pilot with coexistence. Move a test OU to Cloud Sync while keeping the rest on Connect Sync.
- Expand gradually. As pilot succeeds, migrate more OUs.
- Decommission Connect Sync. Once all objects are managed by Cloud Sync, disable and remove the Connect Sync server.
The migration quickstart covers both the manual (OU-based) and programmatic (MS Graph API) approaches. See Migration from Connect Sync.
Keeping This Page Current
Cloud Sync’s feature set is expanding. The parity gaps listed here will narrow over time. Check the Microsoft feature comparison for the latest status before making a decision.
Cross-Product Resources
For additional cross-product material that spans both sync technologies:
- Decision matrix - Scenario-based recommendations and decision flowchart
- Coexistence guide - Supported coexistence topologies, ownership rules, and common mistakes