Permissions are the most complex data type in any SharePoint migration. The table below shows what each approach can and cannot preserve; the sections below explain why.
| Permission type | Within-tenant move (native) | Cross-tenant, GUI migration tool | Cross-tenant, PowerShell / SPMT |
|---|---|---|---|
| Site-level role assignments | Fully preserved | Preserved with user-mapping file | Partial (depends on script) |
| Unique folder and item permissions | Fully preserved | Preserved (tool-dependent) | Limited; manual effort required |
| SharePoint groups (structure) | Fully preserved | Recreated in destination | Not typically preserved |
| SharePoint group membership | Fully preserved | Mapped via user-mapping file | Manual rebuild required |
| Sharing links (Anyone / Specific people) | Preserved | Not transferable (platform limit) | Not transferable |
| External guest permissions | Preserved | Requires re-invitation in destination | Manual only |
Why permission preservation is harder than it looks
When migration vendors say they preserve permissions, they are usually describing two separate things that behave very differently across migration types:
- Permission structure describes which libraries, folders, and items have unique permissions versus inherited ones. This is metadata about access control layout, and most migration tools read and recreate it accurately.
- Permission assignments describe which users and groups hold which roles on each item. In a within-tenant move, these copy verbatim because the identities already exist in the destination. In a cross-tenant migration, the identities do not exist yet, and every assignment needs a translation step.
A tool that claims permission preservation is telling you it handles both parts. The accuracy of the result depends on how completely you supply the identity mapping before migration starts.
Permission types in detail
Site-level role assignments
Every SharePoint site has three default groups: Owners, Members, and Visitors. These groups are assigned permission levels (Full Control, Edit, Read) and populated with users or Microsoft 365 groups. A within-tenant move carries all of this across automatically. A cross-tenant migration recreates the group structure in the destination tenant and then populates each group using the user-mapping file. Users not included in the mapping file are silently omitted from the destination groups, leaving those permission slots empty after migration.
Unique folder and item permissions
SharePoint allows breaking permission inheritance on any library, folder, list item, or document. These unique permission scopes are the most labour-intensive part of any migration audit. Within a tenant, a copy or move operation preserves all unique permission breaks automatically. In a cross-tenant migration, the tool must walk the entire content tree to identify every broken-inheritance node, record the permission assignments on each, and then recreate those assignments in the destination using mapped identities.
Not all tools do this equally. CLI tools and PowerShell scripts frequently stop at the library level, leaving folder and item-level unique permissions to be rebuilt manually. Purpose-built GUI migration tools tend to handle the full item tree, but confirm this capability explicitly before migration begins. ShareMaster's Clone Master is designed for this depth of permission handling in both within-tenant and cross-tenant moves.
SharePoint groups versus Microsoft 365 groups
SharePoint groups are site-scoped containers managed within SharePoint. Microsoft 365 groups are Entra ID objects used as membership containers for Teams, Planner, and other services. They behave very differently in a migration:
- SharePoint groups are recreated in the destination tenant by migration tools that support group preservation. Their membership is populated via user mapping.
- Microsoft 365 groups referenced in SharePoint permissions are Entra ID objects that must exist in the destination tenant independently. A migration tool maps references to existing destination groups; it cannot create new Entra ID groups as part of a SharePoint content migration.
If your source site uses Microsoft 365 groups heavily for permission assignments, confirm those groups exist and are populated in the destination tenant before the migration job runs.
Sharing links: the non-transferable permission type
Sharing links are tenant-specific signed tokens. A link generated in the source tenant is cryptographically bound to that tenant's infrastructure and becomes invalid the moment the underlying content no longer lives there. This is a Microsoft platform constraint that applies equally to every migration tool and every scripting approach. No tool can transfer sharing links across tenants.
The practical consequence: any "Anyone" links, "Specific people" links, or company-wide links that were distributed to partners, clients, or external stakeholders before migration will stop working immediately after the content moves. Those recipients will receive an access denied error or a page not found error when they follow their bookmarked link.
Running a full sharing link audit before migration lets you communicate proactively with affected external contacts and quantify how many new links need to be created post-migration. ShareMaster's Shared Links and Permissions tool exports all active links per site, giving you that inventory before migration day.
External guest permissions
Guest user accounts are Entra ID B2B identities in the source tenant. The destination tenant has no record of those guests unless they are separately invited. Trying to migrate permission assignments that reference unmapped guest accounts produces one of two outcomes: the tool skips those assignments silently, or it errors on those rows and requires manual resolution in the migration log.
The cleanest approach is to invite all external guests to the destination tenant before migration starts and include them in the user-mapping file along with internal users. For tenants with large guest populations, a report showing all unique guest accounts across all site permissions gives you the full invitation list. Report Master's permission matrix export covers this.
The within-tenant advantage
All of the complexity above applies specifically to cross-tenant migrations. Within a single tenant, permission preservation is straightforward: identities already exist, sharing links remain valid because the tenant is unchanged, guest accounts stay intact, and SharePoint groups carry across with full membership.
If your migration project is consolidating sites within the same Microsoft 365 tenant rather than moving content between organisations, the permission problem is largely solved by the platform. The main remaining work is verifying that inherited permissions versus unique permissions at the destination behave as intended, particularly when merging content from multiple source sites into a single destination library or site.
Pre-migration permission checklist
- Export all site permissions to a spreadsheet as a documented baseline before migration starts.
- Audit active sharing links and record every link that will need to be recreated in the destination tenant.
- Identify all external guest accounts referenced in site permissions. Confirm their destination accounts will exist before migration day.
- Build a complete user-mapping file covering every internal user, every external guest, and every Microsoft 365 group that appears in a permission assignment.
- Run a test migration on one small site and verify the permission assignments in the destination match the pre-migration export before scaling to all sites.
- After migration, send new sharing links to any external parties whose links were invalidated.
Decision matrix
| Scenario | Recommended approach | Permission risk |
|---|---|---|
| Within-tenant library move, simple permissions | Native Copy To / Move To | Low |
| Within-tenant move with many unique item permissions | GUI migration tool (Clone Master) | Low with right tool |
| Cross-tenant migration, few external guests | GUI tool with user-mapping file; invite guests to destination first | Medium |
| Cross-tenant migration, large guest population | Audit guests with Report Master, invite all to destination, then migrate with full mapping | Medium (managed) |
| High volume of active sharing links | Audit with Shared Links tool before migration; recreate all cross-tenant links post-migration | High without pre-audit |
Frequently Asked Questions
Do SharePoint permissions transfer in a cross-tenant migration?
Permission structure can be preserved, but permission assignments require a user-mapping file. Entra ID identities are tenant-specific; the migration tool uses the mapping file to translate source accounts to their destination equivalents. Users absent from the mapping file are silently dropped from permission assignments in the destination.
Do sharing links transfer in a SharePoint cross-tenant migration?
No. Sharing links are tenant-scoped tokens. They become invalid the moment content moves to a different tenant. Every sharing link distributed to external parties before migration must be recreated in the destination tenant and resent to recipients.
What is the difference between permission structure and permission assignments in SharePoint migration?
Permission structure describes which items have unique permissions versus inherited ones. Most tools preserve this automatically. Permission assignments describe which users and groups hold which roles. These require a user-mapping file for cross-tenant migrations because source identities do not exist in the destination tenant.
What happens to external guest permissions in a SharePoint migration?
Guest accounts are Entra ID B2B identities in the source tenant. The destination tenant does not have those accounts unless they are separately invited. The recommended approach is to invite external users to the destination before migration and include them in the user-mapping file so their permissions transfer correctly.