Your migration has been scheduled: Entra Connect sync gives way to cloud sync

The Message Center post is written in the friendliest corporate voice imaginable, but read it twice and the substance is new. Starting this July, Microsoft is notifying tenants about their move from Entra Connect Sync to Entra Cloud Sync through the Message Center, Entra Connect Health and targeted mails. And the notifications do not ask whether you would like to migrate. They tell you when. Individual transition timelines, assigned per tenant, rolled out in waves.

For years this was an invitation. Cloud Sync sat next to Connect Sync as the lighter option you could consider, someday, once it covered your scenarios. That era is over. The wording has quietly shifted from "you can" to "you will be scheduled". Somewhere in Redmond there is now a system that decides when your organization has time for its sync migration. Anyone who has run hybrid identity for the last decade knows exactly how much that assumption is worth.

What is actually happening

Two separate things are converging in the second half of 2026, and it helps to keep them apart.

The first is the transition program itself. Beginning in July 2026, Microsoft assigns transition windows in waves. The early waves target tenants whose synchronization needs Cloud Sync already covers completely: single forest, standard attribute flows, no exotic rules. If you run a more involved setup, multi-forest, heavy filtering, a large directory, you are explicitly not in the first group. Microsoft says later waves will follow as Cloud Sync reaches parity with the scenarios those tenants depend on.

The second is a hard version deadline that has nothing to do with Cloud Sync but lands in the same quarter. Every Connect Sync server has to run version 2.5.79.0 or later by September 30, 2026, otherwise synchronization simply stops. And that minimum build itself leaves support on October 23, 2026. The message between the lines is hard to miss: the old engine is being kept on a very short leash while the exit is being built.

Why Microsoft is pushing, and why the direction is right

It is worth being fair here. Connect Sync is a heavy, stateful piece of on premises software. It wants a dedicated server, a database, patch cycles, backup, monitoring and a person who still remembers why it is configured the way it is. Cloud Sync replaces that with lightweight agents that hold no configuration worth grieving over. The sync logic lives in the tenant, high availability means installing a second agent instead of designing a failover concept, and the authentication experience for users does not change at all. Password hash sync and pass-through authentication carry on as before.

Nobody who has watched a sync server eat itself on a patch Tuesday evening will shed a tear for the architecture. As a direction, this is the right call, and for a large share of organizations Cloud Sync is simply the better place to be.

Where the frustration will actually come from

The pain is not in the standard case. It is in everything that accumulated around the sync engine over the years, precisely because the engine allowed it.

Think of the declarative sync rules a consultant built in 2019 who has long since left. The custom attribute flow that feeds an extension attribute because a badge system, an HR export or a signature tool reads it on the other side. The OU and attribute filtering that grew organically through three reorganizations. The third party provisioning tool that quietly depends on what the sync server writes. Exchange hybrid attributes. Device scenarios that assume the old engine. None of this translates one to one, because Cloud Sync deliberately does not offer a hand-tuned rule engine. That is its whole point.

So the realistic failure mode is not a big bang outage. It is subtle mismatches: an attribute that silently stops flowing, a transformation Cloud Sync's model cannot express, a downstream system that starts matching on stale data. The kind of thing you discover three weeks later through a ticket that makes no sense.

An assigned migration window does not turn technical debt into a plan. It only sets the date on which the debt becomes visible.

What I would do before the mail arrives

The tenants who will have a boring migration, and boring is the goal, are the ones who treat this as an identity hygiene project now instead of a calendar event later.

Start with a real inventory of your sync configuration. Export the rule set and separate defaults from customizations. For every customization, write down why it exists and which system depends on it. In my experience roughly half of these rules no longer have an owner, and a good part of them can simply be retired, which is the cheapest migration work you will ever do.

Then map what remains against what Cloud Sync supports today and identify genuine blockers rather than assumed ones. If you find blockers, you have your argument for a later wave and a concrete list to watch as parity grows. If you do not, run Cloud Sync in parallel on a scoped pilot OU next to your existing Connect Sync, which is a supported pattern, and let it prove itself on real objects before any window opens.

And treat the September version deadline as separate, unavoidable housekeeping. Being on an unsupported build while planning a platform migration is a place you do not want to be.

The scheduler wins either way

Forced migrations are irritating, and the irritation is legitimate: this one arrives on Microsoft's schedule, not yours. But the underlying move is overdue, and complaining about the calendar does not change it. The only real choice left is whether the assigned window finds you scrambling through undocumented sync rules, or politely bored because the work was already done.

Microsoft has decided when you have time for your migration. The best answer is to have already had time.