From file servers to SharePoint Online and Teams

Picture the classic file server as a filing cabinet in the basement. At some point almost everyone got a key. Barely anyone remembers what’s in half the folders. And the only way to tell who last touched a file is a filename ending in “_final_v3_actually_final.”

That’s roughly what most file servers we migrate actually look like.

Nobody built it that way on purpose. A folder for one project, an exception for an external partner, a subfolder nobody ever cleaned up because the original owner left the company years ago. After ten years, the folder structure is a history of the organisation, not a picture of how it actually works today. That’s also the real reason a migration to SharePoint Online and Teams is rarely a pure technology project. It forces decisions that got postponed for years.

The challenges worth knowing before you start

• Permissions don’t transfer one to one. NTFS permissions are folder-based and inherited. SharePoint thinks in sites, libraries and shares, and a deeply nested folder structure with a hundred individual permission exceptions can be technically migrated, but it makes exactly as little sense afterward as it did before, just in a new system.
• The sync client has limits. Long paths, special characters in filenames and very large libraries regularly cause sync errors nobody sees coming before migration, because the file server never had these constraints.
• Teams gets messy faster than a file server ever did. Without a naming convention and an owner per team, you end up with dozens of teams with overlapping purpose within a few months, and every team automatically brings its own SharePoint site with it.
• Old habits run deep. A mapped drive letter is ten years of muscle memory for a lot of users. That doesn’t change because the technology moved, it changes through training and through a system that’s genuinely simpler once someone actually understands it.

That’s also where a lot of these projects stall: the files get migrated, but the decisions about who needs what and why don’t. You end up with the same filing cabinet, just behind a more modern door.

Why the move is worth it anyway

Real-time co-authoring, actual version history instead of version numbers baked into filenames, and search that genuinely finds what you’re looking for are the part users notice first. The part that matters more long-term is governance: retention policies, sharing controls for external partners, and the ability to control access granularly without creating a new folder with its own ACL for every exception. And operationally, a piece of infrastructure disappears that needs patching, backing up and eventually replacing, without anyone in the business being particularly fond of it.

What this needs in terms of licensing

SharePoint Online and Teams are included from Microsoft 365 Business Basic or E1 upward, no separate licence required. Storage is pooled, one terabyte per tenant plus ten gigabytes per licensed user, which covers most mid-sized environments before additional storage even becomes a conversation. Microsoft’s own migration tool is free, covers standard cases well and hits its limits with complex permission structures or very large data volumes, which is where tools like ShareGate or AvePoint earn their price, mostly through the cleanup time they save. Retention policies and data loss prevention at scale usually belong to E5 or a Purview add-on, and I’d only buy that once the SharePoint foundation is actually in place, not before.

What I’d actually recommend

Don’t copy the entire folder structure into Teams one to one. Migrate one department’s file share as a pilot, work through the permission logic properly there, and only then move the rest. That costs more time upfront than a big-bang weekend migration, but it’s exactly that time that stops the new filing cabinet from being just as disorganised as the old one two years from now.