Microsoft Entra ID guest accounts tenant-to-tenant migration

Guest accounts are often the hidden complexity in a Microsoft 365 tenant-to-tenant migration. In 2026, the right approach is not to “move” Microsoft Entra ID guest objects, but to inventory, re-create or synchronize external identities, remap access, and apply modern external identity governance.

What changes when migrating guest accounts?

Microsoft Entra ID, formerly Azure Active Directory, represents external collaborators as guest or external user objects in the resource tenant. These objects allow users from another organization, personal account, or identity provider to access Teams, SharePoint, enterprise applications, Azure resources, Power Platform assets, and other workloads.

In a tenant-to-tenant migration, guest objects are usually not migrated with full fidelity. Instead, they are re-created, re-invited, synchronized, or remapped in the target tenant. Important identifiers and state do not transfer automatically, including object IDs, some app assignments, user consent records, audit history, sharing link context, and workload-specific permissions.

For mergers, acquisitions, divestitures, and tenant consolidation projects, external identity migration should be treated as a controlled access reconstruction and governance project, not just a directory export/import task.

Common scenarios

Guest identity migration is typically required when:

• A company consolidates Microsoft 365 tenants after a merger or acquisition.
• A divested business unit moves to a new tenant but must retain collaboration with the parent company.
• External partners need continued access to Teams, SharePoint, OneDrive, applications, or Azure resources after tenant restructuring.
• A tenant is being cleaned up and stale or unmanaged guest accounts must be removed.
• Collaboration policy is being modernized using Microsoft Entra External ID, cross-tenant access settings, access reviews, and entitlement management.

The migration plan should distinguish between guests that must be re-established, guests that should be replaced by internal member accounts, and guests that should be retired.

Prerequisites and planning checklist

Before re-creating or synchronizing guest identities in the target tenant, validate the following:

1. Use least-privilege administrative roles instead of defaulting to Global Administrator. Depending on the task, roles may include User Administrator, Groups Administrator, Application Administrator, Cloud Application Administrator, Conditional Access Administrator, Security Administrator, Privileged Role Administrator, SharePoint Administrator, Teams Administrator, or Exchange Administrator.
2. Review Microsoft Entra external collaboration settings, invitation restrictions, allowed and blocked domains, redemption settings, guest access permissions, and tenant restrictions.
3. Configure Microsoft Entra cross-tenant access settings for inbound and outbound B2B collaboration. Decide whether to trust MFA claims, compliant device claims, or Microsoft Entra hybrid joined device claims from the other tenant.
4. Decide whether to use cross-tenant synchronization. It can automate creation, update, and removal of B2B collaboration users between tenants, but it still requires careful scoping, attribute mapping, and access assignment planning.
5. Inventory guest users, sponsors or business owners, source identity domains, email addresses, user principal names, groups, Teams memberships, SharePoint permissions, application assignments, Azure RBAC assignments, and Power Platform access.
6. Confirm identity matching rules. Email address alone may not be enough if users have changed domains, been converted from guests to members, or have duplicate accounts.
7. Review Conditional Access policies for external users, authentication strengths, MFA requirements, terms of use, session controls, and risk-based policies.
8. Plan licensing. Basic B2B collaboration does not mean every guest needs a Microsoft 365 license, but advanced Microsoft Entra ID Governance capabilities, workload access, or converting guests to internal users may require appropriate licensing. If licenses are assigned through CSP, include current New Commerce Experience (NCE) subscription terms in the migration plan.
9. Create a rollback and communication plan for guests who must re-accept invitations or access resources through a new tenant.

Recommended 2026 migration process

A practical Microsoft Entra ID guest migration process includes these phases:

1. Discovery and inventory Export guest users, attributes, creation dates, sign-in activity, group memberships, app role assignments, owners, sponsors, and workload permissions. Use Microsoft Graph API or the Microsoft Graph PowerShell SDK rather than deprecated AzureAD or MSOnline PowerShell modules.

2. Cleanup and classification Remove stale guests, disabled accounts, expired partner access, and accounts with no valid business owner. Classify remaining users by required access: collaboration only, application access, Azure resource access, privileged access, or replacement with a member account.

3. Identity matching and mapping Map each source guest to the correct target identity. Document source object ID, target object ID, email, UPN, external user state, sponsor, groups, applications, and workloads. This mapping becomes the foundation for permission reassignment.

4. External collaboration policy design Configure Microsoft Entra External ID settings, B2B collaboration policies, cross-tenant access settings, inbound and outbound rules, MFA trust, device trust, Conditional Access, and terms of use before inviting users at scale.

5. Guest creation, invitation, or synchronization Use Microsoft Graph to create invitations, or use cross-tenant synchronization where ongoing synchronization between tenants is required. Validate that guests redeem invitations correctly and that user attributes align with naming and governance standards.

6. Access remapping Reassign access to Microsoft 365 Groups, Teams, SharePoint sites, OneDrive resources, enterprise applications, Azure subscriptions, Power Platform environments, and other systems. Do not assume permissions follow the guest automatically.

7. Validation and pilot testing Run a pilot with representative users and workloads. Test sign-in, MFA, Conditional Access behavior, Teams access, SharePoint sharing, app access, Power Platform access, and Azure RBAC if applicable.

8. Communication and cutover Notify external users and internal sponsors. Provide clear instructions for invitation redemption, tenant switching, Teams access, and support escalation.

9. Post-migration cleanup and governance Disable or remove obsolete guest accounts in the source tenant when appropriate, update access reviews, document exceptions, and monitor sign-ins and audit logs after cutover.

Workloads affected by guest access

Guest identities often touch more systems than expected. Include these workloads in the migration assessment:

• Microsoft Teams: standard team membership, private channels, shared channels, meeting access, and Teams-connected Microsoft 365 Groups.
• SharePoint Online and OneDrive: site permissions, direct permissions, sharing links, external sharing settings, sensitivity labels, and information barriers where applicable.
• Microsoft 365 Groups: group membership, owners, Teams-connected groups, Planner plans, and group-based app access.
• Exchange Online: shared mailboxes, calendars, distribution groups, mail contacts, and partner scheduling scenarios.
• Enterprise applications: app role assignments, SAML/OIDC configuration, user consent, admin consent, SCIM provisioning, and third-party SaaS integrations.
• Azure resources: Azure RBAC assignments, management groups, subscriptions, resource groups, and privileged role assignments.
• Power Platform: environment roles, Dataverse security roles, app sharing, Power Automate ownership, connectors, and data loss prevention policies.
• Viva Engage: community access and external network considerations where still in use.

Important limitations

Set expectations early. Guest account migration has important limitations:

• Source guest object IDs are not preserved in the target tenant.
• Existing access often must be reassigned or rebuilt.
• User consent, app role assignments, enterprise application state, and SCIM provisioning relationships may need reconfiguration.
• SharePoint and OneDrive sharing links may not map cleanly to new guest objects.
• Teams membership can be remapped, but user experience may change and some historical context is tied to the old identity.
• Audit history and sign-in history remain associated with the original tenant and object identifiers.
• External users may need to redeem a new invitation or access resources using a different tenant context.
• Stale or unowned guests should usually be removed rather than migrated.

Because of these limitations, the safest strategy is to build a validated identity and access mapping, test with a pilot group, and migrate in controlled waves.

Security and governance recommendations

A tenant-to-tenant migration is a good time to modernize external identity governance:

• Require business owners or sponsors for external users.
• Use access reviews for guests in groups, Teams, apps, and privileged roles.
• Use entitlement management access packages for repeatable partner onboarding and offboarding.
• Apply lifecycle workflows or automated processes to remove expired access.
• Enforce Conditional Access for external users, including MFA, authentication strength, sign-in risk, session controls, or compliant-device requirements where appropriate.
• Review inbound and outbound cross-tenant access settings regularly.
• Standardize guest naming, department, company name, sponsor, and extension attributes.
• Separate privileged external access from standard collaboration access.
• Keep emergency access accounts and administrator safeguards outside the migration blast radius.

The goal is not only to preserve collaboration, but to reduce long-term external access risk.

Tooling: use Microsoft Graph

For 2026 projects, use Microsoft Graph API and the Microsoft Graph PowerShell SDK for discovery and automation. The older AzureAD and MSOnline PowerShell modules should not be used for new migration automation.

Typical Microsoft Graph tasks include exporting guest users, reading group memberships, creating invitations, checking sign-in activity, reviewing app role assignments, identifying owners, and validating post-migration access. Workload-specific administration may also require SharePoint Online PowerShell, Teams PowerShell, Exchange Online PowerShell, Azure PowerShell, or Power Platform admin tools.

Automation should be tested in a pilot tenant or limited migration wave before bulk execution.

Key takeaways

• Microsoft Entra ID guest accounts are usually re-created, re-invited, synchronized, or remapped; they are not migrated with all identifiers and access state intact.
• Cross-tenant access settings, B2B collaboration policies, MFA trust, device trust, and Conditional Access should be designed before bulk guest onboarding.
• Permissions in Teams, SharePoint, OneDrive, Microsoft 365 Groups, enterprise applications, Azure, and Power Platform must be inventoried and reassigned carefully.
• Use Microsoft Graph API or the Microsoft Graph PowerShell SDK instead of deprecated AzureAD or MSOnline PowerShell modules.
• A guest migration is also an opportunity to remove stale external users and implement access reviews, entitlement management, and lifecycle governance.

Planning a Microsoft 365 tenant-to-tenant migration? IT Partner can help assess your Microsoft Entra ID external identities, design cross-tenant access settings, automate guest re-creation or synchronization, and remap collaboration access across Microsoft 365 workloads.