Microsoft Entra Cloud Sync Migration: An SMB Checklist

A directory migration can look successful while an employee still cannot reset a password, a finance group loses access, or a mailbox update stops reaching Active Directory. For an SMB, the important decision is not whether a newer synchronization tool exists. It is whether the current environment fits the supported migration path and whether someone can prove that essential work still functions afterward.

ITECS recommends a three-part decision: establish eligibility, test business dependencies, and retain a usable recovery path. Treat this checklist as a planning aid for your identity administrator or managed IT partner, not permission to experiment on production accounts.

Check the migration wizard’s limits, not just Cloud Sync’s capabilities

As checked on October 20, 2026, the guided tool accepts one AD forest, up to 2,000 in-scope objects, and additive OU inclusion with at most 30 included containers per domain. Custom sync rules, group filtering, custom UPNs, directory extensions, device sync, and unsupported writebacks block this path. Run it from the active Connect Sync server, not a staging server. Download the readiness report; do not bypass blockers. Microsoft’s guided migration requirements.

These are migration-tool restrictions, not a complete list of Cloud Sync product limitations. Microsoft’s broader feature comparison includes capabilities such as directory extensions and device synchronization. Product support does not mean the guided tool can transfer your existing configuration. Check the exact scenario rather than interpreting a feature-table checkmark as migration approval. Cloud Sync decision guide.

• Proceed to planning: the actual configuration passes readiness, its dependencies are understood, and test and recovery owners are available.
• Pause for remediation: a blocker has a documented, supported correction that does not remove a necessary business capability.
• Seek support or another supported path: the environment does not fit. Do not delete rules, narrow scope, or abandon writeback simply to make an assessment turn green.

Build a dependency register before scheduling cutover

Give each dependency a technical owner, a business owner, a test account, an expected result, and a recovery decision-maker. Count directory objects rather than employees. Record forests, domains, included OUs, users, groups, contacts, authentication methods, existing agents, synchronization rules, attribute mappings, and every writeback direction.

Then connect that inventory to everyday work: Microsoft 365 sign-in, licensed applications, group-based access, shared resources, password resets, and Exchange administration. Ask application owners which attributes their systems actually consume. An undocumented field used by payroll is a dependency even if most employees never see it.

Microsoft documents phased migration eligibility and organization-specific notifications. If your assigned window cannot be met, request an exception through Microsoft; approval is not automatic. Keep a dated blocker, business impact, responsible owner, and target resolution in your change record. Do not turn another tenant’s notification into your own deadline. Migration eligibility and exceptions.

Prepare privileged access, servers, backups, and deletion safeguards

Cloud Sync requires a non-guest Hybrid Identity Administrator; the guided tool also requires Domain Admin credentials for the selected forest’s provisioning-agent service-account setup. Microsoft recommends a domain-joined Windows Server 2025 or 2022 host; older versions have support qualifications. Server Core is unsupported. Check the documented .NET, TLS 1.2, directory-schema, firewall, proxy, and certificate-validation requirements. Protect the agent host as a control-plane asset, not an ordinary utility server. Agent prerequisites and hardening.

For an SMB, assign privileged work to named administrators for the approved window. Do not share administrative passwords in the migration ticket. Record how authorized staff will access the tenant if the on-premises environment becomes unavailable.

Export the current Connect Sync configuration to protected storage. Microsoft notes that changes made outside its wizard may require an on-demand export; an old automatic export may be incomplete. Preserve the original file rather than editing its JSON, and document settings outside the export’s coverage. Configuration export and recovery limitations.

Record accidental-deletion protection, the approved threshold, and a monitored quarantine-notification address. Cloud Sync can stop synchronization when the configured deletion threshold is reached. Group deletion protection does not, by itself, protect member objects from deletion. Investigate the cause before allowing deletions; do not raise a threshold merely to clear an alert. Accidental-delete prevention.

Our recommended evidence pack also includes the server recovery procedure, last successful sync, scope exports, installed versions, responsible contacts, and a protected copy available if the primary administration workstation fails.

Test before activation, then verify the staging handoff

The wizard installs/registers the provisioning agent and prepares disabled Cloud Sync configurations while Connect Sync remains the exporter. Activation enables Cloud Sync and moves Connect Sync into staging. The wizard checks aggregate object totals and job health, not every identity or dependency. Transfer and activation behavior.

Use Provision on Demand with approved representative users and groups before activation, covering each migrated domain. Read the detailed result, including scope and attribute outcomes. This feature applies configuration to an individual object; it is not merely a read-only readiness scan. Configuration and on-demand testing.

Choose cases that could reveal a meaningful difference: a new hire, an existing employee, a disabled account, a group controlling a business application, and an account with the organization’s less-common attributes. Use controlled test identities where possible. Record before-and-after evidence without putting passwords or unnecessary personal data in the report.

Do not confuse a successful object test with permission to make both synchronization engines active for the same identities. Microsoft does not support simultaneous synchronization ownership of the same objects. A manual scoped pilot is a separate migration procedure, not an improvised addition to the guided wizard. Coexistence guidance.

Validate password and Exchange writeback separately

Password hash synchronization and password writeback solve different problems. If employees rely on self-service password reset, verify the Cloud Sync writeback configuration, tenant SSPR settings, service-account permissions, and applicable licensing. Microsoft lists an Entra ID P1 prerequisite for this scenario and documents supported and unsupported reset operations. A successful reset through one interface does not establish that every administrator tool works the same way. Cloud Sync password-writeback requirements.

For your acceptance test, have the authorized tester use the reset workflow employees will actually use, then verify the intended on-premises result and subsequent sign-in. Keep password values out of screenshots and tickets. Record both success and the expected rejection of an unauthorized action.

Exchange hybrid writeback needs its own proof. Microsoft requires the appropriate Exchange schema and agent support. Its on-demand process first provisions the user, allows Exchange Online attributes to populate, and then tests writeback. Attribute writeback is not a mailbox or message migration. Confirm the precise configuration and attributes your environment depends on rather than treating “Exchange works” as a sufficient result. Exchange hybrid writeback.

Ask the messaging owner to approve representative attribute and administration tests. Do not change mailbox source-of-authority settings or enable unrelated writeback capabilities as an incidental part of this project.

Keep Connect Sync for two weeks and make rollback someone’s job

Microsoft requires keeping Connect Sync installed for a two-week post-migration validation period. If activation fails, follow wizard recovery; do not manually delete, disable, or retag migration-owned resources. Validation and recovery requirements.

Two weeks is a minimum observation requirement, not an automatic uninstall appointment. ITECS recommends withholding removal until the identity owner and affected business owners accept the evidence. Include at least one real joiner/change/leaver cycle or a controlled equivalent, scheduled application activity, password reset, and any required Exchange writeback.

• Define stop conditions: unexpected deletions, unexplained membership changes, persistent provisioning errors, broken sign-in, or a failed critical workflow.
• Name the rollback lead: one person authorizes the supported recovery sequence and coordinates with Microsoft when required.
• Rehearse the recovery plan: know how to recover the prior configuration without overlapping active exporters. Do not assume reinstalling software reverses directory changes already made.
• Retain evidence: readiness results, configuration snapshots, test outcomes, job status, exceptions, and the final go/no-go decision.

Scope changes deserve particular care. Microsoft warns that prematurely removing objects or OUs from Connect Sync scope during migration can export reference deletions, including group-membership removals. “Cleanup” is therefore a controlled change, not housekeeping for an administrator to perform early. Migration scope warning.

Agree on service-desk handoff and completion evidence

Before cutover, tell the help desk what is changing, which symptoms warrant escalation, who owns identity recovery, and how to distinguish synchronization issues from application incidents. Tell employees what to report without asking them to send passwords or approve unexpected authentication prompts.

During observation, review provisioning failures, quarantine notifications, group membership, sign-in outcomes, and writeback tests. Separate “no reported tickets” from positive verification. Maintain an exception list with an owner and next review date; do not silently accept an unexplained mismatch because aggregate counts happen to agree.

For a managed or co-managed environment, the handoff should identify who watches alerts after hours, who can authorize changes, who preserves records, and who closes the migration. The business owner approves operational readiness; the administrator supplies evidence. Neither should have to guess what the other has checked.

If you need help establishing that division of responsibility, explore ITECS Microsoft 365 consulting or discuss your identity migration requirements. Start with an inventory and a supported plan, not a promise that every configuration can move unchanged.

Prepared by ITECS Team with AI-assisted research and drafting. Microsoft documentation was checked on October 20, 2026. This is a planning guide, not a tenant assessment or a substitute for the current supported migration instructions. Recheck eligibility, feature support, and prerequisites before approving a production change.