Picture a shared drive that has been growing for fifteen years. It has top-level folders for Operations, HSE, Field Tickets, Engineering, HR and Finance. Underneath them are hundreds of subfolders where someone once granted one crew lead access, or locked out a contractor. Now leadership wants all of it in SharePoint Online.
Copying the files is the easy part. Most projects get stuck on permissions.
Take a field supervisor with Edit access. He creates a folder for his crew leads and tries to limit who can open it, and he can’t. On the file server, whoever created a folder could control it. SharePoint has no creator-owner concept. The default Edit and Contribute permission levels don’t include the Manage Permissions right. Only Full Control and Manage Hierarchy do.
So the supervisor sends a ticket to IT. Then another. By the end of the month, IT is handling permissions for the whole company.
Why “preserve file share permissions” makes it worse
Microsoft’s Migration Manager has a setting called “Preserve file share permissions”. It rebuilds your folder-level permission mess inside SharePoint, and loses some of it along the way.
The mapping is lossy. Modify and Write become Contribute. Read, Read and execute, and List folder contents all become Read. Advanced NTFS permissions are removed.
Explicit Deny entries are not migrated at all. A folder that was only protected by a Deny can become open to the very people it was meant to exclude. If HR or payroll folders on your server rely on a Deny, find them before you move anything.
Then there are the limits. Every folder with its own permissions becomes a unique permission scope. SharePoint supports up to 50,000 per library, but Microsoft recommends staying under 5,000, and a deep file share with per-folder permissions can get close to those numbers quickly.
Once a library or folder holds more than 100,000 items, you can’t break or restore inheritance on it at all. So you have to decide library boundaries before you load the data.
Design SharePoint sites and libraries before any content moves
On our E.S. Fox migration, about 4 TB of legacy DocuShare content moved to SharePoint Online. We defined the target information architecture before any content moved: the site hierarchy, content types, taxonomy and permission model. A file share needs the same order.
- Inventory access by share, not by folder. For each top-level folder, write down who really needs to read it and who needs to change it. Flag every explicit Deny and every folder with unique permissions.
- Map each top-level folder to a site, a library, or OneDrive. If the audience is the same, use a folder or a metadata column inside the existing boundary.
- Move personal folders to OneDrive. Microsoft’s guidance is that files belonging to one person go to OneDrive, and team content goes to a shared library the team can reach by default.
- Flatten deep trees. SharePoint limits the full decoded path, including the file name, to 400 characters. Paths like
\Operations\2019\Area 3\Rig 12\Tickets\Approved\Scanned\...add up fast and are hard to search anyway, so turn the rig, area and year levels into metadata columns.
Rule of thumb: a different audience means a different site or library. The same audience never needs a new permission boundary.
What this looks like for an oilfield services company
Take a hypothetical oilfield services company. The Operations share becomes an Operations site with a Field Tickets library and a Job Files library, and rig and area become columns.
HSE becomes its own site. Incident investigations get a separate library with a smaller audience, because that’s a real difference in who can see the content.
HR and Payroll get their own sites with external sharing turned off. Microsoft recommends keeping content that must never leave the company on sites where external sharing is off, and creating separate sites for anything you share externally.
You end up with a handful of permission boundaries you can explain in a sentence each, instead of a few thousand nobody can explain.
SharePoint groups, owners and who can change access
Manage team sites through their Microsoft 365 group. Group owners become site owners and group members become site members. Members get Edit by default.
Microsoft 365 groups don’t have a read-only role. If head office needs read access to a field site, add those people to the site’s Visitors group. Existing Active Directory security groups synced to Entra ID belong there too. Microsoft advises against nesting security groups inside SharePoint groups, because it can cause performance issues.
If you use Teams, note that private and shared channels have their own SharePoint sites. Their permissions are managed in Teams and are read-only in SharePoint.
Three ways to decide who changes access
That leaves the question the supervisor was really asking. There are three common answers.
| Approach | Who can change access | What happens over time |
|---|---|---|
| IT only | IT | Tidy, but IT becomes a ticket queue for every new crew, contractor and project |
| Custom level adding Manage Permissions to Edit | Every user, on their own folders | Each change creates a new unique scope, and within a year the sprawl is back and harder to audit |
| Named business owners per site | Two or three people who know the content, with Full Control | Owners add and remove people through the group; everyone else has Edit or Read |
We recommend named business owners. On the HSE site, that’s the HSE manager and a coordinator rather than IT. It follows Microsoft’s model: the people closest to the data decide who sees it, and the number of people who can change access stays small.
Have at least two owners on every site so it still works when someone leaves or goes on rotation.
Stop permission sprawl coming back after go-live
There’s one more way inheritance breaks. When a member shares a file with someone who doesn’t already have access, SharePoint automatically breaks inheritance on that file and adds Limited Access on the folders above it. Each sharing link recreates the problem you just fixed, on a small scale.
On sites that hold sensitive content, go to Site permissions, choose “Change how members can share”, and set it to “Only site owners can share files, folders, and the site”. Members can still ask for access, and owners decide.
A common request is “Edit but no download”. SharePoint has a View Only permission level that lets people view files in the browser without downloading them, but it’s a read level, not edit. It also doesn’t stop downloads of file types the browser can’t render, such as videos and images. If you really need to prevent downloads, use a block download policy or sensitivity labels.
Migrate in waves and verify access
A few mechanics are worth getting right:
- Keep Created, Modified and author metadata. Check the user mapping so old domain accounts resolve to Entra ID users; otherwise authorship and permissions fall back to defaults or fail. Migration Manager can use Entra lookup, a custom mapping file, or both.
- Keep libraries under 300,000 files if people will sync them with OneDrive.
- Run a pilot with one department, then migrate in incremental waves, with a single cutover for users.
On TD Wealth’s SharePoint 2013 estate, more than 1 TB moved to SharePoint Online in phased waves with validation checkpoints. On E.S. Fox, every batch was reconciled against the source before sign-off, and phased cutovers kept production running. File shares need the same discipline: a wave isn’t done until someone has confirmed the right people can open the right content, and nobody else can.
Check access with SharePoint Advanced Management
The tools for checking this have improved in the last year. SharePoint Advanced Management is now available across the tenant if at least one user has a Microsoft Copilot licence. You can also get it through the SAM Plan 1 add-on or Microsoft 365 E7. A base Microsoft 365 or Office 365 licence, such as E3 or E5, is also required, and some features need the Plan 1 add-on.
It gives you what file servers never had:
- Data access governance reports that show permission state across sites and files, and every site a given user can reach.
- Site access reviews, sent to site owners rather than IT.
- A site ownership policy that enforces a minimum number of owners and notifies people when a site falls below it.
- Site attestations, where owners periodically confirm their site’s access is still correct.
Run the reports straight after each wave to confirm nothing opened up because of a lost Deny. Then schedule access reviews, so the owners you named keep their sites clean after the project team has gone.
If you’re planning a file server move and want the permission model settled before any data moves, that’s the part we do. See our SharePoint migration services.