Entra ID Migration Strategy: Merging Identities Without Disrupting Users
How to merge Entra ID tenants without disrupting users — cross-tenant sync, conditional access, MFA, and timeline planning.
Identity is the control plane of every modern enterprise. When two organisations merge, the identity layer is the first dependency and the last thing you want to get wrong. A botched Entra ID migration locks people out of their tools, breaks application integrations, and erodes trust in the entire transformation programme.
This guide covers the strategy, sequencing, and technical detail required to merge Entra ID tenants smoothly. It is drawn from CC Conceptualise's experience consolidating identity environments for enterprises across Europe.
Why Identity Migration Is the Critical Path
Every workload migration depends on identity: mailbox moves need target UPNs, SharePoint permissions need target groups, SaaS apps need target SAML assertions. If identity is not resolved first, everything downstream stalls.
At the same time, identity migration is the most user-visible change. When an employee's login changes, their muscle memory breaks. Password prompts appear unexpectedly. MFA challenges fire on trusted devices. The goal is to make this transition as invisible as possible.
Guiding principle: Users should wake up on migration day, sign in the way they always have, and find that everything works. Anything less is a planning failure.
Step 1: Map the Identity Landscape
Before choosing a migration approach, build a complete picture of both environments.
What to Inventory
- User objects: Count, UPN format, custom attributes, extension attributes used by downstream applications
- Groups: Security groups, Microsoft 365 groups, distribution lists, dynamic groups. Note nesting depth
- Service principals and app registrations: These are often the most overlooked and most fragile objects. Document each app's permissions, redirect URIs, and certificate/secret expiry dates
- Conditional access policies: Export as JSON from both tenants. Compare side by side — policy names rarely match, but the logic often overlaps
- Authentication methods: Which MFA methods are registered per user? Authenticator app, FIDO2 keys, phone numbers, software OATH tokens
- Privileged roles: PIM assignments, standing admin accounts, break-glass accounts
- Hybrid identity components: Azure AD Connect or Cloud Sync configuration, sync rules, filtering, password hash sync vs. pass-through authentication vs. federation
Identify Conflicts
The most common conflicts:
- UPN collisions: Two users with the same UPN suffix but different identities (e.g., both organisations have a
jsmith@company.com) - ProxyAddress conflicts: Overlapping SMTP addresses block mailbox migration
- Group name collisions: Two groups named "IT-All" with different memberships
- Duplicate guest accounts: Users who were already B2B guests in the other tenant before the merger
Document every conflict. Resolving them post-migration is ten times harder than resolving them beforehand.
Step 2: Choose the Migration Pattern
Option A: Cross-Tenant Synchronisation + B2B Collaboration
Use when: You need an extended coexistence period (3–12 months), both tenants must remain operational, or the target tenant is not yet ready for full migration.
How it works:
- Entra ID cross-tenant sync projects users from the source tenant into the target tenant as B2B member accounts
- Users retain their source credentials but can access target-tenant resources
- Gradually migrate workloads (mail, SharePoint, Teams) and then cut over identity last
Advantages: Low disruption, reversible, enables phased migration. Disadvantages: Two tenants to manage, B2B accounts have some feature limitations (e.g., certain Teams calling features, some Power Platform capabilities).
Option B: Full Tenant-to-Tenant Identity Migration
Use when: A clean cut is feasible (small user population or short coexistence window), or the source tenant will be decommissioned quickly.
How it works:
- Use a migration tool (Microsoft native, Quest, Binary Tree) to move user objects, groups, and attributes from source to target tenant
- Users are re-provisioned in the target tenant with new credentials
- Workloads are migrated simultaneously or immediately after
Advantages: Clean end state, single tenant to manage. Disadvantages: Higher disruption, requires careful credential and MFA planning, harder to roll back.
Our Recommendation
For most enterprise mergers, start with Option A (cross-tenant sync) for immediate collaboration, then execute Option B as the final step once all workloads have been migrated. This hybrid approach gives you the best balance of speed and safety.
Step 3: Harmonise Conditional Access
Two organisations will almost certainly have different conditional access policies. Before users move between tenants, you need a unified policy set — otherwise migrated users will face unexpected blocks or, worse, weaker-than-intended security.
Harmonisation Process
- Export all policies from both tenants as JSON (via Graph API or the Entra portal)
- Create a comparison matrix: Map each source policy to its target equivalent by intent (e.g., "Require MFA for all users," "Block legacy authentication," "Require compliant device for Office 365")
- Adopt the stricter policy in cases of conflict. It is easier to relax a policy after migration than to tighten one
- Test in report-only mode before enforcing. Deploy the harmonised policies in the target tenant as report-only for at least two weeks and review sign-in logs for unexpected blocks
- Address named locations and trusted IPs: Both tenants likely have different office IP ranges configured. Merge them into the target tenant's named locations before migration
Policies That Catch People Off Guard
- Device compliance requirements: If the target tenant requires Intune-enrolled devices and the source tenant does not, every source user will be blocked on Day 1 unless you pre-enrol their devices
- App protection policies: Source users' mobile apps (Outlook, Teams) may need to re-register with Intune App Protection in the target tenant
- Session controls: If the target requires sign-in frequency of 1 hour but the source used 24 hours, users will see more prompts than expected
Step 4: Plan MFA Re-Enrolment
MFA credentials are tenant-bound. When a user moves from tenant A to tenant B, their Authenticator app registrations, FIDO2 keys, and phone numbers do not follow automatically.
Options for MFA Migration
| Approach | User Experience | Effort |
|---|---|---|
| Temporary Access Pass (TAP) | User receives a one-time code to sign in and re-register MFA in the target tenant | Medium — requires coordination and support desk capacity |
| FIDO2 key re-registration | User registers their existing hardware key in the target tenant | Low per user, but must be done individually |
| Phone number pre-population | Pre-populate phone numbers in the target tenant; user completes verification on first sign-in | Low disruption, but phone-based MFA is less secure |
| Staged rollout | Migrate MFA in waves, with a support desk available during each wave | Highest success rate for large populations |
Best Practice
- Communicate early. Tell users two weeks before migration that they will need to re-register MFA. Provide step-by-step instructions with screenshots
- Use Temporary Access Passes for the initial sign-in to the target tenant. TAPs are time-limited, one-use codes that let users authenticate and register new MFA methods
- Offer walk-in support during migration waves. Some users (especially those with FIDO2 keys or hardware tokens) need hands-on help
- Monitor authentication failures in real time during migration. Set up alerts in Entra ID for failed MFA challenges from migrated users
Step 5: Build the Timeline
A realistic identity migration timeline for a mid-market organisation (500–5,000 users):
| Phase | Duration | Key Activities |
|---|---|---|
| Discovery and planning | 3–4 weeks | Inventory, conflict resolution, policy comparison |
| Cross-tenant sync deployment | 2–3 weeks | Configure sync, test B2B access, validate conditional access |
| Coexistence and workload migration | 8–16 weeks | Mail, SharePoint, Teams migration in waves |
| Identity cutover | 2–4 weeks | Migrate identities, re-enrol MFA, decommission source tenant sync |
| Hypercare | 2–4 weeks | Monitor authentication, resolve edge cases, clean up |
Total: 4–7 months for a well-planned programme. Add time for larger populations or complex hybrid environments.
Critical Path Dependencies
- Cross-tenant sync must be live before workload migration begins
- Conditional access harmonisation must be complete before identity cutover
- MFA re-enrolment must be tested with a pilot group before full rollout
- Break-glass accounts must be configured in the target tenant before any admin accounts are migrated
Common Anti-Patterns
- Migrating identity last: This creates months of B2B workarounds and confuses users. Start identity work in week one
- Ignoring service principals: A legacy LOB app with a hard-coded client ID and secret will break when its service principal moves. Test every application integration
- Skipping the pilot: Always migrate a small pilot group (20–50 users) two weeks before the main waves. The pilot surfaces edge cases that documentation misses
- Assuming Entra ID Connect "just works": If both organisations use hybrid identity, you need to carefully plan the sync cutover — two Connect instances pointing at the same tenant is a recipe for attribute conflicts
How CC Conceptualise Helps
We specialise in Entra ID migrations that users do not notice. Our consultants handle the technical execution — cross-tenant sync, conditional access harmonisation, MFA migration — while managing the communication and support logistics that determine whether users have a good experience.
Reach out to discuss your identity consolidation project.