Scanner, planifier et migrer en toute confiance

A SharePoint permission matrix report shows the complete permission structure for a site, library, or other scope. It breaks down who has access at each level (site, library, folder, document) and shows whether permissions are inherited or unique.

The report includes SharePoint groups and their members, Active Directory/security groups, direct user permissions, and permission levels granted at each level. It also highlights where inheritance is broken and can show sharing links and guest access. ShareGate's Permissions Matrix Report scans the entire scope you select and gives you a hierarchical view of every permission assignment.

Don't run ShareGate's Permissions Matrix Report tenant-wide. It's too resource-intensive and will produce unmanageable outputs. Instead, scope your tenant into batches first.

Run a Site Collection or Site report to filter sites by size, activity, or other criteria. Then launch the Permissions Matrix Report from those filtered results, one batch at a time. Export each batch to CSV or Excel. If you need one consolidated view, combine the exports in Excel or Power BI afterward. This keeps individual reports manageable and avoids hitting export limits.

Yes. Run the Permissions Matrix Report, use "Expand all groups" (or expand specific groups you care about), then export to Excel or CSV. The export will include the individual members inside each expanded group.

To expand and include members of security groups, you need to run the report as a SharePoint admin or Global admin. Site collection admin permissions alone won't let you see inside security groups.

Run ShareGate's Permissions Matrix Report on the destination after migration to see the complete permission structure at every level. Ideally, run the same report on the source before migration so you can compare them side by side.

Check the migration report for permission-related warnings and errors, like unresolved users or groups that couldn't be mapped. These flag what didn't migrate correctly. For a detailed comparison, export both permission matrix reports to Excel and compare broken inheritance locations, permission levels, and group memberships. This confirms whether everything carried over as expected.

Don't run the Permissions Matrix Report tenant-wide or on extremely large scopes. It's resource-intensive because it traverses every level to find broken inheritance and unique permissions, which creates long runtimes and massive outputs.

Batch your reporting by scoping first. Run a Site Collection report to filter sites by size or activity, then launch the Permissions Matrix Report on smaller batches from those results. You can also use "Check permissions" as a lighter pre-scan to identify which sites have broken inheritance or unique permissions, then run the full matrix only on those sites that need deeper analysis.

Make sure destination user accounts and groups exist before you start. ShareGate doesn't create accounts for you. In your migration job, go to Mappings and then Users and groups. ShareGate tries automatic mapping, but if it can't match confidently, you'll need to manually map source users to destination accounts.

For consistency at scale, export a master mapping file (SGUM format) or build one from CSV using PowerShell, then import it for every migration operation. This ensures permissions, group memberships, and user metadata like Created By and Modified By resolve to the correct destination identities across all migrations.

Changing user mappings doesn't update permissions retroactively on content you already migrated. ShareGate applies permissions when content is copied, so if a user wasn't mapped (or didn't exist) during the original migration, those permissions won't be there.

To apply updated mappings, re-migrate the affected content. ShareGate will recreate permissions using the new mappings when it copies the items again. Even in incremental migrations, only items that are actually recopied will get updated permissions. Skipped items keep their original permissions from the first migration.

You need Site Collection Administrator on every site in scope. ShareGate uses delegated permissions, so you can't do anything in ShareGate that your account couldn't do directly in SharePoint.

For bulk operations across multiple site collections, Site Collection Administrator is required on all of them. In some cases, Global Admin is needed only to grant initial consent to ShareGate's Azure app, but the actual day-to-day permission changes still require Site Collection Administrator on the target sites.