How to migrate a file server to SharePoint and keep permissions
Updated October 2026 · 8 min read
Why permissions break during migration
- NTFS ≠ SharePoint. NTFS has granular rights and inheritance; SharePoint has permission levels (Read, Edit, Full Control) applied to groups. A migration must translate between the two — a straight copy can't.
- Broken inheritance. Years of "just give them access" exceptions leave folders with explicit ACLs that don't match their parents.
- Orphaned SIDs. Deleted users and groups leave security identifiers that can't be mapped to anyone.
- Deny rules & advanced ACLs. Many tools silently drop explicit Deny and advanced entries — quietly widening access.
What “keeping permissions” really means
There are two honest goals, and it's worth deciding which you want before you start:
- Faithful replication — reproduce exactly who had access to what. Best when access is already well‑governed.
- Clean‑slate model — use the migration to tidy a decade of sprawl into a sensible structure. Often the better long‑term choice.
The wrong approach is an accidental third option: a tool that flattens everything to a few broad roles and drops what it can't translate, so you neither replicated nor cleaned up — you just lost fidelity.
The right order
- 1. Survey — read every ACL; flag broken inheritance, orphaned SIDs and Deny rules, and report the permission complexity.
- 2. Remediate — take ownership, repair inheritance, remap or safely drop orphaned SIDs (with an audit trail), and resolve conflicting entries.
- 3. Map — translate the cleaned NTFS groups to SharePoint permission levels, or apply your chosen clean‑slate model.
- 4. Migrate & verify — apply the mapped permissions on upload, then verify that effective access matches what you intended.
How Approdo preserves permissions
Approdo's agent does steps 1–2 on your server automatically: it audits the ACLs, takes ownership where needed, repairs inheritance, and handles orphaned SIDs — detecting them, remapping where it can, and safely dropping the rest with a logged record. Then, during migration, it maps the cleaned groups to SharePoint permission levels and verifies the result. You see the plan and the diff before anything is applied, and it's reversible.
NTFS → SharePoint mapping, briefly
In practice: NTFS Full Control → SharePoint Full Control; Modify/Write → Edit/Contribute; Read & Execute → Read. Group‑based access maps cleanly; per‑user ACLs and Deny rules need decisions — which Approdo surfaces rather than silently dropping.
Replicate or start clean?
Approdo can do either: reproduce exactly what you had, or propose a recommended clean‑slate model — with the difference shown so you choose deliberately. For many firms, migration is the best moment they'll ever get to fix permissions, not just carry the mess across.
Approdo is coming soon
Approdo's assessment maps your NTFS permissions and flags every orphaned SID and broken inheritance before you migrate.
Register your interest →FAQ
How do I keep permissions when migrating to SharePoint?
Remediate the NTFS ACLs first (ownership, inheritance, orphaned SIDs), then map the cleaned groups to SharePoint permission levels. Approdo automates this so access is preserved, not flattened.
Do SharePoint permissions work like NTFS?
No — SharePoint uses permission levels on groups, not granular NTFS rights, so a mapping is always required.
What happens to deleted users / orphaned SIDs?
They can't be mapped to anyone, so most tools drop them. Approdo detects, remaps where possible, and safely drops the rest with an audit trail.