Migrating file shares to OneDrive and SharePoint

Moving Windows file shares to OneDrive and SharePoint is the single most common Microsoft 365 migration project. The mechanics are well-understood, but getting the destination architecture right takes more thought than the migration itself.

The mapping that works for most organisations:

Personal H: drives, "My Documents", user home folders → OneDrive per user.
Department-wide shares (HR, Finance, IT) → one SharePoint team site per department, with libraries for different content types. Site members are the department.
Project shares → either a Microsoft Teams team (with channels per workstream) or a SharePoint project site, depending on how the team works.
Reference / read-only shares (policies, templates) → a communication site with libraries.
Application data shares — re-evaluate; many should stay on a file server or migrate to Azure Files instead. SharePoint isn't designed for application I/O patterns.
Build shares, source control shares — definitely don't put in SharePoint.

Resist recreating file share structure 1:1. The cloud rewards flatter structure with metadata over deep nested folders.

First-party tooling

Microsoft provides two free tools:

SharePoint Migration Tool (SPMT) — Windows tool that you run on-prem to push files into SharePoint or OneDrive. Good for moderate volumes.
Migration Manager — orchestrates SPMT agents across multiple servers from a single web UI in the SharePoint admin center. Right for larger projects.

Both handle Windows file shares, on-premises SharePoint, and (via Migration Manager) Google Drive and Box. Both preserve file metadata, version history (some flavours), and permissions where possible.

Third-party tooling

For complex migrations (millions of files, mixed sources, custom mappings, hybrid environments) the established tools — ShareGate, AvePoint Fly, Quest Migration Manager, Mover (now part of Microsoft) — offer richer permissions handling, transformation, and reporting.

Pre-migration

The boring-but-essential work before you migrate anything:

Inventory and triage. How big is each share? When was it last accessed? Who owns it? A common finding: 30–50% of file shares haven't been touched in 5+ years.
Identify owners for every destination site or OneDrive. Each destination needs an accountable owner.
Map permissions to a clean target. NTFS permissions don't translate 1:1 to SharePoint; design the target permissions first.
Fix file issues. Files with illegal characters, very long paths, or $ system files need handling.
Communicate the timeline. Users need to know what's moving, when, and what changes.

During migration

A typical pattern:

Initial bulk migration to the destination (read content from source, write to OneDrive/SharePoint).
Delta migration of any newly added or modified files since the bulk run.
Source goes read-only at a defined cutover.
Final delta to catch the last changes.
Source decommissioned after a stabilisation period (typically 30 days).

For shares with active editing, this typically means an evening or weekend cutover with users out.

After migration

Onboard users — show them where their content is now, train them on co-authoring, OneDrive sync, Teams.
Roll out Known Folder Move so users' Desktop/Documents/Pictures back up to OneDrive automatically.
Decommission the old shares — leaving them online is the surest way to make sure people keep using them.
Capture lessons for the next wave.

Common pitfalls

Migrating before cleaning — you carry junk forward.
Not designing target permissions — re-shaped at the eleventh hour, badly.
Underestimating user training — the file share habit is decades old.
Trying to preserve every file ever created — old, stale content rarely earns its keep.