SharePoint permissions do not travel with content. They travel with identity. Precreate every user and group on the target tenant, map them on a stable attribute, and the permissions resolve. Skip that step and the files arrive with nothing attached to them.
What happens to SharePoint permissions between tenants?
Content and SharePoint permissions move as two separate things, and only one of them is about files. The routes themselves are compared in how to migrate a SharePoint site to another tenant.
A permission entry is a pointer. It names a user or a group in Entra ID and the role that identity holds on a site, a library, a folder or one item. Copy the content to another tenant and those pointers come with it, still naming the source identities.
If the matching identity exists on the target, the pointer resolves and the person keeps working. If it does not, the pointer resolves to nothing. The file sits there with no access, and nothing in your migration report says so.
Every SharePoint permissions failure I have been called into was an identity problem wearing a content problem's clothes. The files were fine. The people were missing.
Jamie Kaler Marketing Head and Content Strategist, RecoveryTools
Why does identity mapping decide everything?
Microsoft is direct about the sequence. For cross tenant SharePoint migration it states that all users and groups identified for migration must be precreated on the target tenant, and the identity mapping file has to be uploaded to every target instance before content moves.
Map on something stable. User principal name for people, mail nickname for groups. A display name looks fine in a spreadsheet and breaks the moment somebody married, changed department or appears twice.
Four mapping mistakes cause most of the damage:
- A group that exists but is empty. It passes a spot check because the name matches. It grants nothing.
- A Microsoft 365 group that was never created. You lose more than SharePoint permissions. The team site, the shared mailbox and the Planner boards go with it.
- Duplicate identities from a second run. Permissions split across two objects and the cleanup outlives the project.
- A parent group that is missing. Inheritance has nothing to inherit from, so every site, library and folder below it loses access at once.
One licensing detail saves money here. Microsoft states that every user needs a licence on either the source or the target tenant, and the licence does not have to be applied in both places.
Target Microsoft 365 groups have their own rule. Microsoft states they must be precreated in a specific way, and that a target group for a group connected site cannot already be linked to an existing SharePoint site.
Which SharePoint permissions do not migrate?
Most articles stop at "permissions are preserved". Microsoft's own documentation is narrower than that, and the gaps are where access quietly disappears.
- Deny entries are dropped. Microsoft states plainly that special permissions, including Deny, are not saved. A person you deliberately blocked can arrive with access through a group.
- Inherited permissions are not copied. From a SharePoint source, only the unique permissions on a file migrate. Everything inherited is rebuilt by the destination instead.
- Custom permission levels do not come across. Recreate them on the target before migrating, or every assignment pointing at them lands nowhere.
- Root folder permissions can be skipped. When the destination is a document library, the source root folder permissions are not migrated.
- Sensitivity labels with user defined permissions block the move. Microsoft states sites holding them cannot be migrated with cross tenant migration at all.
There is also a translation step. On premises Read becomes Read, Write becomes Contribute and Full control stays Full control. Anything outside those three has no equivalent waiting for it. That route runs through Microsoft's own tool, whose wider boundaries sit in SharePoint Migration Tool limitations.
How many unique permission scopes can a library hold?
This number gets quoted wrong constantly, and the difference matters when you are sizing a job.
A list or library cannot hold more than 50,000 unique security scopes. That is the hard platform ceiling. Separately, Microsoft recommends staying under 5,000 unique scopes per library when you migrate, because scopes above the list view threshold add database round trips that slow the transfer down.
Scope count drives cost as well as speed. Microsoft prices a permission call at five resource units against one for a file read, which is why a permissions heavy job runs into SharePoint migration throttling sooner.
So 5,000 is advice and 50,000 is a wall. Plenty of blog posts report the advice as the wall, which makes a perfectly viable library look impossible.
Either way the fix is the same, and it happens at the source rather than inside any tool. Replace per item sharing with group membership, let inheritance do its job again, and the scope count falls on its own. Every folder shared with one person adds another scope.
Why can the preserve setting overwrite your destination?
Here is the behaviour that surprises people who did everything else right.
Turn the preserve user permissions setting on and point a migration at a library root, and Microsoft documents what follows: the role assignments in the source root folder replace the role assignments of the target library. Run it at site level and a subsite becomes unique, with its own role assignments replaced by the source.
Replace, not merge. Any SharePoint permissions somebody built on the target before your migration are gone when the job finishes.
That matters most on a phased move, where the destination has been live for weeks and an admin has already granted access to a few teams. Migrate into a subfolder rather than a library root when you need the target assignments left alone.
How do you migrate SharePoint permissions step by step?
Treat it as an identity project with a content phase bolted on. This order is what keeps access working on the Monday after cutover.
- Inventory the permission model first. Count unique scopes per library, list every custom permission level, and find the sites with broken inheritance. Numbers before plans.
- Clean up at the source. Remove departed accounts, collapse per item sharing into groups and delete obsolete groups. Migrating a mess reproduces the mess.
- Precreate users and groups on the target. Same membership, correct attributes, before any content moves.
- Recreate custom permission levels. Same names, same rights, so the assignments have somewhere to land.
- Build the mapping file on stable attributes. User principal name for people, mail nickname for groups, and re-runnable without creating duplicates.
- Pilot one site with real people. Three users, one guest and one departed account tell you more than a thousand files.
- Check effective access, not the report. Open the site as a mapped user and confirm what they can reach.
- Migrate in phases, then audit. Re-count scopes at the destination and compare against the source inventory.
Map your identities before you move a single file
Discovery and read only scanning run without volume limits in trial, so you can count permission scopes, custom levels and unmapped accounts across the estate before spending anything.
No credit card, no sign-up. Runs on Windows 11, 10 and Windows Server.
Our RecoveryTools SharePoint Migrator carries permission levels, SharePoint groups and broken inheritance across through the user mapping, and the rest of the site moves in the same job. A multi workload project pulls in the Tenant to Tenant Migration Tool instead.
Does a delta pass pick up permission changes?
Not on its own, and this one catches careful teams.
Microsoft states that on a delta sync, permissions migrate only when the corresponding files are transferred. A delta pass moves what changed, and a permission change is not a file change.
Picture the gap. You run the bulk migration on Tuesday. On Thursday somebody at the source grants three people access to a contract folder, touching no file. Your delta pass on Saturday sees nothing to move, so those three SharePoint permissions never arrive.
Freeze permission edits at the source once the bulk run starts, the same way you freeze content edits. Collect any changes made during the window and apply them at the destination by hand.
What happens to external guests and sharing links?
Guests are different in kind from everyone else. A guest is an invitation your tenant issued, not a person your tenant owns, so a guest cannot simply be copied into another directory.
Sharing links are better news than most people expect. Microsoft states that when a cross tenant SharePoint site migration completes, existing shared links for the migrated files are redirected automatically.
Three things still need hands:
- Re-invite guests on the target. Then map them, so their SharePoint permissions have an identity to attach to.
- Compare external sharing policy on both tenants. A stricter destination locks out collaborators who worked fine yesterday.
- Review conditional access rules. Policies written against source objects do nothing useful on the target.
How do you verify SharePoint permissions landed?
A migration report lists what the tool did. Only effective access tells you whether people can work, so check that instead.
- Sign in as mapped users. Three ordinary staff across three sites, and confirm what all of them can open.
- Test one guest and one departed account. The guest should get in. The departed account should not.
- Open a broken inheritance folder. Unique SharePoint permissions are where the gaps hide, not on the site home page.
- Look for empty groups. A group with the right name and no members is the failure that survives every casual check.
- Count scopes at both ends. A destination library with far fewer scopes than its source lost assignments on the way.
Keep a readable copy outside both tenants while you check. Our SharePoint Backup Tool writes one to local or network storage, and the SharePoint Restore Tool puts it back. Version history has its own trap after cutover, covered in SharePoint version history migration.
Teams without spare hands for a verification pass hand it to our cloud migration service.
Frequently asked questions
Do SharePoint permissions migrate to another tenant automatically?
Only when identity is mapped first. Microsoft states that users and groups must be precreated on the target tenant and listed in the identity mapping file. Unmapped accounts leave permission entries pointing at identities that do not exist, so the content arrives without access.
What is the unique permission scope limit for a SharePoint library?
50,000 unique security scopes is the hard limit per list or library. Microsoft separately recommends staying under 5,000 before a migration, because scopes above the list view threshold slow the transfer down. The 5,000 figure is guidance rather than a ceiling.
Are Deny permissions preserved during migration?
No. Microsoft states that special permissions, including Deny, are not saved. Check every Deny entry at the source before you move, because a person you blocked can arrive with access inherited through a group.
Do custom permission levels migrate?
No. Recreate them on the target tenant with the same names and the same rights before content moves, otherwise assignments that point at them have nothing to resolve to.
Will a delta pass carry permission changes made after the bulk run?
No. Permissions migrate only when the corresponding file transfers, so a permission edited without touching the file is invisible to a delta pass. Freeze permission changes at the source during the migration window and apply any that slipped through by hand.
What happens to external guest access after migration?
Guests have to be re-invited on the target tenant, then mapped, because a guest is an invitation a tenant issued rather than an account it owns. Shared links for migrated files are redirected automatically, but the guest still needs an identity on the target for those links to open.
Where to start this week
Count two things and your plan writes itself. Unique permission scopes per library, and accounts with no match on the target. Both feed the timeline maths in how long does a SharePoint migration take.
The second number is the one that decides your timeline, because provisioning identities is work that cannot be rushed and cannot be done after the content moves. Everything else about SharePoint permissions follows from getting that list right. Fold it into the wider Microsoft 365 migration planning checklist rather than treating it as a separate exercise.
Then ask the question that settles the rest. Who is missing on the far side, and who is creating them?
Jamie blends strategic marketing insight with technical writing, turning migration and recovery topics into guidance that works for technical and general readers alike.
Published 7 October 2026. Permission behavior quoted above comes from file and folder permissions when migrating, permission settings in Migration Manager, cross tenant SharePoint site migration and migration permission guidance.