How should permissions be handled in a SharePoint migration?

Key facts

• Grant access to groups, not individuals, at the site or library level.
• Every broken inheritance point adds admin effort and audit risk.
• Set tenant and site sharing settings before migrating content, not after.
• Copilot and search respect permissions, so oversharing becomes visible after migration.
• Each site needs at least two named owners responsible for access reviews.

Why not just copy existing permissions

File servers and cloud drives build up access over many years. Folders get shared with individuals for a single project, groups named Everyone or Domain Users get read access, and nobody removes access when people change roles. Migration tools can copy those permissions faithfully, but faithful copying keeps every problem.

SharePoint also behaves differently. Microsoft Search and Microsoft 365 Copilot surface anything a user can technically open. Content that was obscure on a file server becomes easy to find once it is indexed in SharePoint, so oversharing turns into real exposure.

Design the target permission model

Start from the site design. Each site or Team has three standard roles: owners, members and visitors. Map those roles to groups that already reflect the business, such as department security groups synced from Active Directory or Microsoft 365 Groups behind Teams.

• If a folder needs different access from its parent, consider a separate library or site instead of breaking inheritance.
• Avoid granting access to Everyone or Everyone except external users on sites with sensitive content.
• Use security groups managed in Entra ID or synced from AD so access follows HR changes.

Map old permissions to the new model

Run a permissions report on the source before migration. For file servers, export NTFS access lists per share and folder. For Google Drive, Box or Dropbox, export sharing reports. Review them with department owners and decide which access rules to keep.

Then build a mapping table from old principals to new groups. Old local groups or individual grants become members of the right Microsoft 365 or security group. Orphaned accounts and departed users are dropped. Most tools, including SharePoint Migration Tool and Migration Manager, can use a user mapping file so permissions resolve to the right Microsoft 365 identities when you do choose to preserve them.

Set sharing controls before content lands

Decide external sharing settings at the tenant level and per site before the first migration pass. Common choices are to limit anyone links, default to specific-people links, set expiration on guest access, and allow external sharing only on sites designed for it.

Sensitivity labels from Microsoft Purview can mark sites as confidential and control sharing and guest access for the whole site. Where the organization has SharePoint Advanced Management, data access governance reports and restricted access controls help find and contain oversharing.

Review access after migration

Permissions are not finished at cutover. Schedule an owner review in the first month to remove access that was kept just in case. Repeat reviews on a regular cycle, especially for sites with guests.

Before rolling out Copilot, run a dedicated oversharing check. Look for sites shared with large groups, files shared through anyone links, and libraries with many unique permissions. Fix those first so Copilot does not surface content to people who should not see it.

How Accred Consulting approaches it

Accred Consulting reviews source permissions with department owners during discovery and designs a group-based model in the Proposal, alongside the site structure, fixed price and timeline. Delivery sets sharing controls before content moves and uses mapping files so access resolves to the right identities. In one engagement for about 240 users, about 1.8 TB was assessed and consolidated into 11 governed sites over 9 weeks. Handover gives site owners documentation and knowledge transfer on running access reviews.

Track record: 400+ client projects, 2,000+ migration workstreams and 150,000+ users migrated by a US-based team. Company facts · Case studies

Related questions