Let’s start with the headline, because it changes the tone of the rest of this post: Microsoft confirmed in April 2026 that Entra Connect Sync is being retired. Cloud Sync becomes the default sync engine, and tenant notifications have been rolling out in phased waves since July 2026, based on which features each environment actually needs from Cloud Sync before it’s safe to move.

Worth being precise about what that means, because there’s a fair amount of noise around it. It isn’t a single hard cut-off for everyone — Microsoft’s own guidance is that you’re not required to migrate until the features you depend on are supported in Cloud Sync, and you can request an exception if you’re genuinely not ready. But it is a retirement, not a suggestion. If you’re still running Connect Sync, you’re already somewhere in that queue, whether or not the notification has landed in your tenant yet.

Don’t confuse this with the other Connect Sync deadline doing the rounds — the mandatory upgrade to version 2.5.79.0 or later by 30 September 2026, after which synchronisation stops working entirely if you haven’t updated. That’s a security hardening requirement, not the retirement itself. They’re two different clocks. If you’re behind on patching, sort that first before you even start thinking about migration timelines.

I’ve sat through enough of these migrations now to know the pattern: someone reads a “Cloud Sync is the future” blog post, spins up an agent in a test tenant over lunch, and declares the project basically done. Then Hybrid Azure AD Join breaks, or a group with 60,000 members refuses to sync, and suddenly it’s a very different conversation with the customer.

So this post is the version I wish someone had handed me before my first Cloud Sync migration: what’s actually happening with the retirement, what Cloud Sync changes, what to check before you start, and where people trip up.

Why bother moving at all?

Connect Sync has done its job well for a decade. And now, with a retirement date attached to it rather than just a lack of new features, “increasingly a job nobody wants to own” becomes “a job that’s going away regardless.” That changes how you prioritise this internally — it’s no longer purely a modernisation project you can defer indefinitely.

It’s a Windows server, sat on-prem, with a sync engine, a database, and a scheduler that somebody has to patch, back up, and babysit. When it falls over at 2am, it’s your problem, and usually it’s your problem alone, because most environments only run one.

Cloud Sync flips that around. The configuration lives in Entra ID and you manage it from the Entra Admin Centre. What’s left on-prem is a lightweight provisioning agent — genuinely lightweight, not “lightweight” in the way vendors usually mean it.

The bit I actually care about as a consultant: you can run several active agents at once. Connect Sync gives you an active/passive pair if you’re disciplined about it. Cloud Sync gives you proper active/active, so one agent falling over doesn’t take sync down at all. For anyone who’s been paged because the one Connect Sync box died overnight, that alone is worth the migration.

Other things worth knowing:

• Agents update themselves. No more scheduling patch windows for the sync server.
• Disconnected forests are supported natively — no VPNs or trust relationships needed just to sync identities.
• New Microsoft sync features land here first, sometimes exclusively.
• The infrastructure footprint shrinks considerably — no SQL Server (or ADAM/AD LDS) to maintain.

None of this means Connect Sync is bad. It means Microsoft has stopped investing in it the way they invest in Cloud Sync, and that gap will only widen.

Before you touch a single agent: check whether you actually can move

This is the step people skip, and it’s the one that causes the awkward client calls later.

Cloud Sync doesn’t do everything Connect Sync does. Not yet, and in some cases maybe not ever. Go through this list honestly before you promise anyone a migration date.

Scale. Cloud Sync currently tops out at 150,000 objects per AD domain, and groups are capped at 50,000 members. If you’re a large enterprise with sprawling security groups, check your actual numbers — don’t assume you’re fine.

Hybrid Azure AD Join. This is the one that catches people out most often. Connect Sync supports it. Cloud Sync currently doesn’t. If your organisation still relies on Hybrid Azure AD Join for device management, that’s not a footnote — it’s a blocker, and it needs its own conversation (and likely its own plan, possibly involving Entra Join instead) before Cloud Sync becomes viable for you.

Custom sync rules. If you’ve got a sync engine full of custom inbound/outbound rules, attribute transforms, and clever filtering that some contractor built five years ago and nobody’s touched since — go and actually read it. Cloud Sync has an attribute-mapping expression builder, and it’s decent for straightforward transforms. It is not the Connect Sync rules engine. If your rules are doing anything genuinely complex, expect rework, not a like-for-like port.

Forest design. Cloud Sync handles single forests, multiple connected forests, and multiple disconnected forests. Fine for most setups. If you’ve got a complicated cross-forest arrangement, go through Microsoft’s feature comparison line by line rather than assuming it’ll just work — cross-forest is exactly where the edge cases live.

If any of this rings alarm bells, that’s not a reason to abandon the idea. It’s a reason to scope properly before you start, rather than discovering the gap mid-migration.

Prerequisites: the boring bit that saves you later

Document what you’ve actually got. Not what you think you’ve got — what’s actually configured. OU filtering, which object types sync, Password Hash Sync settings, PTA and Seamless SSO config, every custom rule, directory extensions in use, group writeback, and anything tied to Exchange hybrid. I promise you this document will matter more during troubleshooting than during planning.

Export your Connect Sync configuration. Use the built-in import/export settings feature before you change anything. It’s a five-minute job and it’s your safety net if something goes sideways.

Check your authentication story separately from sync. This is genuinely good news, and it’s worth saying plainly: PTA and Seamless SSO are configured independently of the sync engine, so they keep working through the migration. Authentication is not the thing that breaks here. Sync scoping and attribute behaviour are.

Get the provisioning agents deployed. Install them on supported servers ahead of time, and deploy at least two. This isn’t gold-plating — a single agent just recreates the single-point-of-failure problem you were trying to get away from.

How to actually run the migration

There’s one rule that matters more than any other: never sync the same objects through both engines at once. Microsoft is explicit that this isn’t supported, and I’ve seen what happens when someone tries it anyway — duplicate writes, confused attribute states, and a support case that takes far longer to unpick than the migration itself would have taken done properly.

The way round this is scoping by OU. Cloud Sync takes ownership of specific OUs while Connect Sync keeps managing the rest, and you move the boundary a bit at a time.

Phase 1 — Pilot. Pick a small OU: test users, test groups, non-production service accounts. Nobody important. Validate attribute flow, password sync, group membership, and general provisioning behaviour. Cloud Sync’s on-demand provisioning is genuinely useful here — you can trigger sync for one specific user and watch exactly what happens, rather than waiting for a scheduled run and hoping.

Phase 2 — Configure Cloud Sync properly. Set up forest connectivity, OU scoping, attribute mappings, and Password Hash Sync. Don’t rush this bit — test it thoroughly before you let it anywhere near a production OU.

Phase 3 — Put Connect Sync into staging mode. This is the checkpoint that matters most. Staging mode lets Cloud Sync take over as the active engine while Connect Sync stays configured and ready as a rollback path. Before flipping anything live, check your object counts match, provisioning is behaving, group memberships are correct, and password sync is actually working — not just “looks fine at a glance.”

Phase 4 — Widen the net. Move more OUs across once the pilot’s proven itself. Validate after every phase, watch sync health properly, and resist the temptation to move everything at once because the pilot went smoothly. It always looks easy until the OU with the awkward legacy group turns up.

Phase 5 — Cut over fully. Once everything’s migrated, check sync health, confirm provisioning, verify authentication is still solid, and go through the provisioning logs properly. Only decommission the old Connect Sync infrastructure once you’re genuinely confident, not just hopeful.

Where people actually get burned

Splitting related objects across two engines. This is the mistake I see most often in staged migrations — users move to Cloud Sync while their groups stay on Connect Sync, or vice versa. The two engines don’t share an understanding of object relationships, so group memberships start behaving oddly in ways that are genuinely painful to debug afterwards. Move related objects together. Users and their groups go in the same phase.

Assuming feature parity that doesn’t exist. Organisations that have been running Connect Sync for years have usually accumulated a fair bit of custom logic nobody fully remembers building. Go through your custom attribute flows, sync rules, device sync requirements, and group writeback dependencies properly before you commit to a date. Not everything has a direct equivalent in Cloud Sync, and finding that out mid-migration is a bad time to find it out.

Testing the pilot too lightly. “It provisioned a test user” is not a pilot. A proper pilot covers password changes, group membership updates, attribute updates, anything Exchange-related, and joiner/mover/leaver scenarios. Those last three are where the real-world mess lives — a user changing department, a contractor’s account being disabled, someone getting rehired eight months later. If your pilot doesn’t touch those, it hasn’t actually told you much.

Is it worth doing?

Yes, generally — but on a timeline that matches your actual complexity, not the one a vendor slide deck implies.

If you’re running straightforward user and group sync, this is a genuinely quick win, and honestly one of the more satisfying migrations to run: less infrastructure, less patching, less 2am paging.

If you’ve got Hybrid Azure AD Join dependencies, heavy custom sync rules, or a large or complex environment, take the time upfront. Do the readiness assessment properly. Run a pilot that actually tests the edge cases, not just the happy path.

Move in phases, validate at every step, and keep Connect Sync as your safety net until you’re actually confident — not just optimistic. That’s the difference between a migration that goes quietly and one that ends up as a war story at the next conference.