Validate Permissions After Migration: Practical Checklist for SharePoint Owners

After migrating content to a new SharePoint site, permission errors are the most common problem site owners face. Users may see Access Denied messages, broken sharing links, or missing edit buttons. These issues happen because permissions are not always copied exactly during migration — especially when moving between site types or tenants. This article provides a practical checklist to validate permissions after any SharePoint migration. You will learn exactly which settings to check and how to fix common permission gaps.

Why Permissions Break During Migration

Permissions do not always survive a migration intact. The root cause depends on the migration method used.

When you use the out-of-box SharePoint migration tool, the tool copies permissions from the source to the destination. However, it does not always map users correctly if the destination is in a different tenant. Users from the old tenant may appear as unknown or failed entries. If you use a third-party tool, the mapping of Active Directory groups and Microsoft 365 groups may be incomplete. The tool may also skip inherited permissions that were broken at the folder or item level.

Another common cause is the difference between site-level and library-level permissions. After migration, some libraries may inherit permissions from the new site instead of retaining their original unique permissions. This can expose content to the wrong audience or lock out users who previously had access.

Permission Inheritance After Migration

SharePoint uses permission inheritance by default. A library inherits permissions from the site, and each folder inherits from the library. During migration, this inheritance chain may be reset. If the source site had unique permissions at the library level, the destination site might revert to inherited permissions. You must check each level manually.

Checklist: Validate Permissions After Migration

Use this checklist in order. Each step covers a specific permission layer. Do not skip steps even if the site appears to work at first glance.

1. Confirm Site-Level Permission Groups
   Go to the SharePoint site. Select Settings (gear icon) > Site Permissions. Review the list of groups and users. Make sure the default groups — Owners, Members, Visitors — contain the correct people. If you see any entries labeled as unknown or with a broken user icon, those users failed to migrate. Add them manually or update their accounts.
2. Check Permission Inheritance for Every Library
   Open each document library. Select Settings (gear icon) > Library Settings. In the Permissions and Management section, select Permissions for This Document Library. If the button says Stop Inheriting Permissions, the library currently inherits from the site. If you need unique permissions, select Stop Inheriting Permissions and then add the specific groups or users.
3. Verify Unique Permissions on Folders and Items
   Navigate to any folder or item that had unique permissions in the source site. Select the ellipsis (three dots) next to the item and choose Manage Access. The panel shows who has direct access and who has inherited access. If the unique permissions are missing, select Advanced Settings > Stop Inheriting Permissions and reapply the correct access.
4. Test a User’s Effective Access
   From the site, select Settings > Site Permissions > Advanced Permission Settings. On the ribbon, select Check Permissions. Enter the user’s email or name. The tool shows exactly what permissions that user has on the site. Repeat this for a few test users — one from Owners, one from Members, and one from Visitors. If the result says Access Denied, the user is missing from a group or the group does not have the correct permission level.
5. Review External Sharing Settings
   If your migration included external users, check that sharing is enabled. Go to the SharePoint admin center > Policies > Sharing. Confirm that the sharing level for the site allows external guests if needed. On the site itself, select Settings > Site Permissions > Access Requests Settings. Ensure that access requests are sent to the correct email address.
6. Validate Permission Levels
   Each group must have the correct permission level — Full Control for Owners, Edit for Members, Read for Visitors. Go to Site Permissions > Advanced Permission Settings. Select Permission Levels from the ribbon. Verify that the default permission levels are present and that no custom levels were lost during migration. If a custom level is missing, recreate it and assign it to the appropriate group.
7. Scan Broken Permissions with PowerShell
   For large sites with many unique permissions, use PowerShell to detect broken inheritance. Run Get-PnPListItem -List "Documents" | Where-Object {$_.HasUniqueRoleAssignments -eq $true}. This lists every item with unique permissions. Compare the output to your source inventory. Any item missing from the list lost its unique permissions during migration and needs to be fixed.

Common Permission Problems After Migration

Users Appear as Unknown or Failed in Permission List

This happens when the migration tool copies a user identifier from the old tenant that does not exist in the new tenant. The user entry shows a generic icon and no name. To fix this, remove the broken entry and add the user again using their new email address. If you have many such entries, use the SharePoint admin center to run a user sync or contact Microsoft support to remap the user identities.

Library Shows Inherited Permissions but Should Be Unique

The migration tool may reset inheritance on libraries. If a library should have unique permissions, select Stop Inheriting Permissions and then add the correct groups. Be careful — after you stop inheritance, any changes to site-level permissions no longer affect that library. Reapply the exact same permission entries from the source to maintain consistency.

External Users Cannot Access the Site

External sharing may be turned off at the tenant level or the site level after migration. Go to the SharePoint admin center > Active sites > select the migrated site > Policies. Under External Sharing, choose the appropriate level — New and existing guests or Anyone. Save the change. Then resend the sharing invitation to the external user.

Team Site vs Communication Site Permission Differences

Item	Team Site	Communication Site
Default permission groups	Owners, Members, Visitors — Members have Edit by default	Owners, Members, Visitors — Members have Read by default
Microsoft 365 group connected	Yes — group membership controls site access	No — site permissions are managed independently
External sharing default	Inherited from tenant policy	Inherited from tenant policy
Unique permissions on libraries	Common for project sub-sites	Less common; usually inherited from site

After migration, a team site may lose its connection to the Microsoft 365 group. If the group is missing, site members cannot access the site even if they appear in the group. To fix this, go to the SharePoint admin center > Active sites > select the site > Membership. Under Microsoft 365 group, verify the group is linked. If not, reconnect the group or create a new one.

For communication sites, the default permission level for Members is Read. If your migrated users expected Edit access, you must change the permission level of the Members group to Edit. Go to Site Permissions > select the Members group > Edit User Permissions. Change the permission level from Read to Edit.

After completing the checklist, run a final test by logging in as a user from each group. Create a document, edit an existing file, and share a link. If all three actions succeed, your permissions are correctly validated. For ongoing monitoring, enable SharePoint audit logs and set up alerts for permission changes. This helps you catch future issues before users report them.