Entra Connect Sync to Cloud Sync: what the guided migration covers and what stays behind

Samantha Kloos-Kilkens
Oct 14, 2026 · Samantha Kloos-Kilkens

Since Entra Connect Sync 2.6.91.0 there is a "Transition to Cloud Sync" task in the Connect wizard, and Microsoft is moving tenants over in waves. The tool is deliberately narrow and most enterprise environments will fall outside it, so this post is about the rest: which Connect Sync features Cloud Sync handles differently or not at all, what to inventory first, and how to run the move so there is still a way back.

Two parallel steel bridges over a river, seen from below Photo: Getty Images on Unsplash

What Microsoft shipped in September

The guided migration arrived in Connect Sync 2.6.91.0, released on 16 September 2026 (with hotfix 2.6.92.0 a week later for a Pass-through Authentication registration bug in the wizard). It is listed without a preview label and only for the Azure public cloud. It follows the plan-for-change Microsoft published in the April What's new roundup: tenants are notified per wave through Message Center, Connect Health and email, starting with tenants whose configuration Cloud Sync already fully supports.

The migration tool documentation describes the flow. You start it on the active Connect server (it won't run on a staging server), sign in with Hybrid Identity Administrator and supply Domain Admin credentials for each forest, which the wizard uses to set up the gMSA for the provisioning agent. It runs a readiness review, installs and registers the provisioning agent, creates one Cloud Sync configuration per in-scope domain in a disabled state, and asks you to run Provision on Demand against a representative object per domain. Activation then enables Cloud Sync and puts Connect Sync into staging mode. The validation page compares exactly one aggregate "Total Objects" count between the two engines plus job health; Microsoft states explicitly that it does not validate individual objects, memberships or writeback. Connect Sync has to stay installed for a two-week validation period.

Read the eligibility limits carefully: one forest, no more than 2,000 in-scope objects, inclusion-based OU scoping with at most 30 included containers per domain, and none of the blocking features (custom sync rules, group filtering, a custom UPN, directory extensions, device synchronization, unsupported writeback). What it transfers is user and group sync, password hash sync, password writeback, Exchange hybrid writeback and domain/OU scoping. If you are blocked and get a deadline in your notification anyway, the documented route is a support request for a temporary exception, with your readiness report and a migration plan attached. In practice the guided tool is for small, clean tenants, and everyone else ends up on the manual route, where the capability differences below decide the plan.

What Cloud Sync handles differently

I used the comparison table in the decision guide as it stands after the 6 October update, together with the supported scenarios table. This list has changed a lot over the years, so check it again when you read this. For a typical enterprise deployment these are the items that matter:
  • Sync rules. Connect's rule engine (precedence, join rules, scoping filters, expression-based transformations) has no equivalent; Cloud Sync offers attribute mappings with the expression builder. Out-of-band reconciliation isn't supported either.
  • Filtering. OU scoping works in both. Attribute-based filtering is "Limited" in the decision guide and simply not supported in the scenarios table, so plan on the stricter reading. Group-based filtering in Connect blocks the guided tool.
  • Scale. Cloud Sync supports 150,000 objects per AD domain and groups up to 50,000 members, against 250,000 members in Connect.
  • Multi-forest. Cross-forest references and merging attributes from multiple domains are Connect-only, and the account forest plus resource forest Exchange topology is listed as Connect-only. Disconnected forests are where Cloud Sync is actually ahead.
  • Devices. Device sync for hybrid join became generally available in Cloud Sync at the end of September and has to be enabled separately, but the guided tool still treats it as a blocker. Device writeback is not coming to Cloud Sync, and the scenarios table lists Windows Hello for Business as Connect-only, which I read as the certificate trust deployments that depend on device writeback.
  • Authentication. Cloud Sync doesn't configure PTA or AD FS. PTA and Seamless SSO keep working after migration and, according to Microsoft, remain manageable through the Connect Sync configuration wizard. If you use them, the Connect binaries don't disappear entirely.
  • Source anchor. Cloud Sync uses ms-DS-ConsistencyGuid with fallback to objectGUID and there is no supported way to change that (Cloud Sync FAQ). A Connect installation that was set up years ago with another attribute as sourceAnchor has to solve that first.
Exchange hybrid attributes, directory extensions, password writeback and group writeback v1 are marked as supported in both. Note the mismatch on directory extensions: the platform supports them, but the guided tool won't carry them over.

What to inventory before you start

What I would want on paper first is the custom rule set. Over the years Connect servers tend to collect rules that nobody remembers adding: a cloudFiltered rule from a cleanup project, a cloned "In from AD - User Join" with a different UPN expression, a JoinNoFlow rule from an old group writeback migration. Out-of-box rules carry an ImmutableTag and custom rules don't, which gives a reliable filter: 
# Run on the active Connect Sync server
Import-Module ADSync

$connectors = @{}
Get-ADSyncConnector | ForEach-Object { $connectors[$_.Identifier] = $_.Name }

$rules = Get-ADSyncRule

# Custom rules: no ImmutableTag
$rules | Where-Object { [string]::IsNullOrEmpty($_.ImmutableTag) } |
    Sort-Object Direction, Precedence |
    Select-Object Precedence, Direction, Name, LinkType, Disabled,
        SourceObjectType, TargetObjectType,
        @{ Name = 'Connector'; Expression = { $connectors[$_.Connector] } } |
    Export-Csv .\custom-sync-rules.csv -NoTypeInformation

# Out-of-box rules that were switched off, usually replaced by a clone
$rules | Where-Object { $_.ImmutableTag -and $_.Disabled } |
    Select-Object Precedence, Direction, Name
For each custom rule, Export in the Synchronization Rules Editor gives you the full PowerShell including scoping filters and transformations; that is what you translate into Cloud Sync attribute mappings or decide to drop. Also export the full configuration via "View or Export Current Configuration" in the wizard: the import/export documentation points out that only wizard changes are exported automatically, so anything done in the rules editor or PowerShell is missing from the JSON files in %ProgramData%\AADConnect until you export on demand.

The second check is the source anchor on groups. The pilot tutorial notes that Connect Sync doesn't populate ms-DS-ConsistencyGuid for groups by default, and Cloud Sync needs it to hard match: 
Get-ADGroup -Filter * -SearchBase 'OU=Pilot,DC=contoso,DC=com' -Properties 'mS-DS-ConsistencyGuid' |
    Where-Object { -not $_.'mS-DS-ConsistencyGuid' } |
    Select-Object Name, DistinguishedName
Add your largest groups, objects per domain, device writeback, and whether PTA or federation is configured through the Connect wizard.

Running the migration side by side

If the tool says you're blocked, the manual migration guidance and the pilot tutorial describe the coexistence model: an inbound rule that sets cloudNoFlow to True for the pilot scope, an outbound rule with link type JoinNoFlow scoped on cloudNoFlow, repeated for users, groups and contacts. Two details are easy to miss. JoinNoFlow is not a read-only mode: it stops object adds, deletes and non-reference attribute updates, but member and manager updates still flow. And you must not remove the pilot OU or related objects from Connect Sync scope during coexistence; that drops the connector space objects and exports reference deletes, which shows up as group memberships disappearing in Entra ID. Scope removal comes last, per batch, after Cloud Sync is demonstrably authoritative for the objects and their references.

To compare counts after each batch I use plain Microsoft Graph PowerShell rather than the sample script on the migration page: 
Connect-MgGraph -Scopes 'User.Read.All'
$ou = 'OU=Pilot,DC=contoso,DC=com'
$synced = Get-MgUser -All -Filter 'onPremisesSyncEnabled eq true' `
    -Property id,userPrincipalName,onPremisesDistinguishedName
($synced | Where-Object { $_.OnPremisesDistinguishedName -like "*,$ou" }).Count

Having a way back

For the manual route the rollback is documented: disable the Cloud Sync configuration and disable the custom no-flow rules, which triggers a full sync on the connectors. For the guided tool there is no rollback procedure on the tool page. The migration FAQ says you can roll back because Connect sits in staging mode, while the troubleshooting table says that if activation fails you should follow the wizard's recovery instructions and not disable or delete the Cloud Sync resources the migration created.

My approach is to treat the two-week window like a classic staging server swap and rehearse it in a test tenant: disable the Cloud Sync configurations first so only one engine exports, run an initial sync cycle on Connect, review pending exports with csexport and CSExportAnalyzer, then disable staging mode. One effect to plan for: password hash sync resumes from its last watermark when staging mode is disabled, and after two weeks in staging the catch-up can take hours, during which recently changed passwords don't work in the cloud yet.

Two other deadlines running alongside

MC1237727 (February 2026) announced that Connect Sync versions below 2.5.79.0 would stop on 30 September 2026. On 30 September, the day of the deadline itself, Microsoft moved that to 7 April 2027 on the hardening page (the MC post itself wasn't updated), and a day later it raised the bar: the page now requires 2.6.84.0 or later with application-based authentication. If your tenant isn't in an early wave, you'll upgrade Connect before you leave it, and 2.6.92.0 includes the transition task.

The hard match hardening applies to both engines regardless of client version: since 1 July 2026 (the privileged-role part was announced for 1 June) a hard match is blocked when the target account already has onPremisesObjectIdentifier set, or holds or is eligible for a privileged role. Cloud Sync takes over existing objects through hard match, so any synced account with a privileged role in the pilot scope is something to test explicitly, and this is a good reason not to combine the sync migration with a domain restructure or forest move.

Where to start

Run the rule inventory above on your active Connect server this week, export the configuration, and check Message Center and Connect Health for a wave notification. If the custom rule list is empty and you're under the limits, the guided tool is probably yours; if not, pick one pilot OU and set up the no-flow rules in a test environment first.

Update October 2026: On 21 October Microsoft rewrote the migration FAQ and removed the sentence that you can roll back; it now only says the tool puts Connect Sync in staging mode and that Connect Sync stays installed for the validation period. Treat the staging swap above as your own fallback to rehearse, not as a supported rollback, and for a failed activation follow the wizard's recovery instructions.

Sources

Written by an Argus IT expert

Want an expert like this in your team, or work like this yourself in security, IAM or cloud?

Get in touch Work at Argus IT

Stay in the Loop

Subscribe to our newsletter for a friendly nudge whenever we publish a new article or have news to share.