How to migrate a file server to SharePoint and OneDrive

Most small businesses that still run a file server know it is a liability. The hardware is aging, the backups are questionable, remote access is either nonexistent or held together with a VPN that nobody likes using, and the folder structure has been accumulating cruft since the day it was set up. Migrating to SharePoint and OneDrive eliminates the dependency on a physical server, gives everyone access to files from anywhere, and shifts backup responsibility to Microsoft’s infrastructure. If the file server is one of several roles on the same physical server (file shares plus apps plus a domain controller), see how to move your on-premises server to the cloud first – the right answer might be different per workload.

The migration itself is not complicated in concept – you are copying files from one location to another. What makes it difficult in practice is the planning. A file server that has been in use for years has deeply nested folders, inconsistent permissions, files that nobody has opened in a decade, and a structure that made sense to whoever set it up but makes no sense to anyone else. Moving all of that to SharePoint without cleaning it up first just moves the mess to the cloud.

This guide covers how to plan the migration, which tools to use, what to clean up before moving, and how to communicate the change to your team so the transition does not disrupt daily work. If file storage is one of several things you are looking to move and you have not yet decided what to migrate first, start with moving your business to the cloud: where to start – file storage is usually stage two, after email and identity.

File server to SharePoint migration at a glance

Short answer: A typical 25-person small business file server migration to SharePoint and OneDrive takes 4 to 8 weeks end to end and follows five phases: audit (what is on the file server, how big, how deep, who has access), clean up (delete, archive, or flatten – typical projects shrink the data 20 to 40% before a single byte gets uploaded), design the destination (which Teams sites get which folders, where personal files map to OneDrive), migrate in batches (pilot first, then department by department, with a delta sync at cutover), and decommission (read-only standby for 2 to 4 weeks before turning the server off). The actual file copy is not the hard part. The hard parts are the cleanup, the destination structure design, and the permissions – and rushing any one of them is what turns a clean migration into a six-month “where did my files go” project.

Migration scope	Typical timeline	Recommended tool	Notable gotcha
Under 100 GB, under 10 users, simple structure	2 to 3 weeks	SharePoint Migration Tool (SPMT)	Often a weekend project if data is clean
100 to 500 GB, 10 to 50 users	4 to 8 weeks	SPMT or Migration Manager	Path length issues + permission cleanup dominate timeline
500 GB to 2 TB, 25 to 100 users	8 to 16 weeks	Migration Manager or third-party (ShareGate, AvePoint)	SharePoint storage limits start mattering; pre-clean essential
Over 2 TB, multi-department, complex permissions	16 to 32 weeks	Third-party tool + dedicated project management	Likely needs Azure Files or hybrid storage tier; not pure SharePoint
Over 5 TB or hot media files	Reconsider destination	Azure Files / Azure NetApp Files	SharePoint is not the right destination for media archives or large datasets

The single biggest factor on every migration is not file count or size – it is how clean the source is. A 50 GB file server with thoughtful folder structure and clean permissions migrates faster than a 200 GB file server with a decade of accumulated cruft and 17 different permission overrides.

Should you migrate, or replace differently?

Before assuming SharePoint and OneDrive is the destination, evaluate the alternatives. SharePoint is the right answer for most SMB file servers, but not all of them.

Workload type	Recommended destination	When SharePoint is wrong
Office documents (Word, Excel, PowerPoint), PDFs, departmental files	SharePoint + OneDrive	Almost always the right answer
Personal user files (H: drives, home directories)	OneDrive (per user)	Almost always the right answer
Large media archives (video, audio, raw photo, 3D rendering)	Azure Files / Azure Blob with on-prem cache	SharePoint sync gets unstable above 15 GB per file
CAD files, engineering files with check-in/check-out workflows	Azure Files or specialized tool (Autodesk Vault, Egnyte)	SharePoint co-authoring breaks workflows that require explicit locks
Database files (Access, MDF, BAK)	Azure SQL or stay on-prem	Database files do not belong in document libraries
Application data files	Stay on-prem or Azure Files attached to the app	The app, not the storage, is the migration target – see server migration
Compliance archives with retention requirements	SharePoint with retention policies + Microsoft Purview, OR Azure Blob	Depends on retention requirements; Purview handles most SMB cases

For a typical SMB file server with mixed content, the answer is usually SharePoint and OneDrive for the bulk of it, plus Azure Files for the workloads that do not fit (large media, CAD, app data). It does not have to be one destination for everything – and pretending it does is how SharePoint migrations end up trying to host things SharePoint was never designed for.

If most of your file server is media archives or CAD files, the migration is not really a SharePoint migration – it is an Azure migration, and the strategy is closer to lift-and-shift than to replace-with-SaaS. See lift and shift vs re-platform vs re-architect for the broader strategy framing.

Before you start: audit the file server

Do not start copying files until you understand what you have. A file server audit answers four questions:

How much data?

Check total size and size per top-level folder:

# Total size of the shared drive
Get-ChildItem -Path "D:\SharedDrive" -Recurse | Measure-Object -Property Length -Sum

# Size per top-level folder
Get-ChildItem -Path "D:\SharedDrive" -Directory | ForEach-Object {
    $size = (Get-ChildItem -Path $_.FullName -Recurse -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum
    [PSCustomObject]@{
        Folder = $_.Name
        SizeMB = [math]::Round($size / 1MB, 2)
    }
} | Sort-Object SizeMB -Descending | Format-Table -AutoSize

SharePoint Online has a pooled storage limit of 1 TB plus 10 GB per licensed user. A 20-person business gets 1.2 TB. If your file server has 3 TB of data, you need to decide what actually needs to migrate versus what can be archived or deleted. For a breakdown of storage limits per plan, see Microsoft 365 licensing explained for small business.

How deep is the folder structure?

SharePoint has a 400-character limit on the full file path (site URL + library + folders + filename). A file server with paths like \\server\shared\Clients\Acme Corp\Projects\2019\Phase 2\Documentation\Final Drafts\Approved\v3\report-final-FINAL-v2.docx will hit this limit.

Find your deepest paths:

Get-ChildItem -Path "D:\SharedDrive" -Recurse -ErrorAction SilentlyContinue |
    Where-Object { $_.FullName.Length -gt 200 } |
    Select-Object FullName, @{Name="Length";Expression={$_.FullName.Length}} |
    Sort-Object Length -Descending |
    Select-Object -First 20

Any path over 200 characters needs attention before migration. Either flatten the folder structure, shorten folder names, or shorten file names.

What file types exist?

SharePoint blocks certain file types and has size limits per file (250 GB max, but files over 15 GB may have sync issues). Check for blocked file types and oversized files:

# Files over 15 GB
Get-ChildItem -Path "D:\SharedDrive" -Recurse -ErrorAction SilentlyContinue |
    Where-Object { $_.Length -gt 15GB } |
    Select-Object FullName, @{Name="SizeGB";Expression={[math]::Round($_.Length / 1GB, 2)}}

# Potentially problematic characters in filenames
Get-ChildItem -Path "D:\SharedDrive" -Recurse -ErrorAction SilentlyContinue |
    Where-Object { $_.Name -match '[#%&\*\{\}\\<>\?/\|"]' } |
    Select-Object FullName

SharePoint does not allow these characters in file or folder names: " * : < > ? / \ |. Files with these characters need to be renamed before migration.

Who has access to what?

Document the current permission structure. On most file servers, permissions are set per folder using Active Directory groups or individual user assignments:

# List permissions on top-level folders
Get-ChildItem -Path "D:\SharedDrive" -Directory | ForEach-Object {
    $acl = Get-Acl $_.FullName
    [PSCustomObject]@{
        Folder = $_.Name
        Access = ($acl.Access | Where-Object { $_.IdentityReference -notlike "BUILTIN\*" -and $_.IdentityReference -notlike "NT AUTHORITY\*" } | ForEach-Object { "$($_.IdentityReference) ($($_.FileSystemRights))" }) -join "; "
    }
}

You will need to map these permissions to SharePoint permission groups when you set up the destination.

Planning the destination structure

This is the most important step and the one most businesses rush through. The file server folder structure should not be replicated exactly in SharePoint. SharePoint is not a file server – it works differently and works best with a different organizational approach.

Map folders to SharePoint sites

The top-level folders on your file server typically correspond to departments, clients, or projects. Each of these maps to a SharePoint site:

File server folder	SharePoint destination
\SharedDrive\Marketing\	Marketing team SharePoint site
\SharedDrive\Sales\	Sales team SharePoint site
\SharedDrive\HR\	HR team SharePoint site
\SharedDrive\Clients\	Individual client sites or a single Clients site
\SharedDrive\Templates\	Company-wide SharePoint site
\SharedDrive\Finance\	Finance team SharePoint site

If you are already using Microsoft Teams, each team already has a SharePoint site. Use those existing sites rather than creating new ones. The Marketing team’s SharePoint site is the natural destination for the Marketing folder from the file server.

Map personal folders to OneDrive

If your file server has personal home directories (H: drives, user folders), these map to individual OneDrive accounts. Each user’s personal files go to their OneDrive, not to SharePoint.

Flatten the hierarchy

A file server might have:

\SharedDrive\Marketing\Campaigns\2024\Q3\Social Media\Facebook\Approved\Final\

In SharePoint, flatten this to:

Marketing site > Documents > Campaigns > 2024-Q3-Social

Two to three levels of folders is the sweet spot for SharePoint. Deeper than that and navigation becomes painful, sync issues increase, and path length limits become a problem. Use descriptive folder names instead of deep nesting.

Decide what not to migrate

This is where you save the most time and storage. Every file server has data that should not be migrated:

• Duplicates. Multiple copies of the same file in different folders.
• Old backups. Zip files, database dumps, and backup archives that someone saved to the shared drive years ago.
• Personal files in shared folders. Music collections, photos, personal documents that ended up on the shared drive.
• Obsolete project files. Projects completed years ago that nobody will reference again.
• Temporary files. .tmp, ~$ lock files, thumbs.db, desktop.ini.
• Software installers. Old setup files for applications that are no longer used.

A typical file server cleanup removes 20-40% of the data before migration. Less data means a faster migration and a cleaner destination.

A pragmatic framework: migrate, archive, retire

For every top-level folder on the file server, pick one of three outcomes:

• Migrate to SharePoint or OneDrive. Files anyone has touched in the last 12 to 24 months and that the business actively uses.
• Archive to cold storage. Files nobody has touched in 2+ years but that have legal, compliance, or institutional-knowledge value. Move them to Azure Blob Storage cool/archive tier or a backup vault. Cheap to keep, retrievable if needed, out of the way of daily work.
• Retire entirely. Old project files for projects that wrapped, software installers for apps you no longer run, ad-hoc backups someone saved years ago. Delete after a final backup snapshot.

Run a quick last-modified-date scan to feed this decision:

# Files NOT modified in 2+ years (archive or retire candidates)
$cutoff = (Get-Date).AddYears(-2)
Get-ChildItem -Path "D:\SharedDrive" -Recurse -ErrorAction SilentlyContinue |
    Where-Object { $_.LastWriteTime -lt $cutoff -and -not $_.PSIsContainer } |
    Group-Object { $_.Directory.FullName.Substring("D:\SharedDrive".Length).Split('\')[1] } |
    Select-Object Name, Count, @{Name="TotalGB";Expression={[math]::Round(($_.Group | Measure-Object Length -Sum).Sum / 1GB, 2)}} |
    Sort-Object TotalGB -Descending

Top-level folders where 80%+ of the data is over 2 years old are usually archive candidates, not migrate candidates. The migration becomes faster and the SharePoint destination becomes more useful.

Choosing a migration tool

SharePoint Migration Tool (SPMT)

Microsoft’s free tool for migrating from on-premises file shares and SharePoint Server to SharePoint Online. It is the most straightforward option for small businesses.

SPMT runs on a Windows machine that has access to the file server. It reads files from the source, uploads them to SharePoint Online, and preserves file metadata (created date, modified date, author where possible).

Download SPMT from Microsoft’s website and install it on a machine that has:

• Network access to the file server
• Internet access to upload to SharePoint Online
• Enough local disk space for temporary staging (at least 10% of the data being migrated)

Migration Manager

Migration Manager is the cloud-based version of SPMT, managed from the SharePoint admin center. It uses agents installed on one or more on-premises machines to perform the actual file transfer. The advantage over SPMT is centralized management – you can monitor progress, schedule migrations, and manage multiple agents from the admin center.

For a single file server migration under 1 TB, SPMT is simpler. For larger migrations or migrations from multiple file servers, Migration Manager scales better.

Third-party tools

ShareGate, AvePoint, and BitTitan are popular third-party migration tools with more features than SPMT – better reporting, permission mapping, scheduling, and delta sync capabilities. They are paid tools and are typically used by MSPs or IT consultants who run migrations regularly. For a one-time small business migration, SPMT is usually sufficient.

Running the migration

Step 1: Set up the destination

Create the SharePoint sites and document libraries before starting the migration. If you are using Teams, the sites already exist – you just need to create any additional folders within the document libraries.

Verify permissions on each destination site. The people who had access to the file server folder should be members of the corresponding SharePoint site or Team.

Step 2: Run a pilot migration

Do not migrate everything at once. Start with one folder – ideally a small, non-critical department folder – and migrate it as a test. The pilot maps directly onto the phased rollout step in the cloud migration checklist for small business – same principle, applied to file shares specifically.

After the pilot:

• Verify files arrived correctly
• Check that folder structure matches expectations
• Confirm file metadata (dates, authors) was preserved
• Test permissions – can the right people access the files?
• Have someone from that department use the new location for a day and report issues

Step 3: Migrate in batches

Migrate department by department rather than everything at once. This lets you:

• Communicate with each department before their migration
• Fix issues discovered in one batch before the next
• Avoid overwhelming the internet connection with a massive upload
• Allow each department to validate their files before moving on

A typical schedule for a 20-person business:

• Week 1: Pilot migration (one small folder)
• Week 2: Department 1 + personal home drives for department 1
• Week 3: Department 2 + personal home drives for department 2
• Week 4: Remaining departments
• Week 5: Final validation and cleanup

Step 4: Handle permissions

SPMT can attempt to map file server permissions to SharePoint permissions, but the mapping is rarely perfect. File server permissions use Windows ACLs (Access Control Lists) and Active Directory groups. SharePoint permissions use SharePoint groups and Microsoft 365 Groups.

For most small businesses, the simplest approach is:

1. Set up SharePoint permissions manually based on who needs access (not what the file server had)
2. Use Teams membership as the primary access control (if someone is a member of the Marketing team, they have access to the Marketing SharePoint site)
3. Create specific permission levels only where needed (a subfolder that only managers should access)

Trying to replicate the exact file server permission structure in SharePoint usually creates an unmaintainable mess. Use the migration as an opportunity to simplify permissions.

Step 5: Delta sync

After the initial migration, files may continue to be created or modified on the file server while people are still using it. Before cutting over, run a delta sync to catch any changes since the initial migration:

In SPMT, run the same migration task again. It detects which files are new or modified since the last run and uploads only those files. This keeps the SharePoint destination current with minimal transfer time.

Communicating the change

Technical migration is half the work. The other half is making sure your team knows what changed and where to find their files.

Before migration

Send a clear communication covering:

• When the migration is happening (specific dates per department)
• Where files will be after migration (which SharePoint site, how to get there)
• How to access files going forward (sync to desktop, browser access, through Teams)
• What is not migrating (if you are cleaning up old data, tell people so they can flag anything they need)

During migration

Keep the file server accessible in read-only mode during migration if possible. This prevents new files being created on the file server that would be missed by the migration, while still allowing people to access files they need.

After migration

• Show people how to sync SharePoint libraries to their desktop using the OneDrive sync client. For most users, the experience is nearly identical to accessing files on a mapped network drive.
• Provide a cheat sheet mapping old file server paths to new SharePoint locations. “Your files from \\server\shared\Marketing\ are now in the Marketing team > Documents in Teams.”
• Set a cutoff date for the file server. After validation, disable write access. After a comfort period (two to four weeks), decommission the file server entirely.

Training

Most people need to learn three things:

1. How to find their files in the new location (through Teams or SharePoint)
2. How to sync a SharePoint library to their desktop
3. When to save to OneDrive vs SharePoint

Keep it simple. A 15-minute walkthrough per department is more effective than a company-wide training session. For the OneDrive vs SharePoint decision, point them to the rule: personal files go to OneDrive, shared files go to SharePoint.

After the migration

Validate

Go through each department’s files and verify:

• All files arrived (compare file counts and total size between source and destination)
• Folder structure makes sense
• Permissions are correct
• No files were skipped due to path length, character, or size issues

SPMT generates a migration report showing successes, failures, and skipped files. Review this report for every batch.

Monitor adoption

Watch for signs that people are not using the new system:

• Files still being saved to local drives instead of OneDrive/SharePoint
• People emailing files instead of sharing links
• New shared drives being created on someone’s local machine
• Complaints about not being able to find files

Address these individually. Most resistance comes from not knowing where things are, which is a communication problem, not a technology problem.

Decommission the file server

Once you are confident the migration is complete and the team is working in the new environment:

1. Make the file server read-only for two to four weeks
2. Monitor for access attempts (anyone still trying to use it needs redirection)
3. Take a final backup of the file server for archival purposes
4. Shut down or repurpose the server

Do not rush this step. Keeping the old file server available in read-only mode as a safety net costs nothing and prevents panic if someone discovers a missing file weeks after the migration.

Common problems and how to handle them

Path length errors

Files with paths over 400 characters fail to migrate. Fix before migrating by shortening folder names and flattening the structure. SPMT’s pre-scan report identifies these files.

Special characters in filenames

Files containing # % & * { } \ < > ? / | in their names fail. Rename them on the file server before migrating, or use a script:

Get-ChildItem -Path "D:\SharedDrive" -Recurse |
    Where-Object { $_.Name -match '[#%&\*\{\}\\<>\?/\|"]' } |
    ForEach-Object {
        $newName = $_.Name -replace '[#%&\*\{\}\\<>\?/\|"]', '_'
        Rename-Item -Path $_.FullName -NewName $newName
    }

Large files

Files over 15 GB may have sync issues with the OneDrive sync client. Files over 250 GB cannot be uploaded to SharePoint at all. For large media files or archives, consider whether they belong in SharePoint or should be stored in a cheaper alternative (Azure Blob Storage, a backup service).

Permission complexity

If your file server has granular permissions at many folder levels (folder A has different access than subfolder B which has different access than sub-subfolder C), reproducing this in SharePoint is painful and usually unnecessary. Simplify by setting permissions at the site and library level only, using private channels in Teams for restricted content.

Slow upload speeds

Migration speed depends on your internet upload bandwidth. A 500 GB migration over a 50 Mbps upload connection takes roughly 22 hours of continuous transfer. Plan accordingly – start migrations in the evening or over weekends if bandwidth is limited during business hours.

SPMT supports throttling to avoid saturating your internet connection during work hours.

When to get help

A file server migration for a 5-person business with 50 GB of organized files is a weekend project. A migration for a 30-person business with 500 GB of files accumulated over 10 years, complex permissions, and deeply nested folders is a multi-week project that benefits from professional planning.

Consider getting help if:

• Your file server has over 500 GB of data
• The folder structure is more than four levels deep in most areas
• You have complex permissions with different access at many folder levels
• You are also migrating from on-premises Exchange to Microsoft 365 at the same time
• You have compliance requirements that affect how files are stored and retained
• Your team has low tolerance for disruption and needs a seamless transition

Sequentur’s managed Microsoft 365 services include file server migration as a project service. We handle the audit, structure planning, tool configuration, migration execution, permission setup, and staff communication so the transition does not fall on your internal team. If your Microsoft 365 security settings have not been hardened alongside the migration, we address that at the same time – moving files to the cloud without configuring sharing policies and access controls properly just creates new risks.

Common file server migration mistakes

These are the strategic and planning mistakes that cost SMBs the most time after the migration is technically “done.”

1. Treating it as a copy job. “Just copy the files to SharePoint” is the most expensive sentence on this list. Without the audit, the cleanup, the destination design, and the permission decisions, the migration just moves the mess to a more expensive place.

1. Replicating file server permissions exactly. Years of accumulated NTFS permission overrides at folder, subfolder, and file level do not translate cleanly to SharePoint. Trying to recreate them creates an unmaintainable mess. Use the migration as the moment to simplify – that is the highest-leverage outcome of the project.

1. Skipping the cleanup. Migrating 800 GB when the business only actively uses 250 GB. The other 550 GB is duplicate, obsolete, or archive material that should not have come along. Cleanup is the single highest-ROI step in the migration.

1. Migrating everything to one big SharePoint site. A single team site with 200 folders at the top level is unnavigable. Map departments and teams to separate sites. If you already use Teams, the sites already exist.

1. Not doing a pilot. Migrating all 25 users at once. The first batch is where every issue surfaces – path length problems, character problems, permission gaps, sync failures. Do them with one small department first, fix what you find, then scale.

1. Forgetting the SharePoint storage limit. SharePoint Online provides 1 TB pooled per tenant + 10 GB per licensed user. A 20-person business has 1.2 TB. If the file server holds 3 TB, the migration plan needs an additional storage decision (Azure Files for the overflow, or aggressive archival) before SPMT runs.

1. Migrating media archives that do not belong in SharePoint. Files over 15 GB cause sync issues. Files over 250 GB cannot be uploaded at all. Video archives, raw photo libraries, and large datasets belong in Azure Files or Azure Blob, not SharePoint document libraries.

1. Skipping the read-only standby on the source. Decommissioning the file server the same week the migration completes. Leave it read-only for 2 to 4 weeks as a safety net. Cost: nothing. Benefit: when somebody discovers a missing file three weeks in, you have a recovery path.

1. No communication plan. The technical migration succeeds. The team has no idea where their files are. Help desk gets buried for two weeks. The fix is a 15-minute walkthrough per department plus a path-mapping cheat sheet, sent before the migration, not after.

1. Doing it the same weekend as another major change. The Exchange migration, the new laptops, the VPN rollout – and the file server migration. One change at a time. If you must combine, the file server can usually wait.

For the broader project-management spine that holds these decisions together, see the cloud migration checklist for small business.

Summary

Migrating a file server to SharePoint and OneDrive eliminates hardware dependency, enables remote access, and shifts backup responsibility to Microsoft. The technical migration is straightforward with Microsoft’s free tools (SPMT or Migration Manager). The hard part is the planning: auditing what you have, cleaning up what you do not need, designing a sensible SharePoint structure, mapping permissions, and communicating the change to your team.

Do not replicate the file server structure exactly in SharePoint. Flatten the hierarchy, simplify permissions, and use the migration as an opportunity to organize files properly. Migrate in batches, validate each batch, and keep the old file server accessible in read-only mode until you are confident everything is in place.