Entra Cloud Sync vs Connect Sync: what the 30 September deadline forces

Entra Cloud Sync vs Connect Sync is normally argued as an architecture question. For the next month it is a version question. Microsoft has set a hard service cut-off: every Microsoft Entra Connect Sync server below version 2.5.79.0 stops synchronising on 30 September 2026. That is an upgrade deadline, not a migration deadline, and treating it as a reason to move to Cloud Sync inside it is how organisations find out which of their features Cloud Sync does not have.

A cutover changes how users authenticate and what the directory knows about their devices, and both of those land on your access policies before they land anywhere else. The Conditional Access policy design guide covers that layer. This page is about the sync engine underneath it.

One disclosure before the detail. My tenant is a lab with no enrolled devices and no on-premises forest attached to it, so I have not run a Connect Sync to Cloud Sync cutover in production. What follows is documented behaviour, verified against Microsoft Learn on 26 August 2026, plus the places I would expect it to bite.

The 30 September deadline is about a version number

Microsoft’s Entra Connect version release history carries a mandatory upgrade notice at the top of the page. All synchronisation services in Microsoft Entra Connect Sync stop working on 30 September 2026 if the server is not on at least version 2.5.79.0, which shipped in May 2025 with a back-end service change that hardens the service side. This is not a warning email. Synchronisation fails and stays failed until the server is upgraded.

Two prerequisites travel with it: .NET Framework 4.7.2 and TLS 1.2. The installer is no longer a general download either, it is published in the Microsoft Entra admin center under the Get started page for Microsoft Entra Connect.

Now the part that gets missed. Version 2.5.79.0 is the floor for surviving 30 September, and it is not a destination. Connect Sync 2.x versions retire twelve months after a newer version is released, a policy in force since March 2023. Version 2.5.79.0 leaves support on 23 October 2026, twenty three days after the deadline it satisfies.

The current build is 2.6.84.0, released 7 July 2026, and Microsoft flags it as containing security fixes. If you are taking a maintenance window anyway, upgrading only to the minimum viable version buys you three weeks and a second outage.

Entra Cloud Sync vs Connect Sync: the table that decides it

Microsoft’s own Cloud Sync decision guide publishes a full capability matrix, last updated 24 February 2026. Most of it is parity and not worth reprinting. These are the rows that actually change a decision.

Read that as two lists rather than one. Cloud Sync removes an on-premises single point of failure and adds scenarios Connect Sync cannot do at all. It also removes capabilities that a mature Connect Sync deployment is quite likely to be using without anyone remembering that it is.

The six conditions that keep you on Connect Sync

Any one of these is a blocker today, not a preference:

1. More than 150,000 objects in a single AD domain. The limit is per domain, so a large forest split across several domains may still clear it. Count before you assume either way.
2. Any group above 50,000 members. Connect Sync goes to 250,000. This is the limit that catches organisations with an all staff distribution group nobody has looked at in years.
3. Microsoft Entra hybrid join. Cloud Sync does not synchronise device objects. If your device trust depends on hybrid join today, this is the largest piece of work in the migration, and it is not a sync project, it is a device identity project.
4. Advanced sync rules or attribute based filtering. Cloud Sync offers an expression builder and OU scoping. If your Connect Sync install has custom inbound and outbound rules in the Synchronization Rules Editor, they do not port.
5. Cross forest references or attribute merging across domains. Connect Sync can resolve an object relationship spanning forests and can merge attributes from more than one AD source. Cloud Sync does neither.
6. A dependency on reconciliation. Out of band sync correction is not available in Cloud Sync. If your operational runbook contains a manual repair step, that step disappears.

Microsoft’s migration guidance is explicit about its own scope: it is written for tenants that installed Connect Sync using Express settings and are not synchronising devices. That is a narrower audience than the general framing implies, and it is worth checking whether you are in it before planning around the assumption.

What Cloud Sync gives you in return

Framed only as a list of missing features, Entra Cloud Sync vs Connect Sync reads as a downgrade, and that is not the whole picture. The architectural case is real and it is mostly about failure behaviour. Connect Sync is one server, and when that server is down synchronisation is down. Cloud Sync runs multiple active provisioning agents that fail over between themselves with no configuration change, so patching an agent stops being a change window.

Configuration lives in Microsoft Entra ID rather than on the server, which means sync configuration is something you administer through the Microsoft Entra admin center from anywhere. That is convenient, and it is also a permissions question: who can change your synchronisation scope is now decided by directory role assignment rather than by who can log on to a server. If you have not thought about that boundary, the Entra ID centric RBAC design applies directly.

Beyond that: disconnected forest synchronisation without forest consolidation, which is the merger and acquisition scenario Connect Sync genuinely cannot serve; group provisioning from Microsoft Entra ID back to Active Directory; on demand provisioning for testing a single object; and a provisioning service that runs on a two minute scheduler. Agents update themselves from the service, so the patching treadmill goes away.

The failure modes

Removing objects from Connect Sync scope during coexistence. This is the one that costs data. Microsoft’s migration article states plainly that during the pilot or coexistence phase you must not remove OUs, domains, groups, users, contacts or other referenced objects from Connect Sync scope. Doing so can drop references in the Microsoft Entra connector space and export reference deletes, and reference deletes means group membership removals landing in your tenant. The supported model is to keep objects in Connect Sync scope and apply the cloudNoFlow and JoinNoFlow rules, so Connect Sync stops exporting adds, deletes and non reference attribute updates while reference attributes such as member and manager still resolve.

Upgrading to exactly 2.5.79.0. It satisfies the September cut-off and expires on 23 October 2026. Anyone who plans the change window against the headline deadline rather than against the support table books the same outage twice.

A modified miiserver.exe.config. Microsoft documents a known issue on 2.5.190.0 and 2.6.1.0: if that file was edited previously, the upgrade leaves it alone and synchronisation then fails with an assembly load error.

1System.IO.FileLoadException: Could not load file or assembly
2‘System.Diagnostics.DiagnosticSource, Version=6.0.0.1’ or one of its
3dependencies. The located assembly’s manifest definition does not match
4the assembly reference. (Exception from HRESULT: 0x80131040)

The usual reason that file was edited is old guidance for Password Hash Synchronisation in FIPS enabled environments. The fix is to add a binding redirect for the assembly inside the assemblyBinding section, then restart the ADSync service.

1<!– Add inside assemblyBinding, then restart the ADSync service. –>
2<dependentAssembly>
3  <assemblyIdentity name="System.Diagnostics.DiagnosticSource"
4                    publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
5  <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
6</dependentAssembly>

Expecting a staging server. Staging servers are not supported with the cloud provisioning agent. Multiple active agents give you availability, they do not give you the rehearsal mode Connect Sync administrators use to preview an export before it happens. On demand provisioning tests one object at a time and is not a substitute for a staged full sync.

Losing hybrid join without noticing what it was holding up. When device objects stop flowing, device records lose their registered state, and any policy that tests device state stops matching the way it did. A Conditional Access filter written with positive operators against a device that is no longer in the directory matches nothing at all, which is a specific and quiet failure covered in the Conditional Access device filter behaviour. Check what depends on device state before the cutover, not after.

Using group scope filtering for anything past a pilot. Cloud Sync supports up to 50,000 group members through OU scope filtering, and nested objects beyond the first level are not included when scoping by security group. Microsoft says to use group scope filtering for pilot scenarios only. Take that literally.

What I would do differently

Split the decision in two, because the deadline and the migration are not the same project. Entra Cloud Sync vs Connect Sync deserves its own calendar, and September is not it.

The deadline is just over four weeks away and has one correct answer: upgrade Connect Sync to 2.6.84.0. Not to 2.5.79.0, and not to whatever auto-upgrade last pushed, because auto-upgrade only ships builds carrying a critical fix and is not guaranteed to have moved you past the floor. Check the installed version, check .NET Framework 4.7.2 and TLS 1.2, and take the window. That is a maintenance task, and it should be finished well before the last week of September.

The migration is separate work with its own calendar. Run the six blockers above against your actual environment, in that order, and stop at the first hit. If you clear all six, the sensible path is a pilot scoped by OU with the no-flow rules applied, batch by batch, with nothing leaving Connect Sync scope until that batch is fully cut over. If you do not clear all six, staying on Connect Sync is a supported position rather than a failure, and Microsoft is still publishing support dates for it into 2027.

The one thing I would not do is let the September date drive the architecture. New synchronisation features are being built on the Cloud Sync platform and the direction of travel is not in doubt, but direction of travel is not a reason to run a device identity project in four weeks. If hybrid join is in scope, price that work honestly, and check whether the governance capabilities you would want on the other side sit above your current licence tier before you commit. The Entra ID P1 vs P2 maths is the place to start on that question.

Last verified: 26 August 2026.