How to fix identity issues after a tenant-to-tenant mailbox migration

TL;DR: When identity migration goes wrong, access failures show up silently across SharePoint, Teams, and mailboxes. This guide walks you through triaging what's broken, fixing it in the right order (users first, then groups, then permissions), and validating that it's actually clean before you call it done.

‍

Identity problems after a tenant-to-tenant migration don't announce themselves. They surface as access errors, empty inboxes, and confused users submitting tickets about files they've opened a hundred times before. By the time the pattern is obvious, you're already in damage control.

This guide is the damage control. Triage what's broken, fix it in the right order, validate that it's actually clean. (And if you want to avoid this next time, start with identity.)

‍

Triage first: SharePoint or mailbox?

Identity failures after a mailbox migration split into two categories, which need different fixes.

SharePoint and Teams access failures show up as users locked out of sites, "Unknown user" entries in permissions panels, group memberships that exist in name but grant nothing, and inherited permissions that collapsed when a parent group didn't make it across.

Mailbox access failures show up differently. Shared mailboxes nobody can open. Full Access delegates who lost access. Send on Behalf permissions that didn't follow the mailbox. These fail silently; the mailbox migrated, the delegate account may exist, but either the delegate's identity wasn't mapped correctly in the destination, or a permission that doesn't migrate automatically (Send on Behalf) was never restamped.

Know which you're dealing with before you start fixing.

‍

Decide before you start: Re-migrate or remediate?

Before you spend hours fixing objects manually, make the call on whether remediation is actually worth it.

Re-migrate if broken permissions are widespread across the majority of users, duplicates exist across multiple migration waves, or inheritance chains are broken at root site collection level and cascade across hundreds of sites. At that scale, manual remediation outlasts a clean restart with identity-first sequencing.

Remediate in place if broken permissions are isolated to specific users or groups, duplicates are limited and identifiable, and inheritance breakage is contained to a small number of sites.

‍

What won't fix itself

You'll notice that a few things stay broken no matter how cleanly you fix identity objects.

Sharing links reference identifiers scoped to the source tenant. There's no automated fix. Audit them and plan for resharing.

External sharing policy mismatches are silent. If the destination is more restrictive than the source, external collaborators lost access without any notification. Compare sharing settings in both tenant admin centers and align them deliberately.

Conditional Access policies are tenant-specific and don't carry over. Rebuild any policy that referenced source tenant groups using destination objects. Until you do, you have security gaps you can't see.

‍

Fixing SharePoint and Teams access failures

Permissions in SharePoint reference identity objects—users, security groups, M365 groups—that need to exist in the destination tenant. When they don't, or exist but aren't mapped correctly, permission assignments break silently.

Work through fixes in this order: users first, then groups, then inherited permissions. Users must exist before groups can have correct memberships. Groups need to exist before inherited permissions can resolve.

Correct unmapped users

For every orphaned permission entry in your permissions panel (entries showing no recognized user) find the source account and either create a matching object in the destination or link them to an existing one. (Tools like ShareGate's Entra ID migration handle this mapping before content moves, so orphaned entries don't happen in the first place.) Use UPN as the anchor. Display names aren't reliable when two people share a name, and a user with the wrong UPN won't resolve permissions regardless of whether an object with the right name exists.

Recreate groups with populated memberships

Create any missing security groups and M365 groups in the destination, then populate memberships before anything else. An empty group passes a spot check: it exists, the name matches, but grants nothing to anyone.

M365 groups are the container for a Teams team, a SharePoint team site, a shared Exchange mailbox, and Planner. A missing M365 group doesn't just break a permission assignment. It also makes an entire collaboration workspace disappear.

Private and shared Teams channels need separate attention

Standard Teams channels share a SharePoint site with the parent team. Fix the M365 group and they're covered.

Private and shared channels are different. Each one has its own separate SharePoint site, and access is controlled through Teams membership, not through the parent team's M365 group. If a user was a member of a private channel in the source but their channel membership wasn't carried across, they'll have access to the parent team but not to the private channel or its files.

For private and shared channel sites, permissions are managed directly in Teams, not through SharePoint (they're read-only there).

Rebuild broken inheritance chains

SharePoint permissions pass from parent to child throughout the site hierarchy. Start at hub sites and root site collections, restoring the correct group assignments at the parent level restores permissions for everything that inherits from it. Work down to subsites, libraries, and folders only after the parent is clean.

‍

Fixing mailbox access failures

This is where the most common misunderstanding lives, so it's worth being precise about what actually happens.

Full Access and Send As permissions stored in the mailbox migrate automatically when both the mailbox owner and the delegate are moved to the target system.

These permissions usually break when the delegate's identity hasn't been migrated yet, or when the delegate's UPN wasn't mapped correctly in the destination. Fix the delegate's identity first. Once the delegate exists correctly in the destination, Full Access and Send As should resolve without manual re-stamping.

Send on Behalf permissions are different. Send on Behalf (the publicDelegates AD attribute) stores the DN of the delegate and currently doesn't move as part of the mailbox transition, regardless of whether both users are migrated. Always restamp it manually on the target mailbox once the MEU-to-mailbox conversion completes:

Set-Mailbox <mailbox> -GrantSendOnBehalfTo <delegate

If Full Access or Send As are broken after both users have been migrated, the most likely cause is that the delegate's identity wasn't correctly provisioned in the destination. Verify the delegate exists in the destination with the correct attributes before troubleshooting the permission itself. If identity is correct and permissions are still broken, you can re-add them explicitly:

• Full Access: Add-MailboxPermission -Identity <mailbox> -User <delegate> -AccessRights FullAccess -InheritanceType All
• Send As: Add-RecipientPermission -Identity <mailbox> -Trustee <delegate> -AccessRights SendAs

Shared mailboxes. If nobody can open a shared mailbox, the most common cause is that the Full Access delegates haven't been migrated or weren't correctly mapped in the destination—not that the permission mechanism failed. Confirm each delegate exists with the correct UPN in the destination before troubleshooting the permission itself.

‍

Validate before you call it clean

Pick a sample of real users across different departments and permission levels, not just admins who have access to everything. For each one, confirm:

• They can log in with their destination account
• Mail is present and send/receive works
• Full Access to shared mailboxes they had before
• Send As and Send on Behalf work where they should
• SharePoint sites load and files open
• Teams channels are accessible
• No orphaned permission entries in permissions panels
• Nobody submits an access request for something they had before

If everything passes, you're done. If anything fails, the triage section above tells you which failure type to go back to.

If this cleanup took longer than the migration itself, that's the signal. ShareGate's Entra ID migration gets identity right before anything moves: deterministic matching, pre-migration validation, and safe re-runs so mismatches surface during planning, not after cutover. See it in action with a personalized demo.