Moving a file server to SharePoint: what breaks, and how to plan around it

Retiring an ageing file server is one of the most worthwhile moves a small business can make, and one of the most frequently botched. The migration itself — getting bytes from a share into SharePoint — is close to a solved problem. The trouble is that a file server is not just storage. It is a set of assumptions that have accumulated for a decade, and SharePoint does not share all of them.

Here is what actually breaks, in roughly the order it surprises people.

Path length

SharePoint enforces a limit on the total length of a file's URL. Deep folder nesting plus long, descriptive filenames — the house style of every finance and projects department — exceeds it more often than you would expect, and those files simply fail to migrate.

Scan for over-length paths before you migrate, not from the error log afterwards. The fix is flattening the structure or shortening names, and both are decisions about how people work, so they need the department's agreement rather than an engineer's judgement at 11pm.

Illegal characters and reserved names

Certain characters are not permitted in SharePoint file and folder names, and some names are reserved outright. Files with a leading or trailing space, or a trailing period, cause the same problem. Every established file share contains these. They are trivial to fix once found, and invisible until you look.

Permission sprawl

This is the real work, and the reason migrations overrun.

A ten-year-old file server has permissions applied at every level: groups, individuals, inherited and broken inheritance, some of it set by someone who left in 2019 for a reason nobody remembers. SharePoint's model is different — it works best with permissions at the site or library level, and per-item permissions are possible but rapidly become unmanageable.

Copying NTFS permissions across one-for-one is the instinct, and it is a mistake. It imports the mess into a system less suited to holding it. The right move is to use the migration to redesign access: decide which departments need which sites, apply permissions at that level, and treat per-item exceptions as something requiring justification.

This takes conversations with department heads, which is why it is the long pole. Start it early.

Open files and the delta

You cannot migrate a file somebody has open, and in a live business somebody always has something open. Any real migration is therefore two passes: a bulk copy while people keep working, then a short cutover window for the delta — the files that changed since the bulk pass.

Plan the cutover for a genuine quiet period and communicate a hard deadline after which the old share is read-only. Without that, you migrate the same changing files forever.

Mapped drives and anything hard-coded

Everything that referenced S:\ now needs to reference something else. That includes the obvious — user shortcuts, desktop links — and the ones that bite later: Excel workbooks with links to other workbooks, Access databases, accounting software with a configured data path, label printers, scanners set to drop files into a folder, scheduled scripts, and the one legacy application nobody has the vendor's number for any more.

Inventory these deliberately. Ask each department what saves to the server automatically. The scanner-to-folder workflow is missed almost every single time.

Sync is not a drive mapping

OneDrive sync makes SharePoint libraries appear in File Explorer, and it is genuinely good, but it behaves differently from a mapped drive in ways users notice immediately. Files On-Demand means a file may not be stored locally until it is opened, which matters for anyone working offline or on poor connectivity. Syncing an enormous library to every laptop causes its own problems. Files are checked out and versioned rather than locked in the familiar way.

For large reference libraries people only browse occasionally, use a shortcut to the library rather than full sync. Decide this per library rather than letting each user sync whatever they like.

Version history changes the culture

SharePoint keeps versions automatically, which is a substantial upgrade on a file server — but it means the twelve files called Budget_v3_FINAL_revised_JS.xlsx are now a habit rather than a necessity. Tell people. Otherwise you have paid for versioning and kept the workaround.

What a sensible plan looks like

1. Audit. Total size, file count, largest files, over-length paths, illegal names, and how much has not been touched in three years.
2. Prune. That untouched data is often 40% or more of the share. Archive it rather than migrating it. This is the cheapest speed-up available.
3. Design. Which sites, which libraries, which permission groups — agreed with department heads, not inferred from the current structure.
4. Inventory integrations. Every scanner, script, application and workbook that touches the share.
5. Pilot. One cooperative department, end to end, including their integrations. Fix what you learn.
6. Bulk migrate. Out of hours, in tranches, while the old share stays live.
7. Cutover. Short window, delta pass, old share to read-only on a communicated date.
8. Support properly for two weeks. Expect a spike in questions and staff the first week deliberately.
9. Decommission. Keep the old server readable but read-only for a defined period, then retire it.

The step people skip

Pruning. It is unglamorous, nobody wants to own the decision to delete, and it is the single change that most reduces migration time, cost, risk and ongoing licensing. Data from 2014 that nobody has opened since 2015 does not need to be in SharePoint. It needs to be in an archive, or gone.