HomeServicesManaged IT ServicesClaude DeploymentInsightsAnswersAboutContact
Identity & access

Entra Connect Sync or Entra Cloud Sync: which should we use?

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.

AreaEntra Connect SyncEntra Cloud Sync
On-premises footprintFull sync server with local databaseLightweight agents, outbound only
Where configuration livesOn the serverIn the Entra admin center
High availabilityStaging-mode server you keep currentMultiple active agents
Disconnected or acquired forestsPossible but complexDesigned for it
Pass-through authenticationSupportedNot supported; use password hash sync
Device sync for hybrid Entra joinSupportedNot the tool for this
Custom sync rulesVery flexibleSimpler 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

Yes. Microsoft supports running both against the same tenant as long as each object is in scope for only one engine. This is the normal way to migrate, and it also lets you keep Connect Sync for a forest that needs a feature Cloud Sync lacks while using Cloud Sync elsewhere.
It should not, if you plan it. Users keep the same UPN and password when password hash sync is already in use. If you currently use pass-through authentication or federation, switching sign-in method is a separate change that needs its own testing and communication before you move to Cloud Sync.
Only while on-premises Active Directory is your source of identity. If you plan to retire AD, sync is a transition tool, and the end state is cloud-only accounts in Entra ID. See our answer on moving to cloud-only Entra ID for what that involves.

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