SharePoint vs File Server: What Actually Belongs Where

“Can we just get rid of the file server and put everything in SharePoint?” If you work in IT, someone has asked you that, probably more than once. It’s a fair question. SharePoint is already paid for in most Microsoft 365 plans, it works from anywhere, and nobody enjoys patching file servers.

Most articles on this topic answer it in one of two ways. Microsoft partners tend to say yes, SharePoint replaces the file server. File server vendors tend to say no, SharePoint isn’t a file system. Both are selling something.

I’ve worked through this in a real environment, with office staff who live in Word and Excel, drafting teams with large CAD files, legacy macro-enabled spreadsheets, and years of archive data nobody wants to delete. My honest answer is that SharePoint should be the default home for most documents, but not all of them, and the exceptions are predictable. This article explains where SharePoint genuinely wins, where it struggles, what still belongs on a file share, and how to decide.

Where SharePoint genuinely wins

For everyday office documents, SharePoint isn’t just an alternative to a file server. It’s better, and it isn’t especially close.

The biggest difference users notice is co-authoring. Several people can work in the same Word document, workbook or slide deck at once, instead of the second person getting a “locked for editing” message and a read-only copy. Version history comes a close second. Every save creates a version that users can restore themselves, where a file server usually means a helpdesk ticket and a restore from backup or shadow copies.

It also suits the way people work now. Files are available in a browser, on a phone or in Teams without a VPN, which matters a lot for staff who spend their days on site or on the road. Sharing with a client or contractor can be done securely, with an expiry date and the ability to revoke it later, rather than through email attachments or a file-transfer service IT has never heard of.

For IT, the quiet win is compliance. Retention policies, sensitivity labels, eDiscovery and audit logging are all built in, and because every Team has a SharePoint site behind it, files shared in a channel are governed the same way as everything else. Achieving the same on a file server takes extra products and a lot more effort.

If most of what your users store is Office documents that more than one person works on, SharePoint should be their home.

Where SharePoint struggles

This is the part the sales pitch leaves out. None of these are reasons to avoid SharePoint, but each one is a reason to think before moving a particular kind of data.

Large files that change often

The OneDrive sync client can do differential sync, uploading only the changed parts of a file, but Microsoft lists it as working for modern Office formats such as .docx, .xlsx and .pptx (Microsoft Support: Restrictions and limitations in OneDrive and SharePoint). For other file types, a change generally means uploading the whole file again. A 50 MB drawing saved twenty times a day is a lot of upload traffic, and it’s slow for the person waiting for the sync to finish.

CAD is the classic example. AutoCAD’s save process renames and deletes backup files on every save, and the sync client sees each of those as a change to upload. Combine that with a retention policy and you can end up with hundreds of gigabytes of retained copies. I’ve written separately about a site whose Preservation Hold Library grew to 665 GB for exactly this reason.

Sync limits

Microsoft recommends syncing no more than 300,000 files across all the libraries one user syncs, and performance degrades beyond that. Support for up to a million items per device is in public preview on Windows, but it doesn’t yet cover virtual desktops. A file server migrated wholesale into one huge library, and synced by everyone, runs straight into this.

Path length

The entire decoded path, including the file name, can’t exceed 400 characters. File servers with deep folder structures and long, descriptive folder names often have thousands of files that break that limit. They need fixing before migration, not after.

Applications that expect a drive letter

Some software simply assumes a mapped drive or UNC path. Older line-of-business applications, CAD reference files and linked spreadsheets often store absolute paths. Macro-enabled files are another trap: making macros run from SharePoint in a locked-down environment is far more awkward than from a file share, as I found while working through Essential Eight macro controls.

Permissions sprawl

SharePoint makes sharing easy, which is mostly good. But broken inheritance and ad-hoc sharing links multiply quickly, and Microsoft supports up to 50,000 unique permissions in a single list or library. Without some governance, it’s easy to end up with a site nobody can confidently say who has access to.

Storage isn’t unlimited

SharePoint storage is pooled across the tenant, and for most business plans it’s 1 TB plus 10 GB for each licensed user. That’s generous for documents, but a few terabytes of CAD drawings, photos and archive data can use it up surprisingly quickly, and extra storage is charged per gigabyte each month. Retention adds to it as well, because retained copies count against the same pool. Check where you’d land before moving a large file server, not after the quota warnings start.

Where a file share still wins

A traditional SMB file share is still the better tool for a few kinds of data:

• Large binary files that are saved frequently, such as CAD drawings, models, video and some engineering formats, where whole-file uploads and sync conflicts cause real pain.
• Data used by applications rather than people, such as software that writes to a fixed path or expects a mapped drive.
• Files with absolute references between them, such as drawings with external references or spreadsheets linked to other spreadsheets.
• Archives, where the data rarely changes, nobody co-authors it, and the main requirement is cheap, searchable, reliable storage.

The good news is that “file share” doesn’t have to mean “server in a comms room” any more.

Azure Files is the middle ground

Azure Files gives you an SMB file share as a cloud service. Users see a normal mapped drive and applications see a normal UNC path, but there’s no server to patch. With Microsoft Entra Kerberos, users can authenticate to it with their normal identity, without line of sight to a domain controller and without storage account keys on devices (Microsoft Learn: Enable Microsoft Entra Kerberos authentication on Azure Files).

That makes it a good home for exactly the content SharePoint handles badly. We use it for archive data, mapped as a drive letter through an Intune-deployed script. It took a few attempts to make the mapping reliable, which I’ve covered in a separate article, but once it worked, it behaved like any other network drive.

Azure Files isn’t free, and it doesn’t give you co-authoring or the compliance features built into SharePoint. But for data that needs to behave like a file system, it’s usually a better fit than forcing it into a document library.

A practical decision guide

The question isn’t really “SharePoint or file server?” It’s “what kind of data is this, and how is it used?” This is the rough guide I use:

A few questions settle most of the borderline cases:

1. Do several people edit it at the same time? If yes, lean towards SharePoint.
2. Is it larger than a few tens of megabytes and saved many times a day? If yes, lean towards a file share.
3. Does an application, rather than a person, open it by path? If yes, it needs a file share.
4. Does it need to be shared outside the organisation? If yes, SharePoint makes that far safer.
5. Will anyone sync it? If yes, check it against the sync and path limits before you move it.

Most organisations end up with a hybrid: SharePoint and Teams for the bulk of everyday documents, and a much smaller, better-organised file share for the exceptions. That’s not a failure of the migration. It’s the right design.

If you’re migrating: what I’d do differently

Moving a file server into SharePoint goes wrong in predictable ways. Most of the problems are avoidable if you look before you lift.

Don’t copy the folder structure as it is. File server structures usually grew over years, with deep nesting and folders named after people who left long ago. Copying them into SharePoint keeps every problem and adds path-length failures. Use the migration as a chance to reorganise by team or project, with separate libraries rather than one giant one.

Scan before you move. The 400-character limit applies to the decoded path from the site onwards, such as sites/Projects/Shared Documents/..., not to the path on your file server. So the useful number is what each file’s path will be after migration. This PowerShell works it out for a file share and lists anything that would land close to the limit:

$source = '\\fileserver\Projects'
$target = 'sites/Projects/Shared Documents'

Get-ChildItem -Path $source -Recurse -File -ErrorAction SilentlyContinue |
    ForEach-Object {
        $relative  = $_.FullName.Substring($source.Length).TrimStart('\') -replace '\\', '/'
        $projected = "$target/$relative"
        if ($projected.Length -gt 350) {
            [pscustomobject]@{ Length = $projected.Length; Path = $_.FullName }
        }
    } |
    Sort-Object Length -Descending |
    Export-Csv .\long-paths.csv -NoTypeInformation

I use 350 rather than 400 to leave headroom for folders being renamed or nested later. Count files per planned library at the same time, with the 300,000 sync guidance in mind. Microsoft’s SharePoint Migration Tool will flag many of these issues too, but it’s far better to find them in a spreadsheet you can work through than in a failed migration job.

Find the exceptions first. Search for CAD files, macro-enabled files, databases and anything an application depends on, and decide where each will live before anything moves. These are the files that cause the angry phone calls after cutover.

Clean up permissions rather than copying them. File server permissions are often a tangle of individual users and nested groups. Migrating them as-is carries the tangle into SharePoint, where it’s harder to see. Map each new library to a small number of groups instead.

Discourage syncing everything. Users often sync whole libraries out of habit. Encourage them to open libraries they only dip into through Teams or the browser, and to sync only what they genuinely work on offline. Keep Files On-Demand enabled so synced content isn’t all downloaded to every device. Remember that shortcuts added with Add shortcut to My files also appear in the sync client, so they count towards the same limits.

Think about retention before you migrate, not after. If a retention policy will cover the new sites, decide what it should cover. Every file you migrate, and every file users later delete, can count towards storage through the Preservation Hold Library.

Checklist: deciding between SharePoint and a file share

• Make SharePoint and Teams the default for Office documents that people collaborate on.
• Keep large, frequently saved binary files such as CAD on a file share or Azure Files.
• Keep application data that depends on fixed paths on a file share.
• Decide separately where macro-enabled files will live, if you’re restricting macros.
• Consider Azure Files for archives and for anything that needs to behave like a drive letter without a server.
• Scan for long paths and large file counts before migrating, and reorganise rather than copying the structure.
• Rebuild permissions around a small number of groups.
• Encourage selective syncing, and keep Files On-Demand on.
• Design retention before migrating, so the Preservation Hold Library doesn’t surprise you.

SharePoint can replace most of a file server for most organisations. It just can’t replace all of it, and pretending otherwise is where migrations go wrong. Put collaborative documents where collaboration is easy, put file-system data somewhere that behaves like a file system, and be deliberate about the line between the two.

Sources

• Microsoft Support: Restrictions and limitations in OneDrive and SharePoint
• Microsoft Learn: Enable Microsoft Entra Kerberos authentication on Azure Files
• Microsoft Learn: Learn about retention for SharePoint and OneDrive

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.