Cloud Sync Migration: Validate Every Object

A directory migration can finish with the expected number of objects and still leave a project group without the right members. Counts are useful, but identity continuity and relationships need their own checks.

Microsoft’s 12 October Entra roundup includes the generally available guided Cloud Sync migration experience.

Use the wizard to reduce configuration work, then validate the parts of the directory that staff and applications depend on.

Check the tool’s scope before planning the cutover

The migration-tool guide currently limits the guided path to eligible migration waves and supported configurations. Its documented starting scope includes one forest, no more than 2,000 in-scope objects and limited OU inclusion complexity. Several features, including custom synchronisation rules and device synchronisation, can block that guided path.

These are tool eligibility limits, not a complete statement of what Cloud Sync itself can do. The platform comparison describes broader capabilities, including separately configured device synchronisation. Keep the two assessments distinct.

Export the existing configuration and make a dependency record before choosing a date. Include password hash synchronisation, writeback, group memberships, manager relationships, custom attributes and applications that rely on those attributes.

The earlier Connect upgrade article addresses maintaining the existing service. Moving synchronisation authority is a separate change and needs its own approval and recovery plan.

Choose a representative validation set

Use named test objects whose expected state is known. Include a normal employee, a recently changed employee, a user with an important group membership, a group containing the pilot users and any supported writeback scenario used by the organisation.

For each object, record its identifiers in the source and target, the expected attributes and the relationships that matter. Avoid collecting unnecessary personal data in the migration workbook; the check needs comparison values and object references, not an unrestricted directory export.

Ask application owners for a small number of meaningful tasks. Opening an application with an established session can hide a broken identity dependency. Include a fresh authentication and a task requiring the relevant group or role.

A representative sample does not prove every object is correct. It gives you an informed set of checks to combine with counts, provisioning errors and wider reconciliation.

Understand what the wizard validates

The guided tool creates configurations, runs preactivation checks and changes which synchronisation path is active. Microsoft says its postactivation comparison checks an aggregate object total, job health and Connect staging state. It does not automatically validate individual identities, memberships or writeback.

Use that documented boundary to add your own acceptance record:

Capture the before-and-after evidence, not only a green final status. Investigate unexpected changes before broadening the scope.

Do not improvise coexistence

If the guided route is unsuitable, use Microsoft’s phased migration procedure. Its current guidance warns against removing pilot OUs and referenced objects from Connect scope during coexistence, because doing so can export reference deletions. It describes specific no-flow rules for the supported approach.

That is not a safe area for a shortened generic command sequence. Use the documented procedure against a reviewed configuration, and understand which engine can export each object or reference at each stage.

Likewise, do not restart both systems as active exporters just because an application reports a problem. First identify the failed attribute or relationship, establish the current authority and choose the supported recovery action.

Keep the old service until the evidence is complete

The guided migration documentation requires a two-week validation period with Connect retained. Plan ownership for that period. A server left installed but unmonitored is a weak recovery provision.

Agree the events that stop the migration: unexpected deletes, duplicate identities, unexplained membership differences or failed business-critical writeback. Keep configuration changes controlled so the comparison remains interpretable.

Decommission only after the validation record is accepted, the recovery plan is no longer needed and monitoring has a permanent owner. The useful outcome is a directory whose behaviour is understood, with fewer management dependencies and a clear record of how continuity was proved.

References

• Microsoft — Microsoft Entra October 2026 announcement, published 12 October 2026. Accessed 17 October 2026.
• Microsoft — Migrate to Cloud Sync with the migration tool. Accessed 17 October 2026.
• Microsoft — Cloud Sync migration decision guide. Accessed 17 October 2026.
• Microsoft — Migrating from Connect to Cloud Sync. Accessed 17 October 2026.