File Server to SharePoint Migration: Fix Permissions Before You Move

Moving file shares to SharePoint Online copies years of messy NTFS permissions into a platform where search and Microsoft 365 Copilot can surface anything a user is allowed to open. On a file server, an over-permissioned folder is often protected by obscurity: people do not know the path. In SharePoint, the same access becomes discoverable. Microsoft's migration tools also do not carry every permission across, and some of what they drop, such as Deny entries, was holding sensitive data back. This guide is for infrastructure, Microsoft 365 and security teams planning or running a file server to SharePoint, OneDrive or Teams migration. It covers why the move changes your exposure, how to find and clean up permissions first, how the SharePoint Migration Tool (SPMT) and Migration Manager handle permissions, labels and sharing defaults, testing and rollback, and how to decommission the old shares safely.

Key takeaways

• Clean up before you copy. Every broad group, orphaned SID and broken inheritance point you migrate becomes a SharePoint permission that search and Copilot respect. Fixing it on the file server is cheaper than fixing it after.
• Deny entries do not migrate. Microsoft documents that special permissions such as Deny are not saved. Any folder that relied on Deny to exclude a group will be more open after the move unless you redesign it.
• Design SharePoint structure, do not mirror folders. Map business areas to sites and libraries with Microsoft 365 groups or SharePoint groups, so permissions sit at site or library level rather than on thousands of folders.
• Set sharing and labelling guardrails first. External sharing level, default link type and default library sensitivity labels must be in place before content lands, because users start sharing on day one.
• Decommission deliberately. Make shares read-only, watch access logs, keep a protected backup for an agreed period, then remove shares, service accounts and stale DFS targets.

What is changing and why

A file server enforces access with NTFS ACLs on each folder and file, usually combined with share permissions. SharePoint in Microsoft 365 enforces access with site, library, folder and item role assignments, and adds sharing links that users create themselves. The change is not only technical:

• Discoverability: SharePoint search and Copilot index content across sites. Microsoft states that Copilot only surfaces organisational data to which individual users have at least view permissions, and stresses using SharePoint permission models so the right people have the right access. If permissions are too broad, Copilot will faithfully surface overshared content. See the Microsoft 365 Copilot Security Deep Dive.
• User-controlled sharing: on a file server, only administrators changed ACLs. In SharePoint, site owners and members can share files and folders with links, including to guests where the tenant allows it.
• Identity: permissions must resolve to Microsoft Entra ID users and groups. Local server accounts and unsynchronised groups have no equivalent.
• Limits: SharePoint supports up to 50,000 unique permissions per list or library, with a recommended general limit of 5,000, and a list, library or folder holding more than 100,000 items cannot have inheritance broken or restored. A share with deep per-folder ACLs can hit these limits when mirrored into one library.

The live Windows File Server and NTFS Permissions Guide and SharePoint and OneDrive Security Guide cover each platform on its own. This guide covers the move between them.

Official timeline and current status

There is no Microsoft retirement date for Windows file servers as a role, and both migration tools are current. Timing pressure usually comes from the server operating system and from Copilot rollouts. Status as checked on 8 November 2026:

Product names, licensing and limits change: confirm them on the linked Microsoft pages before you plan.

Who and what is affected

• Data owners and users: anyone with mapped drives, DFS paths or shortcuts. Paths change, and the full decoded path including file name cannot exceed 400 characters in SharePoint and OneDrive.
• Groups and identities: domain local and global groups used in ACLs, local server groups, orphaned SIDs from deleted accounts, and nested groups that are not synchronised to Entra ID.
• Service accounts and applications: scripts, scanners, line-of-business apps and backup jobs that read or write UNC paths with service account credentials. Each needs a new design, typically an Entra application with narrowly scoped Microsoft Graph permissions such as Sites.Selected, or retirement. See the Windows Services and Service Account Security Guide.
• The migration identities themselves: Migration Manager needs a Global Administrator or SharePoint administrator at the destination, and Windows credentials with read access to every share at the source. SPMT needs SharePoint admin or site admin at the destination. These are temporary, high-value credentials.
• Security tooling: file server auditing (event IDs 4663 and 5145), DLP on shares and backup coverage all have to be replaced by Microsoft 365 audit, Purview DLP and a Microsoft 365 backup plan. See the Microsoft 365 Backup guide.

Finding affected systems and identities

Build an inventory before choosing tools. The aim is to know, per share, what is there, who can reach it and who actually uses it.

1. Share inventory: list every share on every file server and DFS namespace target, with size, file count, last write time and owner. Mark shares with no writes in two or more years as archive or delete candidates rather than migration candidates.
2. Permission export: export NTFS ACLs (for example with read-only Get-Acl or icacls listings) to a report per share, down to the depth where inheritance is broken. Record share permissions too.
3. Flag risky entries: Everyone, Authenticated Users, Domain Users, local groups, orphaned SIDs, individual user ACEs, explicit Deny entries and folders where inheritance is disabled.
4. Usage evidence: where object access auditing is on, use 4663 and 5145 events to see who actually reads each share. Groups with permission and no use are removal candidates.
5. Sensitive content: run a classification scan to find personal data, credentials, financial and HR content. Shares with sensitive data get a target site with tighter permissions and a default sensitivity label. See the Data Access Governance Guide.
6. Application dependencies: search scheduled tasks, scripts, application configuration and DFS referrals for UNC paths, and list the accounts that use them.
7. Identity readiness: confirm every group and user in the cleaned ACLs exists in Entra ID. Microsoft advises synchronising Active Directory accounts to Entra ID so permissions can be kept; anything not synchronised needs a user mapping file or a redesign.

How permissions translate

Microsoft documents the file share permission mapping used by its migration tools as follows. Anything outside these three types needs a design decision.

Migration options

Choosing a target permission model

• Re-architect (recommended for most): one site per business area or team, permissions through the site's owners, members and visitors (or a Microsoft 365 group), with SPMT's "Preserve file share permissions" turned off so files inherit. Exceptions get their own library. This removes the long tail of folder ACLs.
• Preserve and tidy: keep file share permissions on, after cleanup. Suitable where regulation or contracts require exact per-folder access, but count unique permissions against the 5,000 recommended limit per library.
• Archive instead: move inactive content to a restricted archive site, or retain it offline, rather than into collaborative sites.

Tools compared

Use the date and extension filters to leave behind old content and file types you do not want in Microsoft 365, such as executables and old backups.

Guardrails to set before content lands

• External sharing: each site's sharing setting must be the same as or more restrictive than the organisation level. Set migrated sites to "Only people in your organization" or "Existing guests" unless there is a case for more. Anyone links are only available when the level is Anyone; if you allow them, require expiry and View only.
• Default link type: set it to Specific people or Only people in your organization, never Anyone with the link, for migrated sites.
• Default library sensitivity label: a site admin can set one per library. Microsoft documents that new files without a label receive it, existing files get it when edited and saved, and files at rest are not labelled. Test in your pilot whether migrated files receive the label, and plan auto-labelling or bulk labelling for the rest. See the Microsoft Purview Information Protection Guide.
• Migration identity: use a dedicated, time-bound admin account with MFA, through privileged access, and remove it at the end.
• OneDrive Known Folder Move: if home drives move to OneDrive, apply the same sharing defaults to OneDrive, which can be more restrictive than SharePoint but not more permissive.

Testing and rollback

1. Pilot one representative share with broken inheritance, a Deny entry, sensitive data and an application dependency.
2. Verify access with test accounts: a member, a non-member and a former member. Confirm the non-member cannot open or find the content through search.
3. Check labels and sharing: confirm the default label and link type, and look for the "Applied sensitivity label file" audit event.
4. Run Data access governance reports after the pilot: Site permissions across your organization, and Sites and files shared via special SharePoint groups to catch "Everyone except external users".
5. Cut over in waves: set the source share read-only (remove write ACEs) at cutover, run a final incremental pass, then redirect drives and DFS links.
6. Rollback: because the source stays intact and read-only, rollback means restoring write access on the share and redirecting users back. Decide the rollback window (for example 30 days) in advance and lock the SharePoint site with restricted access control if a permission error is found.
7. Decommission: after the window, remove shares, take a final protected backup under your retention policy, sanitise or reuse disks according to policy, remove DFS targets and disable service accounts used only for the old shares.

Detection and measurement

• Monitor: Microsoft 365 audit for sharing link creation, permission changes and guest invitations on migrated sites; continued 5145 events on read-only shares to find users and apps you missed.
• Metrics: percentage of migrated sites with no "Everyone except external users" grants; unique permissions per library; number of Anyone links on migrated content; percentage of sensitive-data files labelled; count of orphaned SIDs and user ACEs removed before migration; number of residual connections to retired shares.

Risks of doing nothing

• Copilot oversharing: a lift-and-shift migration exposes broadly permissioned salary sheets, HR folders and credentials to every user who asks Copilot the right question.
• Silent permission widening: dropped Deny entries and unmapped users falling back to the destination's default permissions widen access without any alert.
• Sharing sprawl: permissive default links turn internal content into external content.
• Unsupported servers: keeping content on Windows Server 2016 past 13 January 2027 leaves it without security updates.
• Zombie shares: leaving old shares online after migration creates a second, unmonitored copy that attackers use for collection (MITRE ATT&CK T1039 Data from Network Shared Drive), alongside the SharePoint copy (T1213.002 Sharepoint).

Common failure patterns

• Mirroring the whole folder tree with permissions preserved, then hitting unique permission limits and unmanageable access reviews.
• Relying on Deny to hide a sub-folder and discovering after migration that it is open.
• Leaving the migration admin account and Migration Manager agents in place after the project.
• Applying sensitivity labels months later, after files have been shared externally.
• Forgetting application service accounts, so scripts keep writing to the old share and data diverges.

Framework mapping

Practitioner checklist

• Inventory every share, its size, last write date, owner and dependent applications.
• Export NTFS and share permissions and flag Everyone, Domain Users, orphaned SIDs, user ACEs, Deny entries and broken inheritance.
• Remove unused groups and redesign Deny-based exclusions as separate libraries or sites.
• Confirm every remaining identity is synchronised to Entra ID or in a user mapping file.
• Choose re-architect, preserve or archive per share, and count unique permissions per target library.
• Set site sharing level, default link type and default library labels before migrating.
• Use a dedicated, time-bound migration admin and harden Migration Manager agent hosts.
• Pilot, test with member and non-member accounts, and run Data access governance reports.
• Set shares read-only at cutover, monitor residual access, then decommission with a final protected backup.
• Remove migration accounts, agents and old service accounts at project close.

Standards and references

• Microsoft Learn: File and folder permissions when migrating
• Microsoft Learn: Introducing the SharePoint Migration Tool
• Microsoft Learn: Migration Manager for file shares
• Microsoft Learn: SharePoint Migration Tool settings
• Microsoft Learn: SharePoint limits
• Microsoft Learn: Manage sharing settings for SharePoint and OneDrive
• Microsoft Learn: Default sensitivity label for a SharePoint document library
• Microsoft Learn: Data access governance reports

Related NHI Mgmt Group resources: Windows File Server and NTFS Permissions Guide · SharePoint and OneDrive Security Guide · Microsoft 365 Copilot Security Deep Dive · Data Access Governance Guide