Short answer
Use Entra Cloud Sync if it supports every feature you need, because it is lighter to run and Microsoft is investing in it. Stay on Entra Connect Sync if you depend on features Cloud Sync does not cover, such as pass-through authentication, device sync for hybrid join, or complex custom sync rules. Many organizations run both during a transition.
Key facts
- Cloud Sync runs lightweight agents and keeps its configuration in the cloud; Connect Sync runs a full sync engine and SQL database on a server you maintain.
- Pass-through authentication and federation sign-in need Connect Sync; Cloud Sync works with password hash sync.
- Hybrid Entra join relies on Connect Sync to sync computer objects.
- Both tools can run side by side, scoped to different OUs or forests, during a move.
- Never let two engines sync the same object; scope carefully before cutover.
The short difference
Both tools copy users, groups and selected attributes from on-premises Active Directory into Microsoft Entra ID so people can sign in with one identity. The difference is where the work happens.
Entra Connect Sync is the long-standing option. It installs a sync engine, a local database and a configuration wizard on a Windows server. It is powerful and highly customizable, but you own the server, its patching, its upgrades and its recovery.
Entra Cloud Sync moves the sync logic into the Microsoft cloud. On premises you install one or more small provisioning agents that only need outbound connectivity. Configuration, scoping and attribute mapping are managed in the Entra admin center. Adding a second or third agent gives you high availability without a staging server.
| Area | Entra Connect Sync | Entra Cloud Sync |
|---|---|---|
| On-premises footprint | Full sync server with local database | Lightweight agents, outbound only |
| Where configuration lives | On the server | In the Entra admin center |
| High availability | Staging-mode server you keep current | Multiple active agents |
| Disconnected or acquired forests | Possible but complex | Designed for it |
| Pass-through authentication | Supported | Not supported; use password hash sync |
| Device sync for hybrid Entra join | Supported | Not the tool for this |
| Custom sync rules | Very flexible | Simpler attribute mapping and expressions |
When Entra Connect Sync is still the right choice
Stay on Connect Sync, or keep it for part of the estate, when a feature you rely on depends on it. Check the current Microsoft feature comparison before deciding, because Cloud Sync coverage keeps growing.
- You use pass-through authentication or federation with AD FS for sign-in and are not ready to move to password hash sync.
- You have hybrid Entra joined Windows devices and need computer objects synced.
- You depend on custom sync rules, complex attribute flows or filtering that Cloud Sync mappings cannot express.
- You have a very large directory or specific writeback scenarios that Cloud Sync does not yet support in your configuration.
When Entra Cloud Sync is the better fit
Cloud Sync suits most small and mid-size organizations that use password hash sync, have a single forest or a few simple ones, and want less infrastructure to maintain.
It is especially useful after an acquisition. You can install agents in the acquired company's forest and bring its users into your tenant without building trusts or merging directories first. That makes it a common building block in M&A identity work.
It also removes a single point of failure. If one agent host goes down, another keeps syncing, and there is no staging server to keep in step.
How to move from Connect Sync to Cloud Sync
A move is a scoping exercise more than a migration. The goal is that every object is synced by exactly one engine at any moment.
- Inventory what Connect Sync does today: sign-in method, OU filtering, custom rules, writeback features, and the source anchor attribute.
- Confirm password hash sync is enabled and working, because Cloud Sync relies on it.
- Install Cloud Sync agents on two or more domain-joined servers and create a configuration scoped to a pilot OU or group.
- Remove the pilot scope from Connect Sync, then enable it in Cloud Sync, and verify that objects match rather than duplicate.
- Expand in waves, then decommission Connect Sync once nothing depends on it, or keep it only for the features Cloud Sync cannot cover.
Common mistakes
- Letting both engines claim the same users, which causes attribute flapping and duplicate objects.
- Changing the source anchor partway through, which breaks matching to existing cloud accounts.
- Removing Connect Sync while hybrid joined devices still rely on it.
- Forgetting that Connect Sync versions must stay current and that old builds lose support.
How Accred Consulting approaches it
Accred Consulting starts with discovery of your current sync setup: sign-in method, filtering, custom rules, writeback and device dependencies. From that we recommend Connect Sync, Cloud Sync or a mix, with the reasons written down. The proposal sets a fixed price and timeline. In delivery, our US-based specialists stage agents, scope pilot OUs, move objects in waves with check-ins at each step, and confirm no duplicates or sign-in changes. At handover you get documentation of the final sync design, the scoping rules, and runbooks for agent health and recovery, with optional support afterward.
Track record: 475+ client projects, 2,000+ migration workstreams and 210,000+ users migrated by a US-based team. Company facts · Case studies
Related questions
Want this scoped for your environment?
Book a free consultation. After discovery you get a written plan with scope, a fixed price and a timeline.
Book a free consultation