How to Migrate a File Share to SharePoint Online

Table of Contents

• Start With a File Server Migration Checklist
  • What to Inventory Before You Touch Anything
  • Cleanup Rules That Save Days Later
• Map Folders to Sites and Document Libraries
  • When to Use Teams, OneDrive, or a Standalone Site
• Using the SharePoint Migration Tool for File Share Content
  • Known Limits and How to Work Around Them
• SharePoint Online Migration Permissions and Identity Mapping
  • Why File-Server Permissions Don't Translate Cleanly
  • Build an Identity Mapping Table First
  • Default to Inheritance, Not Unique Permissions
  • Validate Permissions Before Cutover
• Build a SharePoint Migration Timeline That Survives Contact With Reality
  • Phase 1: Assessment (1-2 weeks)
  • Phase 2: Pilot (1-2 weeks)
  • Phase 3: Waves and Delta Sync (2-6 weeks)
  • Phase 4: Cutover Runbook
  • Validation and Success Metrics
• Validate the Migration and Prove It Worked
• Conclusion: Own the Environment After Cutover
• Frequently Asked Questions

Last Updated: October 12, 2026

Start With a File Server Migration Checklist

Learning how to migrate a file share to SharePoint Online starts long before you touch a single file. Too many teams open Migration Manager on day one and spend a month cleaning up the mess.

A file share migration checklist lists every folder, file type, owner, and permission on your source file server before anything moves, turning a lift-and-shift into small, testable steps.

What to Inventory Before You Touch Anything

Start with a content inventory.

• Total content volume in gigabytes
• Number of files and folders
• File types and extensions in use

Pull this with PowerShell or your migration tool's scanner, skipping the scan is a common mistake.

Cleanup Rules That Save Days Later

Pre-migration cleanup wins back time. Apply these rules before mapping:

• Delete duplicate files and stale content older than two years
• Archive anything legal or compliance teams still need
• Flatten folder structures deeper than five levels

Map Folders to Sites and Document Libraries

Mapping decides whether your new SharePoint environment is usable or a new mess. Every top-level folder should map to exactly one destination: a Microsoft Teams site, a OneDrive for Business account, or a standalone SharePoint site.

A document library is the container inside a SharePoint site where files live, a folder with version history, metadata, and permissions.

A simple mapping table keeps everyone honest:

Source Folder	Destination Type	Why
/Finance	Teams site	Department collaboration
/HR/Private	Standalone site	Restricted access
/Projects/2026	Teams site	Active project work
/Users/jsmith	OneDrive for Business	Personal files
/Archive	Standalone site	Read-only retention

When to Use Teams, OneDrive, or a Standalone Site

• Microsoft Teams for active team collaboration with chat and channels
• OneDrive for Business for personal files and drafts
• Standalone SharePoint site for shared content with no chat need, or for strict governance

If a folder has no clear owner, park it in a "TBD" site and revisit after the pilot.

Using the SharePoint Migration Tool for File Share Content

The SharePoint Migration Tool (SPMT) is Microsoft's free utility for moving file share content into SharePoint Online and OneDrive, handling bulk uploads, preserving metadata where possible, and reporting errors per file.

It suits small to mid-size shares. For larger migrations, the SharePoint Admin Center's Migration Manager adds centralized jobs, scheduling, and better reporting.

Known Limits and How to Work Around Them

• File size limits: SharePoint caps individual files. Split or archive anything over the limit.
• Path length: Long file paths fail silently. Shorten them before migration.
• Unsupported files: Some extensions are blocked by default. Check the list before you start.

SharePoint Online Migration Permissions and Identity Mapping

SharePoint Online migration permissions are the part most teams underestimate. On-premises file shares rely on local security groups, domain-local groups, and inherited ACLs with no direct Microsoft 365 equivalent. Copy files first and fix permissions later, and you'll spend weeks untangling access. Map identities before the first migration job runs.

Why File-Server Permissions Don't Translate Cleanly

Three structural differences cause most of the pain:

• Group scope. A file server may have hundreds of local groups like FS-Finance-RW that exist only on that machine. SharePoint Online has no concept of a machine-local group, every principal must be an Entra ID user, an Entra ID security group, a Microsoft 365 group, or a SharePoint group.
• Inheritance model. NTFS inheritance is folder-by-folder and can be broken at any level. SharePoint inheritance is library-by-library and item-by-item, and every break creates a unique permission scope that must be maintained separately.
• Permission granularity. NTFS has granular rights (Read & Execute, Modify, Write, Full Control, plus special permissions). SharePoint collapses these into three practical levels, Full Control, Edit, and Read, plus a few limited-access variants. Most file-server ACLs map to fewer SharePoint levels than admins expect.

Build an Identity Mapping Table First

Before any migration job, export the source ACLs and build a mapping table, with Get-Acl in PowerShell, AccessEnum, or your migration tool's scanner. One row per source principal:

Source Principal	Type	Target Principal	Target Type	Notes
FS-Finance-RW	Local group	Finance-Team	Microsoft 365 group	Maps to Teams site membership
DOMAIN\jsmith	User	[email protected]	Entra ID user	Personal OneDrive owner
FS-HR-Confidential	Local group	HR-Confidential	Entra ID security group	Unique permission on HR library
DOMAIN\Domain Admins	Domain group	(drop)	,	Use SharePoint Admin role instead

Rules that keep the mapping sane:

• Collapse redundant groups. If three source groups grant the same access to the same folders, map them to one target group.
• Drop domain-wide groups. Domain Users, Authenticated Users, and Everyone should never become SharePoint permissions, they grant access far beyond the original intent.
• Prefer Microsoft 365 groups for collaboration. They provision a Teams site, a SharePoint site, and a shared mailbox in one step, and membership is self-service for owners.

Default to Inheritance, Not Unique Permissions

The biggest long-term cost in a SharePoint migration is unique permissions: every library or item that breaks inheritance becomes a separate access-control problem. Teams that migrate cleanly enforce one rule: no unique permissions below the site level unless the content is genuinely restricted.

Practical approach:

1. Group source folders by audience, not by original folder path. If /Finance/Reports and /Finance/Budgets are both readable by the same group, they belong in the same library with inherited permissions.
2. Create a separate site or library only when the audience is truly different, for example, HR confidential content versus general HR content.
3. Use SharePoint groups (Site Owners, Site Members, Site Visitors) at the site level, and add Entra ID or Microsoft 365 groups to those SharePoint groups. This keeps membership management in one place.
4. For the rare item that needs unique access, a single contract, a single personnel file, use a dedicated library with broken inheritance rather than breaking inheritance on individual files.

Validate Permissions Before Cutover

Permission mapping is done when a test user from each source group can reach exactly the content they should, and nothing else. Run these checks before turning off the file server:

Schedule Free Consultation →

• Sign in as a member of each mapped group and confirm access to the expected libraries.
• Sign in as a user who should not have access and confirm they are blocked.
• Check that no library has more unique permission scopes than you planned for.

Microsoft guidance on SharePoint permission levels and inheritance

Build a SharePoint Migration Timeline That Survives Contact With Reality

A realistic SharePoint migration timeline has four phases: assessment, pilot, delta sync, and cutover. Size it by content volume and complexity, not wishful thinking: a 500 GB share with clean permissions moves faster than a 100 GB share with a decade of nested groups. Most mid-market migrations of a few hundred gigabytes to a few terabytes land in the six-to-twelve-week range.

Phase 1: Assessment (1-2 weeks)

Run the inventory scan, build the identity mapping table, and decide the destination for every top-level folder. Output: a signed-off mapping document and wave plan. Don't provision sites until this is done.

Phase 2: Pilot (1-2 weeks)

Pick one department or site's worth of content, representative complexity, not the easiest one. Migrate it end to end: files, metadata, permissions, and search. Validate with real users. The pilot surfaces file-path failures, unsupported extensions, and broken permission mappings. Fix them here, not in wave three.

Phase 3: Waves and Delta Sync (2-6 weeks)

Migrate the bulk of content in waves, one site at a time. Between waves, run a delta pass on migrated sites to pick up changed files; most tools support incremental jobs that copy only what changed.

Key mechanics for this phase:

• Freeze windows. For each wave, freeze writes to the source folders being migrated for the duration of the job. A short freeze (hours) is better than a long one (days).
• Delta before cutover. The final delta for each site should run as close to cutover as possible, ideally the same day, to minimize the gap between source and destination.
• Error triage. Set a threshold for acceptable error rate (a common target is under 1% of items) and stop the wave if you exceed it. Investigate before continuing.

Phase 4: Cutover Runbook

Cutover is a sequenced event, not a single action. A working runbook:

1. T-minus 5 business days: Notify all users of the cutover date and the read-only window.
2. T-minus 1 business day: Run a final delta on all sites. Confirm error rate is within threshold.
3. T-minus 0, start of window: Set the source file server to read-only. Announce the freeze.
4. During window: Run the final delta pass. Reconcile file counts and sizes per folder. Verify permissions with test accounts.
5. End of window: Redirect users to SharePoint. Update shortcuts, mapped drives, and any scripts or applications that pointed at the file server.
6. T-plus 1 business day: Monitor support queue. Keep the file server read-only but available as a fallback for at least two weeks.
7. T-plus 2 weeks: Decommission or archive the file server once no fallback requests have been logged.

Plan the cutover for a weekend or a low-usage window. A little downtime beats a week of confused users.

Validation and Success Metrics

You need measurable proof the migration worked before decommissioning anything. Track these during and after the job:

• File count and total size per folder, source versus destination. A mismatch means items failed silently.
• Error rate, percentage of items that failed to migrate. Investigate anything above your threshold.
• Permission accuracy, test-user checks per mapped group, plus a review of unique permission scopes.

Microsoft guidance on SharePoint Migration Manager and migration planning

Validate the Migration and Prove It Worked

Validation isn't optional: prove the destination matches the source before turning off the file server.

• Compare file counts and total size per folder
• Spot-check metadata and document properties
• Verify permissions with a test user in each group

Track migration throughput and error rate during the job. A rising error rate means something is wrong, stopping early saves cleanup later.

Conclusion: Own the Environment After Cutover

The hard part isn't the copy. It's the governance, user training, and adoption that follow. Without those, your new SharePoint environment becomes a fresh sprawl within a year.

MTRC Enterprises helps mid-market IT and operations teams plan, execute, and own their SharePoint Online migrations.

Schedule a free consultation with MTRC Enterprises and get a migration plan your team can actually run.

Frequently Asked Questions

What tool should I use to migrate a file server to SharePoint Online?

Microsoft's own Migration Manager (part of the SharePoint admin center) handles most file share migrations at no extra license cost. For very large content volumes, complex permission structures, or repeatable enterprise runs, third-party migration tools add throughput, scheduling, and better reporting. Whichever you choose, test it on a pilot folder first. Confirm it preserves file paths, timestamps, and permissions before you commit to a full run.

How do I preserve file permissions during a SharePoint Online migration?

Direct user permissions rarely survive a file share migration cleanly, so plan to rebuild access using Microsoft 365 groups and security groups instead of individual accounts. Export the current NTFS permissions, map each entry to an Entra ID identity, and decide which folder-level permissions become site permissions, library permissions, or broken inheritance. Test the mapping on a pilot library and verify that a sample of users sees exactly the folders they should.

How long does it take to migrate a file share to SharePoint Online?

Timelines depend on content volume, file count, and how much cleanup you do first. A file share migration typically runs in phases: one to three weeks for assessment and cleanup, one to two weeks to prepare sites and map permissions, then a pilot, a full delta sync, and a cutover weekend or evening. Small shares with clean data can finish in a few weeks; multi-terabyte shares with millions of small files take considerably longer.

How do I verify files after migrating them to SharePoint Online?

Run a reconciliation report that compares source and destination file counts, folder counts, and total size, then spot-check a random sample of documents for metadata, version history, and permissions. Review the migration tool's error log and remediate every failed item before you retire the source. Track error rate and throughput as your success metrics, and keep the source read-only for a set period so users have a fallback.