Permission loss is the number-one complaint in SharePoint migration projects. A site lands in the destination tenant with its content intact but access in disarray: files the finance team could edit are now visible to everyone, external collaborators cannot log in, and unique permissions on three document libraries have silently reverted to inherited access. This guide covers exactly what SharePoint preserves during migration, what breaks, and how to arrive at the destination with your access model intact.
What SharePoint Online preserves during migration
Inherited permissions
When a site, library, or list uses inherited permissions (the default), those permissions derive from the parent site. After migration, if the destination site's permission structure mirrors the source, inherited items continue to work correctly. The structure is what matters, not the individual entries themselves.
SharePoint groups and role assignments
Every SharePoint site carries three default groups: Owners, Members, and Visitors. These groups hold role assignments (Full Control, Edit, Read). Within the same tenant, a site move preserves those groups and their role definitions. The users inside each group remain assigned, provided their accounts exist at the destination.
Custom permission levels
Custom permission levels (combinations of rights beyond the built-in set) are site-scoped objects. A migration tool that copies the full site structure copies those custom levels too, so any libraries or items referencing them continue to resolve correctly after the move.
What breaks during cross-tenant SharePoint migration
User identity mismatches
In a cross-tenant move, user principal names almost always differ. A user who was jane.smith@sourcecompany.com is now jane.smith@destinationcompany.com. Any permission entry referencing the source UPN becomes a broken reference at the destination. Without explicit identity mapping, those entries either fail silently or appear as "unknown user" in the permission panel.
External guest accounts
Guest users in SharePoint Online are registered in the source tenant's Entra ID. They do not transfer automatically. Each guest must be re-invited in the destination tenant, and any unique permission entries pointing to the source guest identity must be re-created after the new invitation is accepted.
Microsoft 365 Group-backed sites
Modern team sites created through Microsoft Teams or the SharePoint start page are backed by a Microsoft 365 Group in Entra ID. The Owners and Members SharePoint groups draw their membership from that M365 Group, not from standalone SharePoint accounts. Migrating only the SharePoint content leaves the M365 Group behind. The destination site needs its own M365 Group, and the Owners and Members groups must be re-linked or rebuilt at the destination.
Unique permissions at folder and item level
Libraries with many folders or items carrying individual unique permissions are the most expensive permission problem in any migration. Each unique entry must be translated independently. The more granular your permission model, the more mapping work you face before and after the move.
The safest approach is to simplify permissions before you migrate. Use the broken permission inheritance guide to reset any unique permissions that no longer serve a purpose. Fewer unique entries means less to map and less to verify at the destination.
Step-by-step permission-safe migration workflow
- Export a permission baseline. Before touching anything, run Report Master on the source site and export the full permission matrix to Excel. Record every SharePoint group, every unique permission entry, and every user assigned at the site, library, folder, and item level. This is your verification reference after the move.
- Identify and simplify unique permissions. Scan for folders and list items with unique permissions that no longer need them. Restore those to inherited. Fewer unique permission entries means less mapping work and fewer post-migration anomalies.
- Build a user mapping file. For cross-tenant moves, create a CSV mapping every source UPN to its destination UPN. Include external guests as a separate list, noting which ones need re-inviting rather than direct UPN mapping. Clone Master reads this file during migration.
- Handle Microsoft 365 Group-backed sites first. If you are migrating a Teams-connected site, create the destination M365 Group in advance and assign the right Owners and Members before starting the content transfer. This ensures SharePoint permission groups resolve correctly on arrival.
- Run the migration with Clone Master. Clone Master applies your user mapping file as it transfers the site, copying SharePoint group definitions, role assignments, and unique permission entries with identities translated to the destination.
- Re-invite external guests. After the content lands, generate a guest re-invitation list from your baseline export. Each guest needs an invitation to the destination tenant; once accepted, their access can be re-applied to the relevant libraries or sites.
- Verify against the baseline. Run Report Master on the destination site and compare the permission matrix to your source export. Look for missing assignments, unexpected inheritance breaks, and any unknown-user entries that indicate a mapping failure.
How Clone Master handles permissions
Clone Master copies SharePoint permission artefacts alongside content during migration. When it encounters a permission entry, it looks up the source identity in your mapping file, applies the translated identity at the destination with the same role assignment, and preserves the permission entry's scope (whether it applies to a list, a folder, or an individual item).
Clone Master logs any entries it cannot map - typically where the destination account does not yet exist - with the original source identity. Handle those manually after the migration completes.
For within-tenant migrations (moving a site between paths or copying a library to a different site collection), Clone Master transfers SharePoint group membership directly without a mapping file, because user identities are identical on both sides.
See the permissions preservation comparison for a side-by-side view of how ShareMaster handles this versus manual PowerShell and the built-in SharePoint migration tooling.
Frequently Asked Questions
Do SharePoint permissions carry over when you migrate a site?
Within the same tenant, SharePoint groups and their role assignments generally survive a site move. In cross-tenant migrations, user identities must be remapped because UPNs change, and external guest accounts need to be re-invited in the destination.
What is a user mapping file in SharePoint migration?
A user mapping file is a document pairing source user principal names with their destination counterparts. Migration tools read this file to translate permission entries rather than leaving them as broken references to accounts that no longer exist.
What happens to Microsoft 365 Group permissions during a SharePoint migration?
Microsoft 365 Group-backed sites tie their Owners and Members groups to an M365 Group in Entra ID. Migrating only the SharePoint content does not move the underlying M365 Group. The associated permissions must be re-established at the destination by creating or linking a matching group.
Can Clone Master copy unique permissions on individual files and folders?
Clone Master copies unique permission entries at the list, folder, and item level. Each entry is translated using the user mapping file you provide. Entries that cannot be mapped are flagged in the migration log for manual follow-up rather than silently dropped.