Hybrid Identity Architecture Patterns: AAD Connect vs Cloud Sync

The Identity Foundation Problem

Every Microsoft 365 project depends on identity. If the identity layer is wrong, everything built on top of it inherits those problems — Conditional Access, Intune, Exchange Online, Defender. It does not matter how well you configure those services if the underlying sync is producing malformed objects, mismatched UPNs, or stale accounts.

I have seen Exchange migrations fail because the UPN suffix wasn't added to AD before the migration started. I have seen Conditional Access device compliance policies break because hybrid join was misconfigured and devices weren't registering correctly. All of these failures trace back to the identity design.

Get it right first.

When to Use Entra ID Connect vs Cloud Sync

This is the most common architecture question I get asked. The answer is almost always determined by one constraint:

Do you need Exchange hybrid writeback?

If yes: Entra ID Connect (formerly Azure AD Connect). If no and you're decommissioning on-premises: Cloud Sync is worth serious consideration.

The full decision matrix:

| Requirement | Entra ID Connect | Entra ID Cloud Sync | |---|---|---| | Exchange hybrid (msExch attributes) | ✅ Required | ⚠️ Limited support | | Multi-forest, single tenant | ✅ Full | ✅ Supported | | Group writeback | ✅ V2 | ⚠️ V2 only | | Device writeback | ✅ | ❌ | | Disconnected forests | ⚠️ Complex | ✅ Native multi-agent | | On-premises decommission path | ❌ Agent stays | ✅ Cloud-managed | | Password hash sync | ✅ | ✅ | | Pass-through authentication | ✅ | ❌ | | Seamless SSO | ✅ | ❌ |

The practical rule: if you are migrating to Exchange Online and need hybrid co-existence during the migration window, use Entra ID Connect. If you are a net-new tenant, a small organisation, or you have disconnected forests you want to consolidate, Cloud Sync is the simpler long-term architecture.

UPN Normalisation: The Pitfall That Stalls Migrations

UPN normalisation is consistently underestimated. Organisations create users with internal domain suffixes — user@corp.internal, user@company.local — that are not internet-routable and cannot be used as Microsoft 365 identities.

The fix is straightforward in theory:

1. Add the public domain as an alternate UPN suffix in Active Directory Domains and Trusts
2. Update userPrincipalName on affected user objects
3. Verify that Entra ID Connect picks up the changes and syncs correctly
4. Update authentication dependencies (service accounts, Kerberos delegations, application configs)

In practice, step 4 is where migrations stall. Service accounts configured with internal UPNs, Kerberos SPNs tied to the old suffix, Line-of-business applications using the internal UPN for authentication claims.

Audit before you touch anything:

# Find all users with non-routable UPN suffixes
$routableDomains = @("contoso.com", "contoso.onmicrosoft.com")

Get-ADUser -Filter * -Properties UserPrincipalName | Where-Object {
    $suffix = $_.UserPrincipalName.Split("@")[1]
    $routableDomains -notcontains $suffix
} | Select-Object SamAccountName, UserPrincipalName, DistinguishedName |
    Export-Csv -Path ".\upn-normalisation-candidates.csv" -NoTypeInformation

Run this before any migration scoping conversation. The number of affected accounts shapes the entire project timeline.

Staged normalisation approach:

Never normalise all UPNs at once. The change affects authentication for every affected user and every application that reads UPN from AD or the token.

1. Normalise IT accounts and service accounts first — they can self-recover faster
2. Department by department, with a 48-hour validation window after each batch
3. Document every service account with its dependencies before changing it
4. Keep a rollback script ready: Set-ADUser -UserPrincipalName $oldUPN

Hybrid Join vs Entra ID Join: Device Identity Strategy

Device identity requires a clear decision before you start Intune deployment. The two primary states for Windows devices are:

Entra ID Hybrid Join — The device has both an on-premises AD computer account and an Entra ID device identity. Requires line-of-sight to domain controllers during registration. Suitable for existing domain-joined estates being migrated incrementally.

Entra ID Join — The device is joined only to Entra ID. Managed through Intune. No AD dependency. The target state for new devices provisioned via Autopilot.

The strategic direction for almost every organisation is Entra ID Join for new devices, Hybrid Join as a transitional state for existing domain-joined machines, and a deprecation plan for the on-premises AD dependency.

Hybrid join prerequisites:

# Verify SCP (Service Connection Point) is configured in AD
$scp = Get-ADObject -SearchBase "CN=Configuration,DC=contoso,DC=com" `
    -Filter { Name -eq "62a0ff2e-97b9-4513-943f-0d221bd30080" } `
    -Properties *

$scp.Keywords  # Should contain azureADName and azureADId

If the SCP is missing or misconfigured, devices will never register. This is the most common hybrid join failure and it takes 2 minutes to verify.

Staged Migration: Identity First, Everything Else Second

The correct sequencing for a Microsoft 365 migration:

1. Identity sync validated — All users syncing correctly, UPNs routable, no sync errors in Entra Connect Health
2. Authentication methods deployed — MFA registered for all users before any service goes cloud
3. Device identity strategy agreed — Hybrid join or Entra join path defined for each device segment
4. Conditional Access in report-only — Policies defined and running in report-only for 14 days minimum before any service cutover
5. Exchange migration — Starts only after identity is stable

Skipping step 1 and going straight to Exchange migration is the most reliable way to guarantee a failed cutover. You cannot fix identity problems while 50 concurrent mailbox migrations are running.

Design Decisions That Matter Early

Most hybrid identity problems are not caused by sync technology. They are caused by unresolved design decisions that get postponed:

• Source of authority for core attributes. Decide up front whether AD remains authoritative for UPN, mail, proxyAddresses, and group ownership during the transition.
• Authentication path. PTA, password hash sync, and federation have different operational footprints. Choose based on resilience and operating model, not habit.
• Device end state. If the target state is Entra ID Join, do not design a multi-year architecture around hybrid join as if it were permanent.
• Directory hygiene threshold. If duplicate, disabled, or orphaned objects are widespread, a clean-up workstream is part of the architecture, not a side task.

These decisions set the project shape. If they are left ambiguous, every downstream workstream starts making its own assumptions.

Common Failure Points in Hybrid Identity Programmes

The recurring enterprise failures are predictable:

• UPN change without dependency mapping. Applications, scripts, scheduled tasks, and claims rules often still depend on the old sign-in identity.
• Assuming Cloud Sync is a universal simplification. It is simpler in the right scenario, but it is not a drop-in replacement when Exchange hybrid or writeback-heavy designs are still required.
• Hybrid join without validating line-of-sight and SCP health. Devices then fail registration intermittently and Conditional Access becomes inconsistent.
• Ignoring operational monitoring. Entra Connect Health, sync errors, export failures, and object quarantine need named ownership.

Hybrid identity is successful when it is treated as a service with health signals and support responsibilities, not as a one-time connector installation.

What to Validate Before the First Workload Cutover

Before moving Exchange, Intune, or Conditional Access enforcement onto the platform, confirm:

• routable UPNs are in place for all in-scope users
• no critical sync errors are unresolved
• admin accounts and break-glass accounts have been tested in cloud sign-in scenarios
• hybrid join or Entra join behaviour is proven on representative devices
• service accounts and application identities have an agreed cloud-era path

If any of those remain open, the right answer is usually to pause the workload migration rather than absorb avoidable identity debt into production.

Recommended Architecture Stance for Most Organisations

For most organisations modernising Microsoft 365, the defensible target state is straightforward:

• password hash sync unless there is a specific reason to carry more authentication complexity
• Entra ID Join for new endpoints, with hybrid join treated as a transitional state
• Entra ID Connect only where Exchange hybrid or writeback requirements still justify it
• a formal plan to retire identity dependencies that only exist to preserve on-premises habit

That is not the right answer for every environment, but it is the most reliable baseline for reducing long-term operational drag.

Hybrid identity problems compound over time. The earlier you address the foundation, the less expensive every subsequent project becomes. Book a discovery call to review your current topology.

Carlos AnnesSenior Microsoft 365 / Hybrid Architect10+ years designing and securing enterprise Microsoft infrastructure.