Microsoft Entra ID user accounts and groups tenant-to-tenant migration

Microsoft Entra ID user and group objects cannot simply be “moved” from one Microsoft 365 tenant to another. In a 2026 tenant-to-tenant migration, identities are recreated, synchronized, invited, or provisioned in the destination tenant, and every dependent workload must be mapped carefully to avoid broken access, licensing issues, and security gaps.

What changed since Azure AD became Microsoft Entra ID

Azure Active Directory is now Microsoft Entra ID. The core tenant-to-tenant migration concept is unchanged: user accounts, groups, roles, application assignments, and object IDs are tenant-specific. When an organization merges, divests, consolidates tenants, or separates a business unit, the destination tenant receives new Entra ID objects with new object IDs. That has downstream impact on Exchange Online, SharePoint Online, OneDrive, Teams, Viva Engage, Intune, enterprise applications, Conditional Access, group-based licensing, and line-of-business systems.

For search clarity, many people still say “Azure AD migration” or “AAD tenant migration,” but current planning, tooling, and administration should use Microsoft Entra ID, the Microsoft Entra admin center, Microsoft Graph PowerShell, Microsoft Graph API, and supported provisioning or migration tools. Legacy AzureAD and MSOnline PowerShell modules should not be the foundation for new migration automation.

What can and cannot be migrated

A tenant-to-tenant identity migration is mostly a mapping and reprovisioning exercise. You can usually recreate or synchronize many user attributes, group memberships, aliases, licensing assignments, and selected configuration objects, but not everything transfers directly.

Important items to plan include:

• User identities: display name, user principal name (UPN), mail attribute, proxyAddresses, employee attributes, manager, department, usage location, and custom attributes.
• Identity matching: source objectId, destination objectId, immutableId/sourceAnchor for hybrid identities, UPN, mail, proxyAddresses, and workload-specific identity references.
• Groups: security groups, Microsoft 365 groups, mail-enabled security groups, distribution groups, dynamic groups, nested memberships, group owners, and group-based licensing.
• Roles and administrative scope: Microsoft Entra roles, administrative units, privileged role eligibility, and delegated administration.
• Security state: authentication methods, MFA registration, passwordless methods, passkeys, Conditional Access assignments and exclusions, Identity Protection risk policies, access reviews, and break-glass account strategy.
• Application access: enterprise application assignments, app roles, SSO configuration, app registrations, service principals, API permissions, secrets/certificates, and claims mapping.
• Audit and history: audit logs, historical object IDs, and some workload-level history do not become native history of the new object in the target tenant.

Because destination object IDs are new, permissions and assignments that reference the old object must be remapped. This is one of the most common causes of post-migration access issues.

Common migration patterns in 2026

The right approach depends on tenant size, coexistence requirements, hybrid identity, security posture, and how many Microsoft 365 workloads are moving.

1. Manual recreation: Suitable only for very small environments or isolated test tenants. Administrators create users and groups in the target tenant and manually assign licenses, memberships, and access. It is simple but difficult to control at scale.

2. Scripted provisioning with Microsoft Graph: User, group, license, and membership data can be exported and recreated using Microsoft Graph PowerShell or Microsoft Graph API. This is more repeatable than manual work, but scripts must be tested carefully and must account for attributes, errors, throttling, security, and rollback.

3. Third-party tenant-to-tenant migration tools: Mature migration platforms can help with identity mapping, workload migrations, permissions, coexistence, and reporting. Tool selection should include security review, supported workloads, auditability, throttling behavior, and how the tool handles identity remapping.

4. Cross-tenant synchronization and B2B collaboration: Microsoft Entra cross-tenant access settings, B2B collaboration, and cross-tenant synchronization can support coexistence, collaboration, and staged transitions. These features are not a full replacement for every migration scenario, but they are useful for merger, acquisition, and phased coexistence models.

5. Hybrid identity migration: Organizations using Active Directory Domain Services, Microsoft Entra Connect Sync, or Microsoft Entra Cloud Sync need a separate identity-source plan. SourceAnchor/immutableId values, AD forest consolidation, domain cutover, password hash sync, pass-through authentication, federation, and device dependencies must be validated before cutover.

Discovery and dependency checklist

Before provisioning identities in the destination tenant, collect a complete inventory. Identity migration touches more than sign-in.

Discovery should include:

• All users, shared accounts, service accounts, guest users, privileged accounts, and break-glass accounts.
• All group types, group owners, nested groups, dynamic group rules, and group-based licensing.
• Microsoft 365 license assignments, including New Commerce Experience (NCE) subscription terms, seat counts, add-ons, and timing for license availability in the destination tenant.
• Exchange Online mailboxes, aliases, accepted domains, distribution lists, mail-enabled security groups, and mail routing.
• SharePoint Online, OneDrive, and Teams permissions that depend on users and groups.
• Teams teams, channels, private/shared channel membership, and Microsoft 365 group ownership.
• Viva Engage communities and identity dependencies.
• Intune users, device compliance policies, app protection policies, Autopilot, and Microsoft Entra joined or hybrid joined devices.
• Enterprise applications, SSO, app registrations, service principals, API permissions, certificates, secrets, and conditional access dependencies.
• Conditional Access policies, authentication strengths, MFA requirements, named locations, exclusions, and emergency access controls.
• Administrative roles, PIM assignments, access packages, entitlement management, and access reviews.
• Line-of-business applications that store source tenant object IDs or UPNs.

Domain, UPN, and identity matching planning

Domain planning is often the critical path. A verified custom domain can be attached to only one Microsoft 365 tenant at a time, so production domain cutover must be sequenced with mail routing, UPN changes, Teams/SharePoint dependencies, and user communications.

A practical plan should define:

• Temporary source and target domains used before the final cutover.
• Final UPN format and whether it will match the primary SMTP address.
• How proxyAddresses and aliases will be preserved or staged.
• How source and destination identities will be matched for each workload.
• Whether immutableId/sourceAnchor values must be preserved, changed, or recalculated in a hybrid identity scenario.
• What users will experience at first sign-in after cutover, including passwords, MFA registration, passwordless methods, and device prompts.

Do not rely on email address alone as the identity key. UPN, mail, proxyAddresses, objectId, immutableId/sourceAnchor, and workload-specific identifiers may all matter.

Security and governance preparation

A tenant migration is an opportunity to improve identity security rather than simply copy old settings.

Recommended security planning includes:

• Create and test break-glass accounts in the destination tenant before cutover.
• Use least privilege and Microsoft Entra Privileged Identity Management for administrative roles.
• Review Conditional Access baselines, authentication strengths, device compliance requirements, session controls, and exclusions.
• Plan MFA and authentication method registration, including passwordless options and passkeys where appropriate.
• Review cross-tenant access settings, inbound/outbound B2B collaboration, and external user lifecycle controls.
• Use access reviews and entitlement management for groups, guests, and privileged access.
• Validate Identity Protection, risk-based policies, and sign-in monitoring.
• Remove obsolete permissions, stale groups, abandoned app registrations, and unused service principals during cleanup.

Avoid copying legacy exceptions into the new tenant without review. Old exclusions and unused privileged accounts are frequent sources of security risk.

Practical phased migration plan

A controlled Microsoft Entra ID tenant-to-tenant migration typically follows these phases:

1. Discovery: Inventory users, groups, domains, licenses, applications, devices, security policies, and workload dependencies.

2. Design: Choose the identity model, target UPNs, domain cutover sequence, group strategy, license model, coexistence approach, and rollback options.

3. Mapping: Create source-to-target mapping for users, groups, mailboxes, Teams, SharePoint/OneDrive permissions, applications, and administrative roles.

4. Provisioning: Create or synchronize destination users and groups using supported tools, Microsoft Graph automation, cross-tenant synchronization, or hybrid sync design.

5. Coexistence: Configure collaboration, mail flow, access controls, and user communications for any period where both tenants are active.

6. Pilot: Migrate a controlled user group and validate sign-in, MFA, licensing, mail, Teams, OneDrive, SharePoint, apps, and device access.

7. Cutover: Move domains, update UPNs and aliases, assign licenses, complete workload migrations, and switch user access to the target tenant.

8. Validation: Confirm group memberships, permissions, Conditional Access behavior, app access, mail routing, Teams access, OneDrive/SharePoint access, and service desk readiness.

9. Remediation and decommissioning: Fix orphaned permissions, remove obsolete accounts, retire old app secrets, update documentation, and decommission source tenant components only after business validation.

Common issues to avoid

The most common problems are predictable and can be reduced with planning and testing:

• Broken permissions because destination object IDs differ from source object IDs.
• Users unable to sign in because UPN, domain, password, MFA, or Conditional Access planning was incomplete.
• Missed group memberships, especially nested groups, dynamic groups, mail-enabled groups, and Microsoft 365 group owners.
• Enterprise applications failing because SSO settings, app roles, claims, certificates, secrets, or API permissions were not recreated.
• Licensing gaps caused by unplanned group-based licensing changes or NCE subscription timing.
• Hybrid identity conflicts caused by incorrect sourceAnchor/immutableId handling or AD synchronization scope changes.
• Device access issues involving Microsoft Entra joined devices, hybrid joined devices, Intune enrollment, compliance policies, or Autopilot profiles.
• Incomplete user communication about new sign-in URLs, MFA registration, password reset, mobile apps, and support contacts.

When to use expert help

Identity migration is the control plane for the rest of a Microsoft 365 tenant-to-tenant migration. If user and group mapping is wrong, Exchange Online, SharePoint Online, OneDrive, Teams, Intune, and application migrations become harder to validate.

Expert assistance is especially useful for mergers and acquisitions, divestitures, regulated environments, hybrid identity, large group structures, complex Conditional Access, many enterprise applications, or migrations that require coexistence between tenants.

Key takeaways

• Microsoft Entra ID users and groups are not directly moved between tenants; they are recreated, synchronized, invited, or provisioned in the destination tenant.
• Destination objects receive new object IDs, so permissions, application assignments, licensing, Conditional Access, and workload access must be remapped.
• Use current tooling such as Microsoft Graph PowerShell, Microsoft Graph API, Microsoft Entra admin center, cross-tenant access settings, and supported provisioning or migration tools.
• Plan beyond identities: include Exchange Online, SharePoint Online, OneDrive, Teams, Viva Engage, Intune, enterprise applications, app registrations, security policies, and NCE licensing.
• Hybrid environments require special attention to Microsoft Entra Connect Sync, Cloud Sync, sourceAnchor/immutableId, AD consolidation, and device management dependencies.

Planning a Microsoft 365 tenant-to-tenant migration? IT Partner can help assess your Microsoft Entra ID, licensing, security, applications, and workload dependencies, then build a practical migration plan for users, groups, and Microsoft 365 services.