File Share Migration to SharePoint Online: A Practical Guide for IT Teams

TL;DR

File share migrations to SharePoint Online involve more than just copying folders into document libraries. The structure, naming conventions, permissions, and file path limitations in SharePoint Online are fundamentally different from a traditional file server. Without proper planning, teams end up recreating a messy network drive inside SharePoint.

This guide covers the practical steps I follow when migrating file shares to SharePoint Online, including discovery, cleanup, structure mapping, permissions, migration execution, and user adoption.

Why file share migrations are different
Discovery and assessment
Content cleanup before migration
Mapping file shares to SharePoint structure
Handling file path and naming limitations
Permissions strategy
Choosing a migration tool
Migration execution
Post-migration validation
User adoption and change management
Final thoughts
FAQ

File share migrations to SharePoint Online come with unique challenges that do not exist in a SharePoint-to-SharePoint migration.

File servers have almost no enforced structure. Folders are nested deeply, files are duplicated across departments, permissions are applied inconsistently, and there is no metadata to work with. When you move this content into SharePoint Online without rethinking the structure, you end up with the same problems in a new platform.

Here are the key differences that affect planning:

No metadata on file shares. SharePoint Online relies on metadata for filtering, views, and search. File shares have none of this, so you need to plan for metadata tagging after migration or use folder-to-metadata mapping strategies.
Folder depth matters. File servers often have deeply nested folders (10 or more levels). SharePoint Online has a 400-character URL path limit, so deep nesting causes failures during migration.
Permissions are applied differently. File share permissions use NTFS ACLs that do not map directly to SharePoint Online groups and permission levels.
File naming restrictions. SharePoint Online does not allow certain characters in file and folder names that Windows file servers do allow, such as #, %, &, *, and others.
No concept of mapped drives. Users are accustomed to accessing content through mapped drives like S:\ or H:\. Moving to SharePoint Online requires changing how users access their files.

Understanding these differences upfront prevents the most common migration failures.

2. Discovery and Assessment

Before planning the migration, I need to understand what is on the file share today. Discovery is the step where I collect data about the environment so I can make informed decisions about structure, cleanup, and timelines.

What to collect during discovery

Total volume of data across all shares targeted for migration.
Folder structure depth to identify paths that will exceed SharePoint Online limits.
File count and average file size to estimate migration duration.
Last modified dates to identify stale content (files not touched in 2 or more years).
Duplicate files across different shares or folders.
File types to identify unsupported or blocked file types.
Current NTFS permissions at the share and folder level.
Files with invalid characters that will need renaming before migration.
Files exceeding the 250 GB file size limit in SharePoint Online.

Tools for discovery

For most file share discovery, I use PowerShell scripts to scan the environment and export the results to CSV or Excel. A few things I look for:

# Example: Find files not modified in the last 2 years
Get-ChildItem -Path "\\server\share" -Recurse -File |
  Where-Object { $_.LastWriteTime -lt (Get-Date).AddYears(-2) } |
  Select-Object FullName, Length, LastWriteTime |
  Export-Csv -Path "StaleFiles.csv" -NoTypeInformation

# Example: Find files with invalid characters for SharePoint Online
Get-ChildItem -Path "\\server\share" -Recurse |
  Where-Object { $_.Name -match '[#%&*:{}<>?/\\|"]' } |
  Select-Object FullName, Name |
  Export-Csv -Path "InvalidCharacters.csv" -NoTypeInformation

# Example: Find paths exceeding 400 characters
Get-ChildItem -Path "\\server\share" -Recurse |
  Where-Object { $_.FullName.Length -gt 400 } |
  Select-Object FullName, @{Name="PathLength";Expression={$_.FullName.Length}} |
  Export-Csv -Path "LongPaths.csv" -NoTypeInformation

You can also use the SharePoint Migration Assessment Tool (SMAT) from Microsoft for a more complete assessment, though it was originally designed for SharePoint on-premises sources.

The output of this discovery phase drives every decision that follows.

3. Content Cleanup Before Migration

One of the biggest mistakes I see is migrating everything from the file share without any cleanup. If the file share has 5 TB of data and 40 percent of it has not been accessed in three years, there is no reason to bring that into SharePoint Online.

Cleanup priorities

Delete or archive stale content. Files not modified in 2 or more years should be reviewed with the content owners. Archive what needs to be retained and delete the rest.
Remove duplicates. File shares commonly have multiple copies of the same file in different folders. Identify and consolidate duplicates before migration.
Flatten unnecessary folder depth. Where folders are nested 8 to 10 levels deep with only a few files at each level, consider restructuring before migration.
Rename files with invalid characters. Fix file and folder names that contain characters unsupported in SharePoint Online.
Handle oversized files. Files larger than 250 GB cannot be uploaded to SharePoint Online. Determine an alternative storage solution for these files.

Getting content owner buy-in

Content cleanup is not something IT can do alone. Each department or team should review their own content and decide what to keep, archive, or delete. I usually provide each team with a report of their stale files and ask for a decision within a defined timeframe. If they do not respond, I apply a default policy, typically archiving stale content rather than migrating it.

4. Mapping File Shares to SharePoint Structure

This is the most important step. How you map the file share folder structure to SharePoint Online determines whether the new environment is usable or just another dumping ground.

General mapping principles

File Share Level	SharePoint Online Target
Top-level department share (e.g., `\\server\Finance`)	SharePoint site or Teams team
Major subfolders (e.g., `Invoices`, `Reports`, `Budgets`)	Document libraries within the site
Working folders within subfolders	Folders within document libraries or metadata-driven views

When to use sites vs libraries vs folders

Create a new SharePoint site for each major department or business unit that owns a distinct set of content.
Create separate document libraries for major content categories within a site. Libraries have their own permissions, views, and metadata columns.
Use folders sparingly within libraries. One or two levels of folders is fine. Beyond that, consider using metadata columns and views to organize content instead.

Using metadata instead of folders

In a file share, the typical structure might look like this:

\\server\HR\Policies\2025\Benefits\Medical\

In SharePoint Online, a better approach is to create an HR site with a Policies library and add metadata columns for Year, Category, and Type. Then use views to filter content instead of navigating through six levels of folders.

This approach makes content easier to find through search, easier to manage with retention policies, and easier to govern with consistent permissions.

5. Handling File Path and Naming Limitations

SharePoint Online has a 400-character limit for the entire URL path, including the site URL, library name, folder path, and file name combined. This is one of the most common causes of migration failures from file shares.

How to calculate the path

The full URL in SharePoint Online is constructed as:

https://tenant.sharepoint.com/sites/SiteName/LibraryName/Folder1/Folder2/FileName.docx

Every character in that URL counts toward the 400-character limit.

Common issues and fixes

Deep folder nesting: Flatten the structure during the mapping phase. Reduce nesting to 2 to 3 levels maximum.
Long file names: Work with content owners to shorten file names that exceed reasonable lengths.
Long folder names: Rename folders with overly descriptive names. A folder called 2024 Q4 Financial Reports - Final Approved Versions - Do Not Edit should become 2024-Q4-Financial-Reports.
Invalid characters: Rename files and folders that contain # % & * : < > ? / \ | and leading or trailing spaces.

Most migration tools will flag these issues during a pre-migration scan. Fix them before running the actual migration to avoid partial failures and manual cleanup afterward.

6. Permissions Strategy

File share permissions are managed through NTFS ACLs and share-level permissions. SharePoint Online uses SharePoint groups, Microsoft 365 groups, and Azure AD security groups. These two models do not map directly to each other.

Common permission patterns on file shares

Inherited permissions from the root of the share down to all subfolders.
Broken inheritance at specific folders where access is restricted to certain users or groups.
Individual user permissions granted directly instead of through groups.
Nested Active Directory groups with complex membership chains.

My approach to permissions mapping

Do not migrate NTFS permissions as-is. Attempting a one-to-one mapping from NTFS ACLs to SharePoint permissions creates an unmanageable mess.
Map Active Directory groups to Microsoft 365 groups or Azure AD security groups. Each SharePoint site should have a clear set of groups: Owners, Members, and Visitors.
Simplify where possible. If a file share had 15 unique permission sets across subfolders, evaluate whether SharePoint needs the same granularity. In most cases, simplifying to library-level or site-level permissions is sufficient.
Document the permission mapping in a spreadsheet so stakeholders can review and approve before migration.

Permissions after migration

After content is migrated, validate that permissions are working as expected. Spot-check access for key users in each department. Verify that external users or service accounts that need access have been properly added.

7. Choosing a Migration Tool

There are several migration tools available for file share to SharePoint Online migrations. The right choice depends on the volume of data, complexity of the environment, and budget.

Common migration tools

Tool	Best For
SharePoint Migration Tool (SPMT)	Free Microsoft tool, good for smaller migrations or straightforward file share moves
Migration Manager (in SharePoint Admin Center)	Centralized management of SPMT agents across multiple machines, good for larger scale
ShareGate	Feature-rich, good for complex migrations with permission mapping needs
AvePoint	Enterprise-grade, good for large organizations with compliance requirements
BitTitan MigrationWiz	Cloud-based, good for remote migrations without on-premises agents

What to look for in a migration tool

Pre-migration scanning to identify issues before they become failures.
Incremental migration support so you can run an initial pass and then a delta sync closer to cutover.
Logging and reporting to verify what was migrated successfully and what failed.
Scheduling to run migrations during off-hours and minimize impact on network bandwidth.
File path and naming issue detection before migration starts.

For most file share migrations, I start with Migration Manager in the SharePoint Admin Center because it handles the majority of scenarios without additional licensing costs. For more complex environments, I bring in ShareGate or AvePoint.

8. Migration Execution

Once discovery, cleanup, structure mapping, and permissions are defined, the actual migration can begin.

Migration phases

Pre-migration scan. Run the migration tool in scan-only mode to identify all issues. Fix them before proceeding.
Pilot migration. Pick one department or share as a pilot. Migrate it, validate it with the business, and collect feedback before scaling to the full environment.
Bulk migration (initial pass). Migrate all content in bulk. This is the longest phase and can take days or weeks depending on data volume and network bandwidth.
Delta sync. After the initial pass, users continue working on the file share. Run a delta sync shortly before cutover to capture any changes made since the bulk migration.
Cutover. At the scheduled cutover date, disable write access to the file share, run a final delta sync, and switch users to SharePoint Online.

Bandwidth and throttling

SharePoint Online applies throttling when large volumes of content are uploaded in a short period. To manage this:

Spread migration across multiple days or weeks.
Schedule large migrations during evenings or weekends.
Use multiple migration agents if the tool supports it (Migration Manager does).
Monitor the migration dashboard for throttling indicators.

Communication to users

Users need to know:

When the migration will happen.
What will change for them (new URLs, OneDrive sync, Teams access).
Where to find their content after migration.
Who to contact if something is missing or broken.

Send communications at least two weeks before the cutover and again the day before.

9. Post-Migration Validation

After migration completes, validation ensures that nothing was lost or broken during the move.

Validation checklist

File count comparison. Compare the number of files on the source file share with the number of files in the destination SharePoint libraries.
Folder structure verification. Spot-check that the folder structure in SharePoint matches the expected mapping.
Permissions verification. Test access with sample users from each permission group to confirm they can access the correct content.
File integrity. Open a sample of critical files (Word, Excel, PDF) to ensure they are not corrupted.
Metadata validation. If metadata was applied during migration, confirm that columns are populated correctly.
Search validation. Search for known files to verify they appear in SharePoint search results. There may be a delay as the search index processes new content.
Migration tool logs. Review the migration tool’s success and failure logs. Investigate and remediate any failed items.

Handling failed items

Every migration has some failed items. Common failures include:

Files with unsupported characters that were not caught during the pre-scan.
Files locked by another process during migration.
Files exceeding size limits.
Paths that exceeded the 400-character limit.

Review the failure log, fix the underlying issues, and re-run migration for the failed items only.

10. User Adoption and Change Management

This is the step that separates a technically successful migration from one that users actually embrace.

Key adoption activities

Training sessions. Run short training sessions (30 minutes) showing users how to navigate SharePoint, use OneDrive sync, and find their files.
Quick reference guides. Create one-page guides with screenshots showing the old file share path and the new SharePoint location.
OneDrive sync setup. Help users set up OneDrive sync for libraries they access frequently. This gives them a familiar File Explorer experience.
Champions network. Identify one or two users per department who can help their colleagues with the transition.
Decommission the file share. After validation and a grace period (typically 2 to 4 weeks), make the old file share read-only and eventually decommission it. Keeping the old file share available indefinitely undermines adoption.

Tracking adoption

Use SharePoint site analytics and Microsoft 365 usage reports to monitor whether users are actually accessing content in the new location. If adoption is low for a specific department, follow up and address any barriers.

11. Final Thoughts

File share migrations to SharePoint Online are not complex because of the technology. They are complex because file shares have been accumulating unstructured content for years, often decades, and moving that content into a structured platform requires deliberate planning.

The most important things I have learned from running these projects:

Cleanup before migration saves more time than cleanup after. It is always easier to delete or archive stale content before it is spread across SharePoint sites.
Structure mapping is the most valuable planning activity. Getting the site and library structure right from the start prevents rework later.
Permissions should be simplified, not replicated. The goal is a manageable permission model, not a copy of the NTFS ACL chaos.
User adoption determines success. A technically perfect migration that nobody uses is still a failure.

FAQ

It depends on data volume, network bandwidth, and migration tool. As a rough estimate, expect 1 to 2 TB per day with Migration Manager under good conditions. Factor in time for discovery, cleanup, pilot, and validation, not just the file copy phase.

Some tools support mapping NTFS permissions to SharePoint permissions, but I do not recommend a direct one-to-one mapping. File share permissions are often messy and inconsistent. Use the migration as an opportunity to simplify and standardize your permission model.

What happens to files with long paths?

Files with paths exceeding the 400-character SharePoint Online URL limit will fail during migration. Identify these during discovery and either shorten the paths or restructure the target location to reduce URL length.

Should I use OneDrive or SharePoint for migrated content?

Use SharePoint document libraries for shared team content and OneDrive for personal files (home drives, personal folders). If the content on the file share is accessed by multiple people, it belongs in SharePoint.

What about file shares with compliance or retention requirements?

Apply Microsoft 365 retention labels and policies to the SharePoint libraries after migration. Map any existing retention schedules from the file share to equivalent retention labels in Microsoft Purview.

Keep it read-only for a grace period of 2 to 4 weeks after cutover. This gives users a safety net while they get comfortable with SharePoint. After the grace period, decommission the file share to drive adoption.