SharePoint Migration Permissions

Direct answer: Migrating SharePoint content is only part of a successful migration — users must also hold the correct access in the target environment. Permission migration becomes complex when the source contains broken inheritance, unique permissions, nested groups, inactive users, external users, sharing links, legacy identities, tenant-to-tenant identity changes, or custom permission models. Inventory, clean up, map, migrate, then prove effective access.

Do not migrate permission complexity blindly. Every unexplained exception in the source becomes an unexplained access problem in the target — usually discovered by users, not by reports.

1. Source — users, groups, permissions, and sharing as frozen.
2. Inventory — every scope, membership, break, and share recorded.
3. Clean up — obsolete access removed with owner approval.
4. Identity mapping — every principal resolved to a target identity.
5. Target permission design — a model owners can explain.
6. Migration — moved with mappings proven in a pilot.
7. Effective access validation — personas confirm real access.

For permission fundamentals, use SharePoint Permissions Explained. For the surrounding program, use Migration Assessment & Readiness, the Migration Checklist, Migration Validation, and the migration hub.

Print Permission Checklists

SharePoint permission model

Access flows down a hierarchy — site, library or list, folder, item or document — with each level inheriting permissions from its parent unless inheritance is broken. Enough background to decide migrations, not a full tutorial:

1. Site — permission granted here.
2. Library — inherits, unless broken.
3. Folder — inherits, unless broken.
4. Document — inherits, unless broken.

Broken inheritance looks like this: a library breaks from its site and carries unique permissions downward to its folders. Each break multiplies what inventory, mapping, and validation must cover — which is why fragmented structures dominate migration effort out of proportion to their content volume.

Permission principals

Individual users, SharePoint Groups, Microsoft 365 Groups, Entra ID security groups, and guests or external users are not interchangeable concepts — they live at different layers, resolve differently, and migrate differently:

1. Microsoft Entra ID — the identity authority: users and groups.
2. Users and groups — resolved, provisioned, licensed principals.
3. Microsoft 365 and SharePoint — group-connected workloads and site collections.
4. SharePoint permissions — levels granted to principals on scopes.
5. Sites, libraries, content — where access takes effect.

Identity concepts: what Microsoft Entra ID is. Use current Microsoft Entra terminology throughout this work — legacy identity names in old documentation do not change what must be mapped.

Permission inventory

Inventory before migrating — each category earns its place because missing it causes a specific failure mode, from unmapped orphans to silently surviving guest access:

• Site permissions
• Library permissions
• List permissions
• Folder permissions
• Item-level permissions where relevant
• Permission inheritance state per scope
• Broken inheritance locations
• Unique permissions with reasons
• SharePoint Groups
• Group memberships exported
• Microsoft 365 Groups
• Entra ID security groups
• Site owners
• Members and visitors
• Direct user permissions
• Guest users
• Sharing links
• Application identities where relevant
• Inactive and orphaned identities

Inventory architecture

Work top-down so nothing hides beneath an unexamined scope:

1. SharePoint environment — tenants, site collections, connected workloads.
2. Sites — ownership and structure per site.
3. Permission scopes — every level where access can differ.
4. Users and groups — principals behind each scope.
5. Access levels — what each principal can do.
6. Exceptions — breaks, direct grants, and shares that deviate.

Then run every finding through the same pipeline: inventory, analyze, clean, map, migrate, validate. Exceptions that skip cleaning resurface as validation failures; mappings that skip validation resurface as incidents.

Permission inheritance versus unique permissions

Inherited permissions flow down untouched; unique permissions stop the flow and substitute custom access. Inherited structures migrate and validate in bulk — one mapping covers whole branches. Unique structures migrate and validate location by location, which is why deeply fragmented hierarchies increase migration and validation complexity far beyond their file counts. No exact platform limits are needed to act on this: if the break inventory is long and unexplained, the structure is simplified before migration, not during it.

Unique permissions

For every location with unique access, answer five questions: how many locations carry unique access, why inheritance was broken, whether the exception is still required, who owns the decision, and whether the target model can be simpler. Then classify:

Migration is the legitimate moment to review unnecessary exceptions — but never remove access without owner and security approval. An exception removed wrongly is a security incident wearing a cleanup disguise.

Direct user permissions

Excessive direct user assignments tangle migration, governance, and future administration: every departed employee becomes a hunting expedition across scopes. Group-based access centralizes that churn into membership changes. Direct permissions are not always wrong — specific requirements legitimately need them — so judge by maintainability: a user granted directly should be explainable in one sentence, and widespread direct grants should move into groups before migration.

1. User → direct permission — fast to grant, expensive to govern.
2. User → group → SharePoint permission — membership changes propagate cleanly.

SharePoint Groups

Review the default owners, members, and visitors associations plus any custom SharePoint Groups: existence, membership, permission levels, unused and duplicate groups, owners, and business purpose. Groups without purpose or owner are cleanup candidates, not migration cargo.

• Groups inventoried
• Membership exported
• Permission levels documented
• Group purpose confirmed
• Target mapping defined
• Membership validated after migration

Microsoft 365 Groups

Microsoft 365 Groups differ conceptually from SharePoint Groups: they span workloads, with owners, members, a connected SharePoint site, and commonly a Teams connection plus other Microsoft 365 surfaces. They cannot simply replace every SharePoint Group — the target access architecture follows the site and workload design. A group-connected team site lands differently from a standalone communication site, so map each group in the context of its workloads, not as an isolated permission entry.

Microsoft Entra ID groups

For Entra ID security groups used in SharePoint access, confirm membership, group-based access behavior, availability in the target tenant, identity mapping, and ownership. In tenant-to-tenant migration, source group identities do not automatically correspond to target tenant groups — each mapping is explicit:

1. Source tenant — Entra Group A grants SharePoint access.
2. Mapping — Group A resolved to a provisioned target group.
3. Target tenant — Entra Group B grants the equivalent access.

Identity mapping

Every source principal resolves to a target principal through verified attributes — source UPN, source email, and source object identity where relevant matched to target UPN, email, user, or group. Handle domain changes, UPN changes, tenant changes, inactive accounts, departed employees, guests, renamed groups, and merged organizations as separate cases with separate owners. Matching display names is not sufficient for reliable identity mapping: names collide, change with marriage and rebranding, and repeat across directories. Unmatched principals become orphans with a disposition, never silent drops.

1. Source identity — as inventoried, including legacy domains.
2. Mapping — verified attribute match to a provisioned target.
3. Target identity — exists, licensed, and owned.
4. Target permissions — re-applied through the target model.

Tenant-to-tenant permissions

Cross-tenant moves compound every permission problem: users, UPNs, domains, groups, guests, site owners, application identities, sharing, and the entire target permission architecture must be rebuilt against a different identity authority. Do not oversimplify this into a content copy with a mapping spreadsheet — sequence identity provisioning first, validate mappings with a pilot containing real guests and groups, and review the full lifecycle in the tenant-to-tenant guide.

1. Source tenant — users, groups, SharePoint, permissions.
2. Identity mapping — explicit, verified, exception-tracked.
3. Target tenant — users, groups, SharePoint, permissions rebuilt.

Inactive and orphaned users

Identify former employees, deleted and disabled accounts, unresolvable identities, legacy domain accounts, old guests, and unknown owners — then route each through owner judgment, never automatic deletion:

1. Identity found — in directory, or only in SharePoint records?
2. Still required? — business and security owners decide.
3. Map, replace, remove, or review — replacement owners assigned where access must survive the person.

External users

Assess guests, external sharing posture, external domains, sharing policies, guest ownership, business need, and target tenant configuration. Do not claim external users automatically retain access after migration — guest identity, invitation state, policy, and assignment all change across the move:

1. External user — as found, with owner and business reason.
2. Still required? — expired collaborations end here.
3. Target guest available? — provisioned and invitable under target governance.
4. Sharing allowed? — policy, site configuration, and domain rules permit it.
5. Reinvite, map, remove, or review — each guest dispositioned with an owner.

Sharing links

People-with-existing-access, specific-people, organization, and anonymous or anyone links where enabled each behave differently across a move. Link behavior and portability depend on source and target configuration and on the migration method — verify current behavior for your combination before promising anything. Never state universally that all sharing links migrate or that all break; inventory link types, confirm the target sharing posture first, and re-test high-value links after migration.

Permission levels

Inventory each permission level with its assigned groups and users, business purpose, and custom configuration. Custom permission levels need additional review because their exact semantics may not transfer unchanged — never assume a custom level migrates as-is. Where the target standardizes on default levels, map customs deliberately with owner sign-off rather than improvising at cutover.

Site ownership

Migration is risky when nobody owns content or access decisions — every exception, orphan, and guest then defaults to "migrate as-is." Confirm before waves start:

• Every site has a valid owner
• Business owner identified
• Technical owner identified where appropriate
• Former employees removed or replaced
• Target ownership confirmed
• Group ownership reviewed

Permission cleanup

Run cleanup as a gated workflow, not as ad-hoc edits: inventory, identify exceptions, find obsolete access, confirm the business requirement, simplify, document, approve, then migrate. Candidates include inactive users, obsolete and duplicate groups, unused permission levels, unnecessary unique permissions, stale direct assignments, old external users, and unknown owners. Never alter permissions automatically — every removal carries review and approval, because access removed wrongly is indistinguishable from a breach in its effects.

Target permission design

Do not copy source permissions exactly by default. Ask whether source access should be preserved, whether it can be simplified, whether the information architecture changed, whether new Microsoft 365 Groups appear, whether sites split or consolidate, and whether security or compliance requirements changed. Permission mapping follows the approved target architecture — design it with the information architecture blueprint, not from the source export alone:

1. Source model — as inventoried and cleaned.
2. Business requirement — who must do what, per owner.
3. Target architecture — sites, hubs, groups, and boundaries.
4. Target permission model — approved, explainable, testable.

Migration tooling and permissions

No product ranking belongs here. Against your chosen migration approach, verify user and group mapping, permission preservation behavior, unique permissions handling, external user handling, sharing behavior, identity mapping support, reporting, exceptions, and error logs — and the version-history relationship where it interacts with permissioned restores. Never claim a specific product supports a permission scenario unless current authoritative documentation confirms it; prove the claims that matter in a pilot containing real unique permissions, groups, and guests.

Pre-migration permission checklist

• Permission inventory complete
• Unique permissions identified
• Broken inheritance reviewed
• Direct user permissions reviewed
• SharePoint Groups reviewed
• Microsoft 365 Groups reviewed
• Entra groups reviewed
• Site owners confirmed
• Inactive users reviewed
• External users reviewed
• Sharing reviewed
• Custom permission levels reviewed
• Identity mapping complete
• Target permission model approved
• Validation plan defined

Pilot permission migration

Pilots must include complex permissions — inherited and unique access, groups, direct grants, external access where applicable, across different site structures. Piloting only simple content when permissions are a known risk proves nothing and approves everything.

1. Pilot migration — with production-shaped access complexity.
2. Permission comparison — configuration against the mapping.
3. Effective access test — personas confirm reality.
4. Fix mapping — correct the model, not just the instance.
5. Update migration plan — lessons gate the bulk waves.

Post-migration permission validation

Verify site, library, folder, and item-level permissions where applicable, inheritance, unique permissions, SharePoint Groups and membership, Entra and Microsoft 365 Groups, owners, members, visitors, external users, sharing configuration, custom permission levels, and the identity mapping itself. Method depth lives in SharePoint Migration Validation — this checklist confirms the permission scope is fully covered there.

• Site permissions verified
• Library permissions verified
• Folder permissions verified
• Item-level permissions verified where applicable
• Inheritance verified
• Unique permissions verified
• SharePoint Groups verified
• Group membership verified
• Entra groups verified
• Microsoft 365 Groups verified
• Owners verified
• Members verified
• Visitors verified
• External users verified
• Sharing configuration verified
• Custom permission levels verified
• Identity mapping verified

Configuration versus effective access

Permission configuration is what SharePoint says is set. Effective access is what the user can actually do — configured permission plus group membership plus inheritance plus identity resolution plus sharing. Source-to-target configuration comparison alone misses broken memberships, unresolved identities, and sharing drift, so every wave pairs configuration diffs with persona testing.

Persona-based testing

Test site owner (administer expected functionality), member (create and edit expected content), visitor (read expected content without modifying restricted content), restricted user (only intended areas), and external user (only explicitly shared content where allowed) — validating both directions: users can access what they need, and cannot access what they should not. Negative testing is where over-permissioning surfaces.

Security regression testing

Compare source access against expected target access against actual target access, and classify each difference as expected, missing access, unexpected access, or needs review. Treat unexpected access as a potentially significant security issue — calmly, through the exception process, with ownership and remediation — never as background noise. Watch specifically for access expansion, access loss, incorrect membership, inheritance changes, sharing changes, and ownership problems.

Permission reconciliation report

Track site and location, principal, principal type, source access, target access, mapping, difference, status, and owner per row. Illustrative format only — populate with project evidence, never sample customer data:

Automating permission inventory

Script the machine-checkable work: enumerating sites and SharePoint Groups, exporting membership, inspecting role assignments, finding unique permissions, reviewing users and owners, and generating permission reports. Verify current cmdlets and APIs against official documentation before running anything, use supported authentication, keep inventory scripts read-only, and never place secrets or credentials in code. For identity and group data, Microsoft Graph for beginners and what Microsoft Graph is cover the concepts.

PnP PowerShell for permissions

No command reference is printed here deliberately: PnP PowerShell syntax and authentication requirements change, and a stale snippet is worse than none. Before inspecting permissions with PnP PowerShell, confirm prerequisites (an app registration or interactive sign-in your tenant allows, plus the SharePoint access needed to read the scopes), verify current syntax against official PnP documentation, start read-only against one site, and export results as reviewable evidence. No PnP permissions guide exists on nextM365 yet — when one does, it will link from here instead of duplicating this section.

Microsoft Graph for identity and groups

Graph helps with users, group membership, and tenant identity information behind permission decisions — but it does not replace SharePoint-specific permission inspection. Use SharePoint APIs or PnP PowerShell where role assignments, inheritance state, and unique permissions are the questions; use Graph where identity resolution and group truth are the questions.

Permission migration problems

Not every row is a migration-tool failure — mapping gaps, redesign decisions, and source inconsistency cause most entries. Diagnose the layer before blaming the engine.

Broken inheritance troubleshooting

When target permissions differ from source, check whether inheritance was intentionally changed, whether the target was redesigned, whether unique access was in scope, whether the migration method preserves the required configuration, whether identity mapping succeeded, and whether the source itself was inconsistent. Expected redesign is accepted with owner sign-off; anything else is investigated as a defect.

External access troubleshooting

When an external user cannot reach migrated content, work outward from identity: target guest identity, invitation state where relevant, sharing policy, site sharing configuration, permission assignment, group membership, domain restrictions, target tenant governance, and link type. Do not assume the problem lives solely in the SharePoint site — invitation and policy layers fail just as often.

Tenant-to-tenant troubleshooting

Validate identity translation separately from content migration: source user to new target UPN, source group to new target group, source guest to target guest, old domain to new domain, source owner to target owner. Each translation gets its own test — preferably sign-in or effective-access proof, not spreadsheet agreement.

Governance after migration

Lock in the gains: confirmed site ownership, scheduled access reviews, external sharing posture, least-privilege defaults, group-based access, lifecycle rules, guest review cadence, and privileged-access oversight. This section covers what migration teams verify at handover — not a general governance program.

Modernization opportunity

Legacy permission structures usually mirror legacy information architecture — deep sites with bespoke access at every level. Route both through assessment into a modern architecture with simpler permission boundaries. Simplification is not always possible: security and business requirements take priority over elegance, and some complexity is the correct answer with an owner attached.

Permissions and SPFx

SPFx solutions execute within Microsoft 365 security and authentication constraints. Where a solution touches SharePoint, Microsoft Graph, or external APIs, validate user permissions, API permissions, Entra authentication, Graph scopes, and backend authorization where applicable. Keep two concepts separate: SPFx API permissions (what the solution may call, approved by administrators) and SharePoint user permissions (what the current user may touch). A solution can hold valid API permissions and still show nothing to an unauthorized user — that is the model working, not failing. Development context: Explore SharePoint Framework (SPFx), what SPFx is.

Permission validation matrix

Migration permission checklist

Before: inventory permissions; review inheritance; review unique permissions; review groups; review direct users; review external users; confirm owners; map identities; design target access; define validation criteria.

During: monitor mapping errors; track missing identities; record permission exceptions; validate representative pilot sites.

After: compare source and target access; validate group membership; test effective access; test restricted access; test external access; resolve exceptions; obtain appropriate owner and security validation.

Working through complex migration permissions?

If you are dealing with identity mapping, unique permissions, external users, tenant-to-tenant access, or post-migration permission issues, share the environment and challenge with nextM365: Discuss Your Migration.

Continue with the migration hub, assessment guide, the migration checklist, migration validation, the classic to modern guide, the Script Editor to SPFx guide, and general permissions guide.