How to Migrate from a File Server to SharePoint

File server to SharePoint migration is one of the most common small business IT projects of 2026. Your company file server has served you well for 10 years — a Windows Server running the “S: drive” that everyone maps, storing department folders with 500GB of company documents. But the server is aging, the backup tape drive keeps failing, remote workers can’t easily access files without VPN, and Microsoft 365 already includes SharePoint that everyone’s paying for anyway. Time to migrate.

Done right, this migration eliminates the file server, gives every employee cloud access to files, adds versioning and co-authoring, and cuts your infrastructure costs. Done wrong, it produces broken permissions, lost files, angry users who can’t find anything, and a support ticket queue that lasts six months. This guide walks through the migration properly.

Some links in this post are affiliate links. If you purchase through our links we may earn a small commission at no extra cost to you.

For the cold-storage destination for archived file-server content (see Phase 1 cleanup), external drives like the WD My Book Duo (16 TB+) or a small NAS work well as a durable “keep for compliance / don’t need active” tier.

Why migrate from file server to SharePoint

The drivers are real:

• Hardware refresh avoidance: aging server needs replacement ($3,000-$8,000) or migration off. SharePoint eliminates the hardware line item.
• Remote access without VPN: file server requires VPN for off-site access; SharePoint is cloud-native and accessible from any browser or synced device.
• Co-authoring: multiple people editing the same Word/Excel/PowerPoint file simultaneously. Impossible on a file server (last-save-wins conflict).
• Version history: SharePoint keeps versions automatically. File server = one version, unless you have a specialized versioning solution.
• Search: SharePoint full-text search finds text inside documents; file server search is limited to filenames.
• Better permissions model: per-file / per-folder / per-user, cleaner than NTFS ACL sprawl.
• Backup handled by Microsoft: geo-redundant, no tape drives.

See our SharePoint vs OneDrive vs Google Drive guide for the broader storage architecture context.

What SharePoint is (and isn’t)

SharePoint is Microsoft’s cloud collaboration platform. Files live in SharePoint sites, which are logical containers for a team or project. Each site has:

• Document libraries (the file storage layer — replaces file-server folders)
• Lists (structured data — replaces spreadsheet-based tracking)
• Pages (news, wikis, dashboards)
• A Teams connection (if desired — a Team is a SharePoint site + Teams chat)

Rule of thumb: 1 SharePoint site per team/department. Not one giant site with 47 sub-folders. Site-per-team maps cleanly to permissions and Teams integration.

Migration prerequisites

1. Microsoft 365 subscription active with SharePoint included (all Business tiers and Enterprise tiers include it).
2. Entra ID users provisioned (see our Entra ID setup guide).
3. SharePoint admin center access.
4. Detailed inventory of file server contents (folder structure, sizes, permissions, active vs stale).
5. Test users identified for pilot testing.

Phase 1 — Discovery and cleanup (weeks 1-2)

Inventory the file server

Before migration, know what you have. Run analysis to determine:

• Total size of file share.
• File count by folder.
• Age of files (last modified date).
• File types (documents vs images vs videos vs junk).
• Current NTFS permissions per folder.

Free tools that help: TreeSize, WinDirStat, PowerShell scripts. Microsoft’s own Migration Manager (below) does this automatically.

Clean up before migrating

The cardinal rule: do not migrate junk. Every gigabyte of stale/orphan/duplicate files migrated is technical debt in your new SharePoint. Before migration:

• Archive files older than 3-5 years to cold storage (Azure Archive Storage, external drive, kept “just in case” but not migrated).
• Delete obvious junk — old backup ZIPs, test folders, .DS_Store and Thumbs.db, orphaned employee folders from people who left years ago.
• Consolidate duplicates. Many file servers have 3-5 copies of the same document scattered across folders.
• Rationalize folder structure. Deep nested folders (X:\Projects\2019\Client\A\Docs\Old\Backup\Final\v2) migrate poorly. Flatten to 3-4 levels max.

Rule of thumb: 30-50% of a typical aging file server is candidate for archive or deletion. Cleanup effort during migration = long-term storage savings + cleaner SharePoint experience.

Phase 2 — Design SharePoint site architecture (weeks 2-3)

Map departments/teams to sites

Standard structure for a 50-employee small business:

• Sales SharePoint site — Sales team files, pipeline docs, presentations.
• Marketing SharePoint site — brand assets, campaigns, content library.
• Finance SharePoint site — financial reports, budgets, vendor docs. Access restricted.
• HR SharePoint site — employee handbook, HR forms, benefits docs. Access restricted.
• Operations SharePoint site — SOPs, process docs, project files.
• Executive SharePoint site — leadership-only files.
• Company SharePoint site (intranet) — company-wide news, policies, employee directory. Everyone can view; small group can edit.

Add project-specific sites as needed (client work, initiatives). Delete when project completes.

Set permissions per site (not per folder)

Old file-server thinking: control access per folder. SharePoint thinking: control access per site. Each site has an M365 Group (Members, Owners, Guests). Manage those groups; the whole site’s permissions follow.

Only use per-folder or per-file permissions when genuinely needed (executive-only subfolder within Finance site, for example). Don’t recreate the file-server nested permission mess.

Phase 3 — Execute migration (weeks 3-6)

Microsoft Migration Manager (recommended for most)

Free tool built into SharePoint admin center. Handles:

• Source: Windows file share (SMB accessible from a workstation running the agent).
• Destination: SharePoint sites (mapping folder-to-library).
• Metadata preservation (modified dates, creator, etc.).
• Permissions mapping (best-effort — often needs post-migration cleanup).
• Incremental sync (initial migration + delta migrations for files that change after cutover).

Setup: SharePoint admin center → Migration → Migration Manager → Add agent (install on a workstation with file server access) → Configure task (source, destination, users). Run.

Third-party tools for complex migrations

ShareGate, Metalogix, Quest Migrator. Better for: complex source (Confluence, Google Drive, Dropbox), extensive permission mapping, large-scale (multi-TB) with tight cutover windows. Cost: $2,000-$10,000+ per project.

For most small business file-server-to-SharePoint migrations, Microsoft Migration Manager is sufficient and free.

Manual copy (last resort)

Small enough migration (< 100GB), single team? OneDrive Sync client can drag-and-drop copy folders into SharePoint. Loses NTFS permissions but preserves file content. Fast but manual and no automation for large migrations.

Phase 4 — Pilot with one team (weeks 4-5)

Never migrate the whole company at once. Pilot with one department (usually IT itself or a friendly team):

1. Migrate pilot team’s files to their SharePoint site.
2. Give team members SharePoint sync client (One Drive-based file sync makes SharePoint feel like a network drive).
3. Run a training session — SharePoint navigation, co-authoring, versioning, mobile access.
4. Let pilot team use SharePoint for 1-2 weeks; capture issues.
5. Fix issues, update process documentation, then proceed to broader rollout.

Phase 5 — Cutover (week 6+)

Once all teams migrated and using SharePoint:

1. Set the old file server to read-only. Users can pull remaining files if needed but can’t add new ones. Force behavior change.
2. Communicate loudly: “As of DATE, S: drive is retired. All files live in SharePoint. Here’s how to find your team’s site.”
3. Support intensively for 2-3 weeks. Help-desk tickets will spike. Prepare with FAQs, quick reference guides, and peer help champions.
4. After 30-60 days, decommission the file server. Back up its contents to cold storage (Azure Archive, external drive), then power down.

Permission mapping — the tricky part

File server NTFS permissions rarely map cleanly to SharePoint permissions. Common patterns:

• File server folder with “Marketing Team” NTFS group → SharePoint “Marketing” site with Marketing team members as Members.
• File server nested folder with special permissions → SharePoint sub-folder with explicit permissions (avoid where possible; instead move to its own site with proper access).
• Files inherited from parent group → keep the inheritance in SharePoint (default behavior).

Migration Manager attempts to preserve permissions but often results in errors or broken inheritance. Plan for 20-40 hours of post-migration permission cleanup for a typical small business migration.

Sync client — how users actually access files

Deploy OneDrive Sync client (built into Windows 11) configured to sync each SharePoint site the user needs:

1. User signs into OneDrive with their M365 credentials.
2. OneDrive syncs their personal OneDrive files.
3. User navigates to a SharePoint library in browser, clicks “Sync” button.
4. Library appears in Windows File Explorer under “[Company Name]” section — feels like a mapped drive.
5. Files sync locally; changes sync back to cloud.

This is what makes SharePoint feel like a file server to end users — files show up in Explorer, drag-and-drop works, no browser required. Configure this deployment via Intune or Group Policy for automation across the fleet.

Common mistakes

• Migrating without cleanup. 30-50% of file server contents don’t belong in SharePoint. Archive or delete first.
• One giant SharePoint site with 47 folders. Site-per-team is the model. Don’t rebuild the file server structure in one site.
• Preserving NTFS permission mess. Use migration as an opportunity to redesign permissions cleanly.
• No pilot phase. Full-company cutover on day one = help-desk apocalypse. Pilot with 1 team first.
• Not training users. SharePoint is a different tool; users will be confused. Training investment pays back in support ticket reduction.
• Decommissioning file server too fast. Wait 30-60 days after cutover before powering down. Users will discover missed files.

Cost math

Typical 50-employee small business migration:

• Microsoft Migration Manager: free.
• Consultant hours (if outsourced): 40-80 hours at $150-$250/hr = $6,000-$20,000.
• DIY IT time: 60-120 hours over 6-8 weeks.
• Training materials + sessions: 8-16 hours.
• Cold storage for archived content: $50-$200/month ongoing.

Cost avoided: file server replacement ($5,000-$10,000 hardware + $500-$2,000/year maintenance + backup solution). Migration pays for itself within 1-2 years even with consultant help; DIY migration is essentially just IT staff time.

Timeline for typical small business

• Small (10-25 employees, 100-500 GB): 4-6 weeks total.
• Medium (25-100 employees, 500 GB – 2 TB): 8-12 weeks.
• Large (100+ employees, 2 TB+): 12-24 weeks, likely with consultant.

Related M365 topics

File-server-to-SharePoint migration ties into several other M365 admin decisions: M365 admin center basics for tenant management, SharePoint vs OneDrive vs Google Drive for the storage architecture decision, and Entra ID setup for the identity layer underneath.

Key takeaways

• Clean up before migrating — 30-50% of a typical file server is candidate for archive or deletion.
• Design site-per-team, not one giant site with nested folders.
• Use Microsoft Migration Manager (free) for most small business migrations; third-party tools for complex scenarios.
• Pilot with one team before company-wide cutover.
• Plan 4-24 weeks total depending on size; keep old server read-only for 30-60 days post-cutover.

FAQ

Can I keep some files on the file server AND put others in SharePoint? Short-term yes (during migration transition); long-term no. Hybrid file storage confuses users about “where is this document?” Complete the migration, retire the file server, single source of truth. If some files must stay on-prem (specialty applications requiring local file access), keep those specific systems and move everything else.

What about really large files (video, CAD)? SharePoint has a 250 GB per-file limit — plenty for most business files. For very large media libraries, consider dedicated storage (Azure Files, Backblaze B2) with SharePoint linking to the storage location instead of storing directly.

Do we lose our file server’s mapped drive letter (S:\)? Yes — SharePoint doesn’t map to a drive letter natively. But OneDrive Sync creates a folder in Windows Explorer that functions similarly. Alternatively, some third-party tools (Zee Drive, Mountain Duck) map SharePoint to a drive letter for organizations that need that specific behavior.