Starting July 2026, Microsoft will begin contacting organizations directly—through the Microsoft 365 Message Center, Entra Connect Health alerts, and targeted emails—to assign them a transition window for moving from Entra Connect Sync to Entra Cloud Sync. The first notices will go to tenants whose current identity synchronization requirements are already fully supported by Cloud Sync. That means straightforward configurations, smaller directories, and environments that aren’t relying on advanced Connect Sync features that haven’t yet been ported.
What Microsoft Announced About the July Migration Wave
In its May 2026 “Plan for change” update, Microsoft outlined a phased approach to shift customers from the on-premises Entra Connect Sync tool to the cloud-native Entra Cloud Sync. The initial phase, targeted for July 2026, will focus exclusively on tenants that can already meet all their synchronization needs with the current Cloud Sync capabilities. Organizations with complex setups—large directories, heavy reliance on custom synchronization rules, device writeback, or advanced group filtering—won’t see a notice yet.
The announcement makes the initial selection criteria unusually clear: the first waves are for tenants that are “fully supported by Entra Cloud Sync’s current capabilities.” Microsoft will provide tooling, step-by-step documentation, and a transition tool when a tenant’s window opens. But it also offers an off-ramp: if a required feature isn’t yet supported, the tenant can continue using Connect Sync and monitor the feature comparison.
This is not a blanket retirement notice. It’s a targeted eligibility signal. The distinction matters because it means most administrators won’t wake up to a forced migration deadline. Instead, they’ll receive a planning trigger that should prompt a structured readiness assessment.
What July’s Notice Means for Your Hybrid Identity Setup
For IT Administrators and Hybrid Identity Teams
If your tenant gets a notice, the first move isn’t to start migrating—it’s to open a decision record. Inventory what Connect Sync manages today, including the parts that were set up years ago and might be forgotten. Microsoft specifically warns that migration duration and complexity are affected by the number of users and groups, custom sync rules, and the number of organizational units (OUs) being moved.
Cross-reference those requirements against Microsoft’s Cloud Sync feature comparison. Don’t reduce this to a generic “supported or unsupported” label. Write down each required capability, decide whether Cloud Sync handles it, and assign an owner who can confirm the result. If even one production dependency is unavailable, the proper conclusion is to stay on Connect Sync for now.
For teams that are ready, the pilot must follow an OU-based scoping model. Microsoft does not support Connect Sync and Cloud Sync managing the same objects simultaneously. That means you cannot run both tools side by side on the same users to compare results. Instead, you pick an OU, stop Connect Sync’s management of those objects, and let Cloud Sync take over exclusively. Validate the pilot on that isolated subset before expanding.
For Organizations That Won’t Get a Notice
No notice doesn’t mean no action. It likely signals that your environment still depends on a feature that hasn’t been replicated in Cloud Sync. The right response is to document that dependency clearly: which feature, which objects or workflows it affects, and who owns it. This turns a vague “we’re too complex” into a defensible, supportable reason to hold. Revisit the comparison as Cloud Sync evolves.
For Developers and Application Owners
If you build or manage apps that consume hybrid identity attributes, check whether Cloud Sync supports your required mappings. Some advanced provisioning scenarios—such as device object synchronization, custom attribute flows using the full rules editor, or certain writeback scenarios—may still be Connect Sync-only. Proactively identify gaps so that when your tenant’s window arrives, you aren’t scrambling to find a workaround.
The Pilot Trap: You Can’t Run Both Tools Side by Side
The highest-risk misunderstanding is the idea that “side by side” means two tools can safely synchronize the same population while you compare results. Microsoft’s documentation is explicit: “Connect Sync and Cloud Sync cannot manage the same objects simultaneously.”
OU design becomes the guardrail. A pilot is valid only when the chosen OU is unambiguously owned by one tool and excluded from the other. For a team preparing an early pilot, the sequence should be:
- Select an OU whose users and groups are well understood and whose impact is manageable.
- Confirm that Connect Sync will no longer manage the pilot objects before Cloud Sync assumes responsibility.
- Validate Cloud Sync on that isolated subset before expanding to additional OUs.
- Keep a record of which synchronization tool owns every production OU during the transition.
Smaller identity teams can gain an advantage here. A simple directory with clean OU boundaries may be a strong candidate for an early transition—but only if the team has documented those boundaries well enough to prove that objects won’t be managed twice.
When ‘Hold’ Is the Right Answer
The migration conversation can become political when a cloud-first roadmap is interpreted as an immediate requirement to abandon the existing tool. Microsoft has left an important off-ramp: if a needed feature is not yet supported by Cloud Sync, the tenant can continue using Connect Sync.
“Hold” is a valid, supportable decision when it’s based on a concrete dependency. It should not be an undocumented instinct. Capture the dependency, identify the affected objects or workflows, assign an owner, and review the feature comparison as Cloud Sync develops. A specific statement—“this configuration depends on capability X, which Cloud Sync doesn’t currently support”—is far stronger than a vague claim that the environment is too complex.
That distinction also protects teams from unnecessary redesign. There may be good reasons to simplify identity architecture, but a forced migration window isn’t automatically a good reason to remove a working dependency before Microsoft supports its replacement.
How We Got Here: The Long Road to Cloud-First Identity Sync
The shift from Connect Sync to Cloud Sync didn’t start in 2026. Microsoft’s hybrid identity tooling has been evolving for over a decade, from DirSync to Azure AD Connect, and then to Entra Connect Sync. Cloud Sync launched as a lightweight agent in 2021, initially supporting only a subset of scenarios. Over time, Microsoft has been adding capabilities that bring it closer to feature parity—group provisioning to Active Directory, support for larger directories, Source of Authority (SOA) switching, and Kerberos-based hybrid join.
Recent announcements signal that the transition is accelerating. In February 2026, Microsoft added Windows Server 2025 support for Connect Sync but explicitly recommended customers consider moving to Cloud Sync. By May 2026, new Cloud Sync features like AD group enforcement and expanded provisioning options were in preview, and the “Plan for change” notice formally kicked off the phased migration.
The strategy is unambiguous: Cloud Sync is becoming the preferred platform for hybrid identity synchronization. But the timeline for each tenant depends on its specific requirements—not on a single retirement date.
A Readiness Checklist for the July 2026 Migration Wave
Don’t wait for a notice to start. Here’s how to prepare now:
- Determine if your tenant is likely in the first wave. If your sync configuration uses only features listed as supported in Microsoft’s Cloud Sync comparison, and your directory isn’t unusually large, assume you could be notified soon. Otherwise, plan for a later wave.
- Run a full inventory. Document every sync rule, OU scope, attribute flow, and dependency. Include custom rules that were set up years ago and might be forgotten. Microsoft notes that migration complexity scales with the number of users, groups, custom rules, and OUs.
- Cross-reference with the Cloud Sync feature comparison. For each dependency, mark it as supported, unsupported, or needs testing. If even one critical dependency is unsupported, your answer is “hold” and you should document it.
- Design a pilot OU. Pick a self-contained, non-critical subset. Plan exactly how you’ll remove that OU from Connect Sync’s scope and assign it exclusively to Cloud Sync.
- Test thoroughly. Validate user sign-ins, password writeback, group memberships, device registration, and any downstream dependencies. Confirm that your helpdesk scripts and administrative tools still work.
- If a notice arrives and you’re not ready, request an exception. Microsoft says tenants that cannot migrate within their recommended transition window can request an exception. Have your readiness evidence ready—current requirements, Cloud Sync support status, pilot OU, test owners, and expected blockers—so you can explain why with evidence rather than a generic plea for more time.
Outlook: Watching Cloud Sync’s Capabilities Grow
Microsoft will continue expanding Cloud Sync’s feature set, and subsequent waves will target increasingly complex environments. Expect more in-product guidance, automated assessment tools, and possibly a deprecation timeline for Connect Sync once sufficient parity is reached. For now, the real dividing line is evidence. The teams that fare best won’t be those that migrate first or resist longest. They’ll be the ones that can show, object by object and OU by OU, which synchronization tool owns the environment and why. Start building that evidence today.