A guest account never moves — it points at a tenant, and the tenant is changing
You can migrate mailboxes, groups, and licenses to a new tenant, but a B2B guest has nothing inside it to carry — it is a reference to an identity that lives somewhere else, and references do not travel.
New to cloud? CAMPUX is a free, build-first course. Start here →
This note is part of the Azure tenant-to-tenant migration guide, and it covers the piece that surprises people on cutover day: the external partners. Someone opens a ticket because a supplier can no longer reach the SharePoint site they used yesterday, and the answer is not a broken permission. The guest object those partners signed in through simply does not exist in the new tenant, and it was never going to.
What a B2B guest actually is
When you invite an external partner into your tenant, Microsoft Entra creates a user object in your directory to represent them. That object has userType set to Guest and a user principal name in the form john_contoso.com#EXT#@fabrikam.onmicrosoft.com. What it does not have is a password. There are no credentials stored on it, because authentication happens against the partner's own identity provider — their home tenant. The Identities property on the object records where that real identity lives: ExternalAzureAD for a partner in another Entra tenant, or a value like google.com or mail for a social or one-time-passcode sign-in. The guest object is a local stub, a pointer. The person it represents is authenticated somewhere you do not control.
There is no identity inside a guest object to migrate. The credentials, the account lifecycle, the sign-in — all of it lives in the partner's home tenant, and your object only points there.
Why it does not move
Tenant-to-tenant migration tooling works on things with substance: a mailbox with contents, a user with a synced on-premises source, a group with members. A guest has none of that on your side. So the migration skips it, and the old guest objects stay behind in the source tenant, which usually gets decommissioned. In the target tenant, each external partner has to be invited again. That produces a genuinely new object — new object ID, new UPN stamped with the target's onmicrosoft.com domain — and the partner has to redeem the invitation before it becomes active. Until redemption, the invited object sits in a Pending acceptance state with its Identities set to the host domain, exactly as it did the first time around. Nothing is copied; everything is re-provisioned.
Set the guardrails before you invite anyone
A fresh tenant starts with its own defaults, and two separate settings decide whether your re-invitations even succeed. Cross-tenant access settings govern which external Entra organizations may collaborate with you, inbound and outbound, and can scope that down to specific users, groups, and apps; they are also where you choose to trust MFA and device claims from a partner's home tenant so people are not challenged twice. External collaboration settings are a different lever — they decide who inside your tenant may send invitations at all, and which partner domains are allowed or blocked. The two are checked together, and the more restrictive one wins. If a partner's domain is blocked in external collaboration settings, it does not matter that cross-tenant access allows their organization; the invite is refused. Configure both in the target before the re-invitation campaign, not during it.
Guests are not only the partners you host — your own staff are guests in their tenants too. When your users get a new home tenant, every external guest object those partners hold still points at your old tenant, which is going dark. Their side has to re-invite your people under the new identity, or the outbound collaboration breaks with no error on your dashboard at all. Inventory both directions before cutover: who you host, and where your users are hosted. The second list is the one that generates the confusing tickets.
Keeping access alive through the switch
Because each re-invited guest is a new object, nothing that referenced the old one follows automatically. Group memberships, application assignments, and SharePoint or OneDrive permissions were all granted to the previous object ID and have to be reapplied against the new one. For a handful of partners you do this by hand; for a real estate of them you script it against the invitation API, or you stand up cross-tenant synchronization so guests are created and kept current between the two tenants during a coexistence window. Coexistence is the calmer path — you run both tenants side by side, re-provision guests and their access in the target, verify partners can sign in and reach what they need, and only then retire the source. A guest whose access you re-created and tested is a guest who does not open a ticket on the morning of the switch.
The takeaway
A B2B guest is a reference in your directory to an identity that lives in another tenant, so it is never migrated — the target tenant re-invites the partner, they redeem, and a new object is born with none of the old memberships or permissions attached. Set cross-tenant access and external collaboration settings in the new tenant first, re-provision guests and reapply their access during coexistence, and do not forget the reverse direction, where your own users are the guests. Treat the external partners as a re-provisioning project, not a copy job, and cutover day stays quiet.
Questions people also ask
Do guest accounts migrate between tenants?
No. A guest is a user object in your directory that points at an identity living in another tenant. It has no password of its own and no mailbox to move, so tenant migration tools skip it. The target tenant has to create fresh guest objects and re-invite each external identity, and their access is granted anew rather than carried over.
What happens to B2B guest users during a tenant-to-tenant migration?
The old guest objects stay behind in the source tenant, which is usually decommissioned. In the target tenant, each external partner must be invited again and redeem the invitation, producing a new object with a new UPN and object ID. Any group membership, app assignment, or SharePoint permission the old guest had must be reapplied against the new object.
Can I copy a guest user to the new tenant?
Not as a straight copy. There is nothing portable inside a guest object — the real identity is in the partner's home tenant. You re-invite the same email in the target, either one by one, in bulk through the invitation API, or continuously with cross-tenant synchronization if both organizations agree to it. Each produces a genuinely new object, not a moved one.
What about our own users who are guests in other tenants?
That is the reverse direction, and it is easy to forget. When your employees are guests in a partner's tenant, moving to a new tenant changes their home identity, so the partner's guest object still points at your old tenant. Each partner has to re-invite your people under the new tenant, or those outbound collaborations quietly break on cutover day.
Do cross-tenant access settings need to be set up in the new tenant?
Yes, before you invite anyone. The target tenant starts with its own defaults. Inbound and outbound cross-tenant access settings decide which external organizations may collaborate, external collaboration settings decide who inside can send invitations and to which domains, and the most restrictive of the two wins. Set these first or your re-invitations get blocked.