Moving Your File Server to SharePoint: How to Actually Do It

Every file server reaches the same afternoon. The disks are out of warranty, the backup job has been amber for months, and half the company is working from home over a VPN to reach a drive letter. Microsoft 365 is the obvious destination: the licences are already paid for, and the files may as well live where the work does.

Then someone opens SharePoint, drags the F: drive into a browser window, and goes home.

That is the version of this project that fails. Not dramatically — it usually appears to work — but by the following month people cannot find things, permissions are wrong in ways nobody can explain, and three laptops are stuck syncing forever. If you have already settled where files should live in Microsoft 365, this is the other half of the question: how you actually get twenty years of shared drive from a box in a cupboard into a place people can work.

Why the straight copy goes wrong

Paths run out of room. A file’s address in SharePoint includes the site, the library, every folder in the chain and the file name. There is a limit on the total length, and a Windows file server has spent years happily storing things like Clients \ 2019 \ Projects \ Phase 2 Final \ Approved \ Signed Copies \ Final Final v3 (approved by MD).pdf. Those files copy in and then refuse to open, sync or move. You do not find them until someone needs one.

Sync has a ceiling. The OneDrive client that puts SharePoint libraries on people’s machines is built for working sets, not archives. Microsoft publishes a supported item count across everything one person syncs, and it is far smaller than most file servers. Check the current figure in Microsoft’s own documentation rather than any article, including this one. Either way, a 900,000-item drive was never going to sync to a laptop.

Permissions do not translate. Windows folder permissions are a per-folder, per-group, inherit-and-override system that a dozen people have quietly modified over a decade. SharePoint has its own model, built around sites and libraries. Nothing carries across on its own, and the tools that promise to map it will faithfully reproduce a mess.

Some things should not go at all. Outlook PST files, Access databases and anything a line-of-business application opens over a network path do not belong in a synced library. They appear to copy, then corrupt or lock.

Most of it is dead. On a typical drive, a large share of the data has not been opened since a version of Windows that is now out of support. You are proposing to spend a project’s budget moving files nobody will ever ask for.

Decide what moves before you move anything

This is the step people skip, and it is the one that shrinks the whole project.

Run a report on the drive by last-accessed date and by folder size. You want three piles. Active is anything touched in roughly the last two years — this migrates, and this is what staff will sync. Reference is older material you are required to keep or might need: it moves too, but into its own archive site that nobody syncs and that stays read-only. Dead is departed staff’s home drives, twelve copies of the same photo shoot, installers for hardware you no longer own, and the folder called Old Server that was itself a migration in 2014.

Nobody will authorise deleting that third pile, and you do not need them to. Keep it as one archive image on cheap storage with a review date, and move on. The argument you cannot win is better avoided than fought.

Rebuild permissions, do not copy them

The temptation is to recreate the old folder tree exactly, permissions and all, so nothing changes for staff. Resist it.

Per-folder permission sprawl is the reason nobody can answer “who can see the HR folder?” on your current server. Recreating it in SharePoint makes that worse, because unique permissions on nested folders are harder to audit at a glance and they interact badly with sharing links.

The better shape is boring on purpose. Access is granted at the site level, to security groups that mean something — Finance, Sales, Senior Team — and inherited downwards. If a folder genuinely needs different access, treat that as a signal it should be its own site or library, not an exception buried six levels deep. A handful of clearly named sites beats one giant library called Company Data every time, and it keeps each library well below the sizes where views and sync start to struggle.

Expect this conversation to take longer than the copying. It forces the business to say out loud who should see payroll, old tenders and client contracts — questions that have been answered by accident until now.

What changes for staff

The drive letter goes away, and that matters to people more than it sounds.

Files On-Demand means a synced library appears in File Explorer with everything visible but only downloaded when opened. Staff see the whole library without filling a laptop — though a file can look present and still need a connection to open, which is worth saying before somebody boards a train.

Two habits need retraining. Saving into ever-deeper folders stops being necessary, because search across a library actually works. And emailing attachments gives way to sharing a link, which is where most of the value arrives: one file, one current version, and access you can withdraw later. Budget for a short session with staff. A migration people do not understand becomes a shadow folder on somebody’s desktop within a month.

The cutover

Do it in stages, not in one heroic weekend.

1. Pre-sync. Copy the bulk of the data up while the old server is still live and in use. Nobody is affected while it runs.
2. Freeze. At an agreed time, usually a Friday evening, the old shares go read-only. Announce it twice, in writing.
3. Delta. Run an incremental pass to catch everything that changed since the pre-sync. This is the short one, and it is why the freeze can be hours rather than days.
4. Switch. Point staff at the new sites, remove the mapped drives, and be available on Monday morning. Something will be missing. Something always is.
5. Keep the old server read-only for a while. A month at minimum, longer if you can. It is your safety net for the file that turns out to matter and the permission you got wrong.

Then decommission it properly, and make sure your backup and continuity plan now covers Microsoft 365 rather than a server that no longer exists.

Be honest about the cost

This is a project, not an afternoon. Discovery, structure decisions, permission design, the copy itself, a rehearsed cutover and a fortnight of support afterwards. Done properly, it is the last time you do it. Done as a drag and drop, you pay for it again in eighteen months and unpick the first attempt as well.

If you are weighing it up, our cloud migration and SharePoint setup work usually starts with a straight look at the drive and an honest answer about how much of it should actually move.