Why This Matters
One of the most understated risks in Microsoft 365 migrations is identity. Moving mailboxes or SharePoint data is visible and trackable—but identity migration failures tend to surface later, in authentication, device access, and sync conflicts.
In a recent migration scenario, the goal was to move from one cloud tenant to another while preserving identities using a swing migration with Entra Connect. The requirement was clear: maintain user continuity without relying on ImmutableID hard matching.
Pre-Migration Guardrails
- Validate UPN uniqueness across both tenants
- Confirm no duplicate proxyAddresses exist
- Ensure attribute consistency for identity anchoring
- Document all domain dependencies before removal
- Prepare rollback and recovery options for failed soft match scenarios
The Core Strategy
The design revolved around three key principles:
- Only one active directory sync server at any time
- A fully staged target sync server before cutover
- UPN soft matching as the identity anchor
The target sync server was built in staging mode, allowing full synchronization cycles without exporting changes. This creates a safe parallel environment where issues can be identified before they impact production.
The Hidden Risk: Hybrid Teardown
The most dangerous phase was not the cutover—it was the hybrid teardown.
Directory synchronization had to be disabled and allowed to fully convert users to cloud-only objects. This process is not instantaneous, and during this window:
- Password sync stops
- Object states transition unpredictably
- Support impact increases significantly
In some scenarios, objects may remain in partially synchronized states even after sync is disabled, requiring validation before proceeding with domain changes.
This is where many migrations fail—not because of tooling, but because of timing and expectations.
Domain Removal: The Real Bottleneck
Removing a production domain from a tenant sounds simple—until you try it.
Every dependency must be removed first:
- User UPNs
- Group memberships
- Mail-enabled objects
Automation tools exist, but they often introduce side effects—such as renaming identities into GUID-based formats. Recovering from that without proper mapping is difficult and time-consuming.
Cutover Execution: Controlled Chaos
- Remove the domain from the source tenant
- Add and verify it in the target tenant
- Update DNS (MX, SPF, Autodiscover)
At this point, identity continuity fully depends on correct UPN alignment.
UPN Soft Match: Precision Matters
- The UPN must match exactly
- No duplicates can exist
- Cloud objects must be prepared before sync resumes
If these conditions are not met, the result is duplicate accounts—or worse, a broken identity state requiring manual cleanup.
Reactivating Sync
Once alignment is validated, staging mode is disabled on the target server and synchronization is enabled. This is the moment of truth:
- Accounts should merge cleanly
- No new users should be created
- Authentication should remain consistent
Post-Cutover Reality
Even with a perfect migration, issues will surface:
- Outlook profiles may need to be rebuilt
- Cached credentials can cause login failures
- Office activation may break
- Devices may still reference legacy identity states
This is normal—and should be planned for, not treated as exceptions.
What I Would Do Differently
- Extend the hybrid teardown observation window
- Pre-stage end user communications for post-cutover issues
- Use scripted validation to confirm domain dependency cleanup
Lessons Learned
- Staging servers are not optional—they are your safety net
- UPN alignment should be validated multiple times
- Domain cleanup will take longer than expected
- User support volume will spike post-cutover
Final Thought
On paper, a swing migration looks straightforward. In practice, it’s a tightly orchestrated sequence where timing, identity accuracy, and preparation determine success.
The technology works—the challenge is executing it without breaking the user experience.