Migrating from file shares to SharePoint and OneDrive
A practical playbook for moving from Windows file shares to SharePoint and OneDrive — tools, structure, and pitfalls.
Moving years of files from Windows file shares to SharePoint and OneDrive is a project, not a copy-and-paste. Done well, it's a chance to clean house and reset structure. Done badly, you ship all the mess into the cloud and add new problems on top.
What goes where
The standard mapping:
- Personal folders (H: drives, "My Documents") → OneDrive for each user.
- Department shares → a SharePoint team site per department, often associated to a hub.
- Project shares → either a Teams team (with channels per workstream) or a SharePoint project site.
- Reference / read-only material → a communication site with libraries, often paired with retention.
- Application data shares → re-evaluate; many should stay on a file server or move to Azure Files.
Resist the urge to recreate file-share structure 1:1. The cloud rewards flatter structure with metadata, not deep folders.
Migration tools
Microsoft ships two free first-party tools:
- SharePoint Migration Tool (SPMT) — Windows tool for moving file shares and on-prem SharePoint into Microsoft 365. Good for batch jobs.
- Migration Manager (in the SharePoint admin center) — orchestrates SPMT agents across multiple servers, with a web UI.
For larger or more complex migrations (millions of files, hybrid environments, legacy ECMs), tools from Quest, AvePoint, ShareGate, and Movere are well-established.
Pre-migration cleanup
Before migrating, do the boring work:
- Remove obsolete files. Anything not accessed in 5+ years is usually noise.
- Map permissions. SharePoint doesn't replicate NTFS permissions perfectly; design the SharePoint permissions before migrating, not after.
- Fix file names. Some characters and very long paths break on migration.
- Identify owners. Each destination site needs a real owner who'll take responsibility.
During and after
Pilot with one or two well-scoped shares. Communicate cutover dates. Make the old file share read-only at cutover so people can't keep saving to it. Plan a discovery phase after migration where users can find missing files.
Within a few weeks of cutover, decommission the old share — leaving it accessible is the surest way to ensure users keep using it.
The migration itself isn't the goal; the new shape of how the organisation collaborates is.