Entra Connect: the date that stops your sync, and the date that just emails you

Two Microsoft items are sitting on the desk of anyone running an Active Directory synchronised with Entra ID, and they are getting conflated. One is a migration: Microsoft wants to move everybody from Entra Connect Sync to Entra Cloud Sync, it runs in waves, it reaches you through the Message Center and it allows you to request an exception. The other is a hard technical cut-off with a date: on 30 September 2026, any Entra Connect server below version 2.5.79.0 stops synchronising. Only one of the two actually breaks something, and it is not the one showing up in the emails.

As we write this there are just over seven weeks until the first one. We are putting it down because the same conversation has come up several times lately and it always starts the same way: somebody received the Cloud Sync migration notice, is weighing up whether it fits, and nobody has checked which version the sync server is on. These are two separate pieces of work with different urgencies, and the correct order is the opposite of the one almost everybody is following.

The date that does break things

Microsoft has deployed a dedicated first-party application for synchronisation between Active Directory and Entra ID: it shows up under enterprise applications as Microsoft Entra AD Synchronization Service, with application ID 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016. That service change ships in Entra Connect version 2.5.79.0, which Microsoft dates to May 2025. And Microsoft's documentation is unusually blunt about what happens if you do not have it: all synchronisation services in Entra Connect Sync will fail.

There is no grace period and no gradual degradation. One caveat worth stating so as not to overstate the alarm: this destroys nothing and is fixed by upgrading, even afterwards. But the note itself is explicit — synchronisation will be down from 30 September until the moment you upgrade — and reaching that moment, if October catches you with a server whose .NET is out of date, can take days.

What stops is not email

This is where it stops being a maintenance notice and becomes a security problem, and where the word "fail" misleads. What stops is synchronisation, not authentication. If you use password hash sync, the hashes already in Entra ID are still there: people will sign into Teams and their mailbox on 1 October without noticing a thing — Microsoft does not state this for this particular cut-off, but its own disaster-recovery guidance for the sync server asks the question the other way round: if you use password synchronisation, do users accept having to use the old password in Entra ID when they change it on-premises? Which assumes they are signing in. What stops flowing is the bookkeeping of who exists.

The joiner who never arrives is noticed the same day: the new salesperson has no mailbox and somebody calls. The password change that never propagates is noticed at the first complaint. The leaver is never noticed. If you disable an account in AD on 2 October because that person left the company, and sync is stopped, that account stays alive in the cloud with its token, its connected applications and its SharePoint access. Nobody is going to raise a ticket about that. It is the textbook silent failure, and the reason a zero trust model does not accept a session as good just because it exists.

It is the same reasoning we applied when we wrote about Entra retiring SMS as a second factor: identity is not defended at the moment of login, it is defended across the account's whole lifecycle. And in a hybrid environment, that lifecycle travels through that one server.

The parachute only opens if you do not need it

Plenty of people answer this with "I have auto-upgrade on, it will sort itself out". That is the reasonable answer and in many cases it is correct: Microsoft auto-upgrades where it can. But there is fine print worth reading twice: for auto-upgrade to work, you must already be on version 2.3.20.0 or higher.

Read it the other way round and the whole problem appears: the mechanism that would save you automatically does not work on precisely the oldest servers, which are the only ones with the problem. The one on 2.4 never needed your help. The one untouched since 2019 — the one that will stop on 30 September — is the one that will not get it. The parachute only opens if you were not going to fall.

And there are two more prerequisites that on an old server are the real blocker, not the version: .NET Framework 4.7.2 and TLS 1.2. On a machine nobody has touched in years, neither of those gets resolved inside Tuesday's maintenance window. That is the work to start this week, not in the final one: check the version, check .NET, check TLS. Ten minutes per server.

The other date: the one that emails you

In April 2026, Microsoft published the start of the Entra Connect Sync to Entra Cloud Sync transition as a "plan for change". The most reassuring detail is the one almost nobody has read: the first waves focus on tenants whose needs Cloud Sync already meets in full and, verbatim, if your organisation relies on advanced features or has a large directory, you will not be among the initial targeted groups. Later waves arrive as Cloud Sync gains capabilities.

The official FAQ goes further and says two things worth having to hand when somebody from management turns up holding the email with an urgent look on their face. One: if you cannot migrate within the recommended window, you request an exception and, if approved, you keep your current setup while you plan. Two, and this is the key sentence: you are not required to migrate until the features your organisation depends on are supported in Cloud Sync. There is no announced retirement date for Connect Sync. This is not a deadline, it is a queue.

The table that actually decides

Microsoft publishes a comparison of more than thirty capabilities across the two tools. Most are at parity — users, groups and contacts, password hash sync, password writeback, Exchange hybrid attributes, directory extensions, OU-based filtering, seamless SSO — and there is nothing to argue about there. The decision comes down to two numbers and eight boxes.

The two numbers are Cloud Sync's scale limits: 150,000 objects per domain and 50,000 members per group. Connect Sync has no ceiling on the first and supports groups of up to 250,000 members. For calibration: 150,000 objects per domain rules out very few of the companies we look after in Catalonia, while being a genuine ceiling for universities, retail chains and industrial groups with years of accumulated objects. If you are below it, that row is not your conversation.

The eight boxes are the rows where Connect Sync says yes and Cloud Sync says no. Ordered by how likely they are to be your problem, not by the order of the table:

• Device synchronisation. The one that decides most cases. We come back to it below.
• Advanced sync rules. Cloud Sync uses an expression builder; Connect's complex rules engine is not there.
• Pass-through authentication configuration. Mind the nuance, because it scares people more than it should: what is missing is the configuration from within the sync tool. Pass-through authentication and seamless SSO are configured separately and, per Microsoft, keep working after migration.
• AD FS integration setup. A different row from the previous one, not the same one: federation is configured with other tools, never from the sync client.
• Cross-forest references. Relationships between objects in different forests. Cloud Sync does support disconnected forests, which is a different thing, and there it wins.
• Merging attributes from multiple domains. The classic case of companies that grew by acquisition and never consolidated.
• Reconciliation. Out-of-band sync correction. Cloud Sync has on-demand provisioning, which is for validating, not the same thing.
• Device writeback. Discontinued in favour of Cloud Kerberos Trust. No debate here: that is the product direction.

Outside those eight there is a ninth row worth a look that is not a no: attribute-based filtering, where the table says "limited". If you filter by OU, it does not affect you. It is worth stating what Cloud Sync does and Connect does not, because a comparison that only looks at one side's gaps lies by omission: disconnected forests without consolidating them, several active agents at once with automatic failover — Connect Sync is a single point of failure and that ends — group provisioning from the cloud into AD, on-demand provisioning to test a single user, and all configuration in the portal with no VPN and no logging into the server.

The row that decides: the laptops

Of the eight, the one that decides it in our experience is the first. If your machines are joined to the local domain and also registered in Entra ID — what is called hybrid join — that join depends today on the computer object syncing from AD. Cloud Sync does not sync devices. That single box decides the answer for a huge slice of Spanish companies with a hundred to a thousand employees, which is exactly the profile that, by directory size, would fall into the first migration waves.

There is a way out coming, and it needs to be described with its label on. In March 2026 Microsoft published, in public preview, hybrid join via Entra Kerberos: the device is joined at provisioning time, without waiting for Entra Connect sync and without AD FS. If that reaches general availability, this row stops blocking anyone. But it is a preview, and a preview does not go on the critical path of two hundred laptops that have to boot on Monday. Our recommendation here is deliberately boring: note it, track it, and do not plan around it.

When Cloud Sync is already the right call

For a large share of the companies we look after, Cloud Sync is not a lesser evil to be swallowed: it is the better tool today. The profile is specific and can be checked in an afternoon: one forest, password hash sync, OU-based filtering, no inherited custom rules, well under 150,000 objects, and machines managed from Intune without hybrid domain join. If that is you, the decisive argument is not that Microsoft is asking: it is that you stop depending on one server for joiners and leavers to reach the cloud at all.

And there is a piece almost nobody uses that puts the path in order: since January 2026, object-level source of authority switching is generally available. It lets you move individual users from being AD-synced to being cloud-managed accounts, one at a time, while sync keeps running for everyone else. Both tools support it. It is useful for the usual reason in a migration: doing it in pieces, starting with the people it hurts least if something looks off, instead of one weekend with everything in it.

Three ways to make this harder

• Using the Cloud Sync migration as a shortcut to make 30 September. It is the obvious temptation — "if I move to Cloud Sync I can forget about the version" — and it is a sequencing error: you swap an afternoon's work for a project, and during that project the Connect server is still there, because the guidance itself puts it in staging mode so you can validate and roll back. Upgrade first. Migrate afterwards, on your own calendar, without somebody else's date on top of you.
• Leaving both tools working on the same objects "for a while, just in case". Running Connect Sync and Cloud Sync at the same time over the same objects is not supported. Coexistence is done per organisational unit: each one managed by a single tool. That is not a style preference, it is the condition for the pilot to mean anything.
• Treating the sync server as just another server. It is the piece that decides who exists in your cloud and who stops existing. When we wrote about auditing your AD CS, the thread was the same: the systems that govern identity do not get inventoried alongside the file servers. This one belongs on that list, with its record, its owner and its version written down.

What to do this week

Open the Entra Connect wizard, look at the version and compare it with 2.5.79.0. If you are below, check .NET Framework and TLS 1.2 before touching anything, because that is where the real work is. Then, and only then, sit down with the comparison table and tick your eight boxes: the answer will almost certainly come from the first one. It is the same method we proposed with the EWS shutdown in Exchange Online — inventory first, deadline second — because Microsoft's dates do not arrive one at a time. And one nuance that saves doing the job twice: 2.5.79.0 is the floor, not the destination. That version drops out of support on 23 October 2026, three weeks after the cut-off, and it carries a note from Microsoft asking you not to use the Synchronization Service Manager while you are on it. Go to the latest, not to the minimum.

All of this — identity, devices and the glue between the office and the cloud — is what we build and run under modern workplace. If you have an Entra Connect server and do not know which version it is on, drop us a line and we will look at it with you.