Permission loss is one of the most common complaints 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 the Security Matrix report from Report Master, selecting the source site's lists and libraries, and save the Excel workbook. It records the site's permissions, every SharePoint group, sharing links, and every unique permission entry at the list, 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. For cross-tenant moves, list every source UPN alongside its destination UPN. Include external guests as a separate list, noting which ones need re-inviting rather than direct UPN mapping. In Clone Master, enter the pairs in the User Mapping dialog on the clone screen; they are saved for that source and destination pair.
- 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. With Copy all permissions ticked in the options, Clone Master copies SharePoint groups, permission levels, role assignments, and unique permission entries as it transfers the site, 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 the Security Matrix report on the destination site and compare it to your source export. Look for missing assignments and unexpected inheritance breaks; a user entry missing at the destination usually indicates 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 User Mapping pairs, then tries the same account and the same email address at the destination, applies the matched identity with the same role assignment, and preserves the permission entry's scope (whether it applies to a list, a folder, or an individual item).
An entry whose user cannot be matched, typically because the destination account does not yet exist, is skipped rather than written as a broken reference. Find those by comparing the source and destination Security Matrix reports, and handle them 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 user mapping, 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?
Yes, when Copy all permissions is ticked. Clone Master copies unique permission entries at the list, folder, and item level, translating each user through your User Mapping pairs first, then by account and email. An entry whose user cannot be matched at the destination is skipped, so compare a Security Matrix report of both sides afterwards.