Moving from On-Premises Active Directory to Microsoft Entra ID Hybrid: A Pre-Migration Checklist

Most problems in a move to Microsoft Entra ID hybrid are not caused by the sync tool. They come from what was already in the directory: a UPN suffix that cannot be verified, duplicate proxy addresses, a sync server nobody owns, or an authentication method chosen because it was the default in the wizard. This checklist is the order I work through before installing anything. It is a planning aid, not a substitute for testing in your own environment.

1. Decide what "hybrid" means for this organization

Write down the goal in one sentence before touching a server. Typical goals are Microsoft 365 sign-in with existing passwords, single sign-on for cloud apps, device registration, or a staged retirement of on-premises Exchange. Each goal changes the design. If the aim is only to give a small office Microsoft 365 mailboxes, a heavy design is probably the wrong answer.

Record these facts first:

• Number of forests and domains, and which ones will synchronize.
• Whether Exchange, AD FS, or third-party identity providers are already in place.
• Which applications authenticate against Active Directory directly and will not move.
• Who owns the decision to change the sign-in method.

2. Check the health of Active Directory itself

Synchronization copies whatever is in the directory, including its faults. Run dcdiag and repadmin /replsummary on your domain controllers, confirm replication is clean, and check that DNS and time synchronization are healthy. Microsoft's prerequisites page lists the supported operating systems, forest requirements and the point at which older domain controllers may need a paid support program, so read the current version rather than relying on memory: Microsoft Entra Connect prerequisites.

Clean up stale objects now. Disabled accounts from former staff, old service accounts and unused computer objects will otherwise be evaluated for sync and may clutter the tenant.

3. Fix identifiers before they sync

User principal names are the most common blocker. The UPN suffix users sign in with must be a domain you can verify in the Microsoft 365 tenant. A suffix such as .local cannot be verified, so affected users will receive a default onmicrosoft.com sign-in name unless you add and assign a routable suffix first.

Also check:

• Duplicate mail and proxyAddresses values, which cause sync errors.
• Invalid characters or missing values in attributes such as displayName.
• Mail nicknames and SMTP addresses that conflict with existing cloud objects.

Microsoft provides IdFix for this. It queries the directory for objects with errors and lets you correct them. Run the query first and review the results with the people who own those accounts, then apply changes in batches and query again. Microsoft publishes the tool on GitHub: IdFix.

4. Check what already exists in the cloud

If the tenant has been in use, there may already be cloud-only users or contacts that match on-premises people. Matching on an existing object can merge identities or fail with a conflict. List the cloud-only accounts, compare them with the directory by UPN and primary SMTP address, and decide for each whether it will be matched, renamed or removed. Do this before the first synchronization, not after.

5. Choose the sign-in method deliberately

The three common options are password hash synchronization, pass-through authentication and federation with AD FS. They differ in where authentication is evaluated, what must stay online, and how much infrastructure you operate. Microsoft's comparison is the right place to start: Choose the right authentication method.

Questions that decide it:

• Can sign-in depend on on-premises servers being reachable?
• Is there a compliance requirement that rules out one method?
• Do you already run AD FS for other reasons, and who maintains it?
• What is the plan if the on-premises environment is unavailable?

Whichever you pick, plan for a fallback. Password hash synchronization is often kept enabled alongside another method as a recovery option, but confirm that choice against your own security requirements.

6. Choose the sync tool and plan the server

Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync are different products with different capabilities. Confirm in the current documentation which one supports your topology, such as multiple forests or disconnected domains, before you decide. Then plan:

• A dedicated, patched, domain-joined server with a named owner, not a shared utility server.
• A second server in staging mode if you need a quick path to recover.
• The service accounts and permissions the installer needs, recorded and reviewed.
• Backup of the sync configuration after the first successful run.

Use organizational unit or attribute filtering so only intended objects sync. Starting with a pilot OU is safer than syncing the whole forest on day one.

7. Plan devices separately

Microsoft Entra hybrid join registers domain-joined Windows devices in the tenant and is a separate piece of work from user sync. Read Configure Microsoft Entra hybrid join and decide whether you need it now, or whether cloud-joined devices are the long-term direction. Do not enable it casually; it touches every managed device.

8. Prepare Conditional Access and MFA before users move

When sign-in moves to the cloud, accounts become exposed to internet password attacks that on-premises networks were shielding. Decide on multifactor authentication enrolment, emergency access accounts and your baseline Conditional Access policies before the first user is licensed. Start new policies in report-only mode so you can see their effect.

9. Write the pilot and rollback plan

A pilot group of IT staff and a few willing users should go first. Define what success looks like: sign-in works, mail and Teams work, password changes propagate, and the helpdesk knows what to say. Write down how you would stop synchronization, how you would reverse a sign-in method change, and who can approve either. A rollback plan that has never been read by anyone but its author is not a plan.

10. Prepare people and operations

Tell users what will change and when. Brief the helpdesk. Add the sync server to monitoring and patching, and decide who reviews sync errors and how often. Microsoft Entra Connect Health can help with monitoring where licensing allows; check the current requirements first.

Limits and when to get help

This list does not replace a design for your own environment. Multi-forest estates, existing federation, Exchange hybrid, or any tenant that already holds a lot of cloud-only data deserve a second pair of eyes before the first sync, because some mistakes are slow to unwind. Product behavior and licensing change; verify each step against current Microsoft documentation.