Migration Connect-Sync to Cloud-Sync

GUENTHER, Kay 0 Reputation points
2026-11-05T10:55:29.4133333+00:00

How do we prevent device export from Connect Sync for a pilot OU without triggering a delete export, and then pass the same hybrid join device objects to AD2AADDeviceSync? The single test successfully updated the existing object.

Exchange | Hybrid management
Exchange | Hybrid management

The administration of a hybrid deployment that connects on-premises Exchange Server with Exchange Online, enabling seamless integration and centralized control.

0 comments No comments

1 answer

Sort by: Most helpful
  1. Kristen Tran 2,785 Reputation points Independent Advisor
    2026-11-05T11:26:42.2566667+00:00

    Hi Kay,

    Thank you for providing the details.

    For the pilot migration, I would not recommend removing the pilot device OU from Microsoft Entra Connect Sync scope simply to stop Connect Sync from exporting those devices. Microsoft specifically warns that removing objects or OUs from Connect Sync scope can remove their connector-space/metaverse representation and potentially result in deletion or reference-removal exports to Microsoft Entra ID.

    For reference: Migrate to Microsoft Entra Cloud Sync

    Microsoft's documented coexistence approach for a phased migration is to keep the pilot objects within Connect Sync scope while preventing Connect Sync from exporting normal changes. The documented manual migration uses cloudNoFlow together with an outbound JoinNoFlow rule for this purpose: Tutorial: Migrate to Microsoft Entra Cloud Sync for a synced Active Directory forest

    However, there is an important distinction for your scenario: Microsoft's published manual migration procedure documents this approach for users, groups, and contacts, but it does not currently document an equivalent custom JoinNoFlow procedure specifically for device/computer objects. Therefore, I would not recommend adapting those synchronization rules to devices in production without confirmation from Microsoft Support.

    For the Cloud Sync side, device synchronization is supported through the AD2AADDeviceSync job in an AD-to-Microsoft Entra ID Cloud Sync configuration. Validate the existing Service Connection Point (SCP), enabling device synchronization, and testing devices before wider deployment.

    Reference: Configure device sync with Microsoft Entra Cloud Sync

    Since your first test updated the existing object successfully, I would suggest expanding the pilot to several representative devices and confirming that Cloud Sync continues to update the same Microsoft Entra device objects without creating duplicates. Before changing Connect Sync's device export behavior, I would also recommend opening a Microsoft Support case to confirm the supported device-specific handoff method, including the appropriate rule/scoping configuration and rollback procedure.

    One additional point is that although Cloud Sync supports device synchronization, device synchronization is currently a blocker for Microsoft's guided migration tool, so this scenario should not be treated as equivalent to the guided migration workflow.

    For more information, please refer to Migrate to Microsoft Entra Cloud Sync with the migration tool

    I hope this helps clarify the safest approach for the pilot. If you have any questions, please let me know.

    Best regards,

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.