Migrating from file shares to SharePoint and OneDrive

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 — the same impenetrable folder tree, now with sync errors and broken links. The migration tooling is the easy part; the decisions about what goes where and who owns it are the actual project.

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. Databases, application working directories, scan targets, and anything accessed by a service account do not belong in SharePoint.

Resist the urge to recreate file-share structure 1:1. The cloud rewards flatter structure — more sites and libraries, shallower folder trees. A 12-level folder hierarchy that "worked" on the G: drive produces path-length failures, unusable sync, and unfindable files in SharePoint. As a rule of thumb: if a folder tree exists mainly to encode permissions, it should become separate sites or libraries; if it exists to encode categories, consider metadata columns or at least a much flatter tree.

Migration tools

Microsoft ships two free first-party tools:

• SharePoint Migration Tool (SPMT) — a Windows tool for moving file shares and on-prem SharePoint into Microsoft 365. Good for batch jobs, handles incremental re-runs.
• Migration Manager (in the SharePoint admin center) — orchestrates migration agents across multiple servers, with a web UI, central reporting, and scan-before-migrate assessment. For multi-server file share migrations, this is the default choice today.

For larger or more complex migrations (millions of files, permissions that must be mapped precisely, legacy ECM systems), commercial tools from ShareGate, AvePoint, and Quest are well-established and pay for themselves mostly in reporting and delta-pass ergonomics. What not to use: dragging files through the browser or robocopying into a synced OneDrive folder. Both lose metadata, choke at scale, and turn the sync client into a migration engine it was never meant to be — timestamps get rewritten and every file shows the migrating admin as modifier.

A detail worth knowing: proper migration tools preserve created/modified dates and authors; they also let you run an initial bulk pass while users keep working, then a small delta pass at cutover. Design the schedule around that pattern — big pass early, freeze, delta, flip.

Pre-migration cleanup

Before migrating, do the boring work:

• Remove obsolete files. Run a last-accessed report; anything untouched in 5+ years is usually noise. Migrating less costs less, in time and in years of future storage.
• Map permissions deliberately. SharePoint doesn't replicate NTFS permissions well, and it shouldn't: decades of item-level NTFS grants are exactly the mess you're escaping. Design site membership (owners/members/visitors per site) first, and treat any share that "needs" hundreds of unique permissions as multiple sites.
• Fix names and paths. Invalid characters, leading/trailing spaces, and very long paths break on migration; the assessment scan in Migration Manager flags these up front.
• Identify owners. Each destination site needs a named human owner who signs off on structure, membership, and what got left behind. Shares with no findable owner are candidates for archive-and-wait, not migration.

During and after

Pilot with one or two well-scoped shares and a friendly department; use the pilot to validate your permission model and your comms, not just the tooling. Then, per wave:

1. Communicate the cutover date and what changes for users (new links, sync setup, where the H: drive contents went).
2. Run the bulk migration pass while the share is still live.
3. At cutover, make the old share read-only — never leave it writable "for a transition period"; dual-write is how you lose data.
4. Run the delta pass, verify counts and spot-check permissions, and point users at the new location.
5. After a defined grace period (a few weeks of read-only access for "where's my file" requests), take the share offline, keep a cold archive copy, and decommission it. Leaving the old share accessible is the surest way to ensure people keep using it.

Expect a support bump for two or three weeks per wave — sync questions, "I can't find X," and permission requests are normal and taper quickly if site owners are empowered to fix membership themselves.

The migration itself isn't the goal; the new shape of how the organisation collaborates is. Budget as much effort for information architecture and ownership as for moving bytes, and the project succeeds. Skip that, and you've just relocated the problem at considerable expense.