Entra Connect vs Entra Cloud Sync

If you run on-premises Active Directory alongside Microsoft 365, you need to sync users and groups from AD to Entra ID so one identity works in both worlds. Microsoft ships two tools for the job: the veteran Entra Connect Sync (formerly Azure AD Connect) and the newer Entra Cloud Sync. They overlap heavily, Microsoft's investment is visibly moving to one of them, and yet the old one still holds several scenarios hostage. Here's how to choose without regret.

Entra Connect Sync

The traditional tool is a full application you install on a Windows server on-prem. It holds the sync engine, the rules, and a local database, and it synchronises one or more AD forests to Entra ID on a cycle (every 30 minutes by default).

Strengths:

• Mature and everywhere — two decades of lineage, every edge case documented somewhere.
• Supports all three authentication topologies: password hash sync, pass-through authentication (PTA), and federation (AD FS).
• Password writeback for self-service password reset.
• Rich, editable synchronisation rules — attribute transformations, complex filtering, precedence control.
• Required for Exchange hybrid writeback, device writeback, and some group writeback scenarios.

Weaknesses:

• It's a pet server. It needs patching, monitoring (Entra Connect Health helps), and a staging server if you want any resilience — active-passive at best.
• Configuration lives in a thick Windows app, and years of accumulated custom sync rules become archaeology.
• Version servicing is real work: old builds go out of support, and upgrades are on you.

Entra Cloud Sync

Entra Cloud Sync inverts the architecture: lightweight provisioning agents run on-prem (installed in minutes, several per tenant), while the sync engine and all configuration live in the cloud, managed from the Entra admin center.

Strengths:

• Active-active high availability by installing multiple agents — no staging-server dance.
• Configured in the portal; nothing meaningful to back up on the servers.
• Handles multiple disconnected forests cleanly — a natural fit for mergers and acquisitions where the forests have no trust between them.
• Password hash sync and password writeback supported.
• Group provisioning to AD (the successor to group writeback) enables cloud-first group management for on-prem apps.
• New capability ships here first; the agent self-updates.

Weaknesses:

• No PTA or federation support — password hash sync is the assumption.
• No device writeback, and Exchange hybrid scenarios still lean on classic Connect.
• Attribute transformation is expression-based and more constrained than the classic rules engine (improving steadily, but if you have heavily customised sync rules, audit them first).
• Very large single domains can exceed its per-configuration object guidance where classic Connect scales further.

Which to use today

• New hybrid deployment, no exotic requirements: Cloud Sync, full stop. Password hash sync plus Cloud Sync is the configuration Microsoft designs for first, and there's no server estate to babysit.
• Existing Entra Connect with Exchange hybrid: stay put for now. Exchange hybrid deployment writeback is the most common anchor keeping tenants on classic Connect; plan the sync migration alongside the Exchange decommission.
• You require PTA or AD FS: classic Connect — though the better question is whether you still need them. Password hash sync is the Microsoft-recommended default, works when your on-prem estate is down, and unlocks leaked-credential detection. Most PTA and federation deployments are historical decisions worth revisiting, not requirements.
• Multi-forest mess, M&A scenarios: Cloud Sync, one configuration per forest, no trusts needed.
• Tens of thousands of users with custom attribute flows: audit against Cloud Sync's limits before assuming either answer.

Coexistence and migration

This isn't a forklift decision. Cloud Sync and Entra Connect can run side by side in one tenant, scoped so each owns different OUs or domains — the supported pattern for gradual migration. The Entra admin center includes a migration assessment that inspects your Connect configuration and flags whatever blocks a move.

A sensible migration: stand up Cloud Sync agents, move a pilot OU, verify attribute fidelity and password flows, then walk OUs across until Entra Connect owns nothing and can be retired. Keep the scoping mutually exclusive — two engines claiming the same object is the one genuinely bad state.

The direction of travel

Microsoft has been explicit that Cloud Sync is the strategic product: it's where features land first, and classic Entra Connect increasingly receives servicing rather than investment. Nobody should build new dependency on the classic engine in 2026. If you're on Entra Connect today, you don't need to panic — it's supported and works — but "migrate to Cloud Sync when the blockers clear" belongs on the identity roadmap, right next to "decommission the last Exchange server," and frequently gated by it.

One more forward-looking note: sync only what the cloud needs. Every service account, every stale security group you sync becomes clutter in Entra ID and surface area for attacks. A sync migration is the natural moment to re-scope from "everything" to "users, and the groups that matter" — see Entra ID groups and group-based licensing for what the cloud side should look like when it's tidy.