Migrating from Entra Connect Sync to Cloud Sync without an outage

The reason to move to Cloud Sync is the reason described in Entra Connect vs Cloud Sync: no pet server, active-active agents, and Microsoft's investment going one way. The reason people put it off is the fear that thousands of users will be deleted and recreated on the day. Done in the right order, no object is deleted, no user notices, and the whole thing can be paused at any step. Done in the wrong order, the deletion threshold in Connect is the only thing standing between you and a very long weekend.

Step 0: can you go at all?

Cloud Sync cannot do everything Connect does. Before planning anything, check the tenant for the features that block a full migration:

• Pass-through authentication or federation as the sign-in method. Cloud Sync assumes password hash sync. Moving to PHS is a separate project and must finish first.
• Exchange hybrid writeback, device writeback, or the legacy group writeback feature. Cloud Sync supports a different group-provisioning-to-AD model; if you rely on the older writeback behaviours, check the current support matrix before assuming.
• Custom sync rules that transform attributes in ways Cloud Sync's attribute mapping and expression language cannot reproduce. Export Connect's rules and go through them one by one. Most are dead weight from a migration years ago; a few will be load-bearing.
• Directory extension attributes, very large groups, or objects with many members — Cloud Sync has its own limits here, and the documentation lists them.
• Filtering by attribute rather than by OU. Cloud Sync scopes by OU and by group; attribute-based scoping filters need reworking.

If any of these are true and cannot be resolved, the honest outcome is either a partial migration (Cloud Sync for some forests or OUs, Connect for the rest — supported and common in multi-forest tenants) or staying on Connect. Both are fine. Discovering it halfway is not.

Also confirm the source anchor. Connect should be using ms-DS-ConsistencyGuid. Cloud Sync uses the same anchor, which is what allows it to take over existing objects instead of creating duplicates. If your Connect installation is old enough to be anchored on objectGUID, migrate the anchor in Connect first.

Step 1: install the agents, configure, verify — and do not enable

Install the provisioning agent on two or more servers (Windows Server, outbound HTTPS only, no inbound). Register them in the Entra admin center under Cloud Sync. Then create a configuration for the forest, scoped to a single pilot OU that Connect also currently syncs, with the attribute mapping matched to what Connect does today.

Use the configuration's Provision on demand feature to run one user through the Cloud Sync mapping and compare the result with the same user's current Entra attributes. This is the point at which mapping differences show up cheaply. Fix them until a provisioned user is identical.

Leave the configuration disabled.

Step 2: hand the pilot OU over

This is the step with sequencing rules, and they exist to prevent Connect from deleting the users you are about to move.

1. In Connect, stop the scheduler: Set-ADSyncScheduler -SyncCycleEnabled $false.
2. In Connect's wizard, remove the pilot OU from the Connect scope (Domain and OU filtering). Do not run a sync yet.
3. In the Entra admin center, enable the Cloud Sync configuration for the pilot OU. Cloud Sync performs its initial cycle and matches the existing Entra users by source anchor, taking over ownership. Confirm in the provisioning logs that users show as updated, not created.
4. Only now run a full import and full sync on Connect (not an export yet): Start-ADSyncSyncCycle -PolicyType Initial. In Synchronization Service Manager, check the pending exports on the Entra connector. Because the pilot users are now owned by another provisioning source, they should not appear as deletions. If they do, stop: something in the anchor or scope is wrong, and the deletion threshold is your safety net — do not disable it.
5. Re-enable the Connect scheduler.

Then leave it for a week. Change a user's phone number, add someone to a group, disable an account in the pilot OU, and confirm each reaches Entra via Cloud Sync within its cycle (a few minutes). Reset a password if you use password hash sync. Test SSPR writeback if you have it.

Step 3: repeat until Connect owns nothing

Move OUs in batches — sites, departments, whatever is meaningful — repeating step 2 each time. Batches of a few hundred users keep the pending-export review readable. Groups follow the users; move an OU that holds groups only after every member's OU has moved, or membership will resolve oddly for a cycle.

Cloud Sync configurations can also scope by group rather than OU, which some organisations use to cut across an awkward OU structure. Either works; do not mix both for the same objects.

At the end, Connect's scope is empty except for whatever you deliberately left it — often nothing.

Step 4: switch Connect off, in stages

1. Set Connect to staging mode via the wizard. It keeps running, exports nothing. Leave it a week; if anything unexpected surfaces, switching back is minutes.
2. Uninstall Entra Connect. The tenant's directory synchronisation flag stays on, because Cloud Sync is a directory sync source; you are not disabling sync, only removing one engine.
3. Delete the Connect server's sync service account from Entra, and the on-prem AD DS Connector account. Remove the Connect server from any Conditional Access exclusions it lived in.
4. Decommission the server. Keep the configuration export somewhere findable for a year.

What can go wrong, and what needs support

The failure mode is always the same: a scoping change on Connect that looks like a mass delete. The accidental deletion threshold catches it, and the correct response is to investigate, never to disable the threshold to "get past it". If users were soft-deleted, they are recoverable for 30 days from Entra's deleted users, with mailboxes and OneDrives intact.

Microsoft support is rarely needed. The exception is a tenant where directory sync was previously disabled and re-enabled, or where objects have hard-matching conflicts from an old migration; those surface as provisioning errors that support can sometimes clear faster than you can.

Downtime: none for users. The only visible effect during the migration is that a change to a user in an OU mid-handover may take one extra sync cycle to arrive.