Before You Start: Make Three Important Decisions

Before installing a migration tool or copying any files, determine where the content should go, which migration tool you will use, and how permissions will be handled.

1. Choose the Right Destination

Not every file should be moved to the same location.

As a general rule:

• Team and departmental content should be moved to SharePoint Online or a Microsoft Teams-connected SharePoint site.
• Personal files, drafts, and individual working documents should be moved to OneDrive.

The destination should be based on who owns the content, who needs access to it, and how the files will be used after the migration.

2. Choose the Migration Tool

For many small and midsized migrations, the SharePoint Migration Tool, commonly known as SPMT, is a practical option.

A general starting point is:

• Use SPMT for migrations under approximately 2 TB.
• Consider Migration Manager for larger or more complex environments.

Migration Manager is often better suited for projects that require multiple migration agents, parallel processing, centralized monitoring, or migration across several locations.

3. Decide How Permissions Will Be Managed

You must also decide whether to preserve the existing NTFS permissions or build a new SharePoint permissions structure.

For organized file shares with clean security groups, preserving permissions may be reasonable.

For legacy environments with years of broken inheritance, outdated users, local groups, and inconsistent folder-level access, rebuilding permissions from scratch is often faster and cleaner.

Step-by-Step: Migrate a File Share to SharePoint Online Using SPMT

Step 1: Install the SharePoint Migration Tool

Install SPMT on a dedicated workstation, migration server, or jump box.

The migration machine should ideally have:

• Windows 10 or Windows 11
• Windows Server 2019 or later
• At least 16 GB of RAM
• Solid-state storage
• Reliable network connectivity
• Direct access to the source file server

Avoid using a heavily utilized end-user workstation. The migration machine should remain powered on and connected throughout each migration run.

Step 2: Sign In with the Appropriate Microsoft 365 Account

Sign in to SPMT using a Microsoft 365 administrative account.

The account should have the required permissions to access each destination SharePoint site. In most cases, it should be configured as a Site Collection Administrator for every target site involved in the migration.

Confirm access before beginning the migration rather than discovering permission issues during the final cutover.

Step 3: Provision the SharePoint Destination

Create the destination environment before copying any content.

This may include:

• SharePoint sites
• Microsoft 365 groups
• Teams-connected sites
• Document libraries
• Security groups
• Metadata columns
• Content types
• Retention or sensitivity settings

This is also the right time to determine whether the existing folder structure should be retained or simplified.

When metadata will be used, create the required columns before the migration. SPMT can populate supported existing columns during the migration process.

Step 4: Add the File-Share Source

In SPMT, select File Share as the source type.

Enter the UNC path for the source file share, such as:

\\fileserver01\finance

Next, enter the destination SharePoint site URL and select the appropriate document library.

For large environments, avoid placing every department into one massive document library. Separate sites or libraries may be more manageable for permissions, navigation, search, ownership, and governance.

Step 5: Run a Scan-Only Assessment

Always run a scan before migrating files.

The scan-only process identifies issues such as:

• Excessively long file paths
• Unsupported file types
• Invalid or reserved characters
• Unresolvable user identities
• Empty folders
• Permission problems
• Files that are locked or inaccessible
• Files that exceed SharePoint limits

This step should not be skipped. A scan provides time to correct problems before they affect the migration schedule.

Step 6: Resolve the Issues Identified in the Scan

Review the scan report and correct the issues it identifies.

Common remediation tasks include:

• Shortening deeply nested folder structures
• Renaming files or folders
• Removing unsupported characters
• Deleting obsolete or temporary files
• Resolving duplicate content
• Synchronizing missing users and groups with Microsoft Entra ID
• Removing references to disabled accounts or old-domain security identifiers
• Confirming that the migration account can read every required folder

Correcting these issues before the migration can prevent failed files and delays during the cutover.

Step 7: Run the Initial Bulk Migration

Run the initial bulk copy approximately two to four weeks before the planned cutover.

During this stage, users can normally continue working from the existing file share.

The purpose of the bulk migration is to move most of the data in advance. Later migration runs will copy only new or modified files, significantly reducing the amount of work required during the final cutover window.

Depending on the size and complexity of the environment, you may run several incremental migration passes before the final transition.

Step 8: Perform the Final Cutover

At the beginning of the cutover window, place the original file share into read-only mode.

This prevents users from creating or modifying files while the final migration pass is running.

Next:

1. Run the existing SPMT task again.
2. Migrate all remaining new and changed files.
3. Review the migration report.
4. Confirm that critical folders and documents are available in SharePoint.
5. Update mapped drives, shortcuts, intranet links, and documentation.
6. Direct users to the new SharePoint or Teams location.

Do not immediately delete or disconnect the original file share. It should remain available in read-only mode during the validation period.

Step 9: Validate the Migration

After the final migration pass, compare the source and destination results.

Review the SPMT migration reports, which are typically stored under:

%LOCALAPPDATA%\Microsoft\MigrationTool\

Validate:

• Total file counts
• Folder counts
• Failed items
• Skipped items
• File sizes
• Modified dates
• Permissions
• Metadata
• Access for key users
• Critical departmental folders

Any differences between the source and destination should be investigated before the migration is considered complete.

How NTFS Permissions Map to SharePoint Online

SPMT can attempt to translate NTFS permissions into SharePoint permissions.

Users and groups that can be resolved in Microsoft Entra ID may be assigned access in the destination. Identities that cannot be resolved may be skipped.

Common examples of identities that may cause problems include:

• Local Windows groups
• Disabled users
• Old-domain accounts
• Orphaned security identifiers
• Legacy service accounts
• The “Everyone” group
• Nested groups that do not exist in Microsoft Entra ID
• Folders with heavily broken permission inheritance

There are two primary approaches to handling permissions.

Option 1: Preserve Existing Permissions

This approach works best when the source environment is already well organized.

Before migration:

• Ensure every required user exists in Microsoft Entra ID.
• Synchronize the necessary security groups.
• Remove obsolete users and groups.
• Simplify broken inheritance.
• Confirm that folder owners approve the existing permissions.

Preserving permissions may reduce immediate change for users, but it can also reproduce unnecessary complexity in SharePoint.

Option 2: Start with a New Permissions Model

For older file shares, creating a new permissions structure is often the better choice.

Content can be migrated using the default SharePoint site permissions, and access can then be rebuilt using:

• Microsoft 365 groups
• SharePoint Owners, Members, and Visitors groups
• Microsoft Entra security groups
• Teams membership
• Department- or role-based access

This approach usually creates a more manageable and supportable environment.

Whichever option is selected, permission cleanup should be completed while business owners and department leaders are already involved in the migration.

Managing Path-Length Limitations

SharePoint Online supports a maximum path length of up to 400 characters.

The full path includes:

• The SharePoint domain
• The site URL
• The document library name
• Every folder name
• The filename

Deeply nested file-share structures can exceed this limit quickly.

For example, a structure containing several project folders, archive folders, working-document folders, and long filenames may migrate successfully at one level but fail after being placed under a longer SharePoint site URL.

To reduce path-length problems:

• Shorten the SharePoint site URL.
• Rename unnecessarily long folders.
• Remove redundant folder levels.
• Shorten document-library names.
• Simplify project folder structures.
• Divide very large libraries across multiple sites.
• Rename long filenames before migration.

A folder named:

01 - Working Documents - Previous Versions - Backup

could potentially be simplified to:

Working Files

Small changes across several folder levels can significantly reduce the total path length.

Reserved and Unsupported Characters

Legacy file shares may contain names that SharePoint does not handle in the same way.

Problematic characters may include:

~ " # % & * : < > ? / \ { | }

The exact behavior can depend on current Microsoft 365 settings and migration-tool configuration.

SPMT may be able to replace or encode certain characters automatically, but the organization should decide how naming issues will be handled before starting the migration.

Whenever possible, rename problematic files at the source so users understand the final naming convention.

Migration Performance and Throughput

Migration performance depends on several factors, including:

• Available bandwidth
• Network latency
• Average file size
• Number of files
• Source-server performance
• Migration-machine performance
• Microsoft 365 throttling
• Antivirus scanning
• Number of parallel migration tasks

A migration containing millions of small files may take much longer than a migration containing fewer large files, even when the total data size is the same.

Real-world SPMT throughput may fall within the range of approximately 50 to 100 GB per day for an individual task, but actual performance can vary significantly.

To improve throughput:

• Run migration tasks during off-hours.
• Use a dedicated migration machine.
• Avoid wireless connections.
• Use SSD storage.
• Exclude approved migration working directories from unnecessary antivirus scanning.
• Run parallel tasks against different destination sites.
• Avoid sending too many parallel tasks to the same library.
• Consider Migration Manager for multi-agent migrations.

Always test throughput using a representative sample of the organization’s data before committing to the final migration schedule.

What to Do After the Migration

The technical migration is only one part of the project. User adoption, governance, and ongoing monitoring are equally important.

Publish a User Guide

Create a simple “Your files now live here” guide showing users:

• How to open the new SharePoint site
• How to access files from Teams
• How to synchronize libraries
• How to share documents
• How to restore previous versions
• Who to contact for support

Pin the guide in Teams and distribute it by email.

Keep the Source File Share Read-Only

Keep the original file share in read-only mode for at least 30 days.

This provides a recovery and comparison window without allowing users to continue creating new content in the old environment.

Review Sharing Activity

Audit internal and external sharing links regularly during the first month.

Confirm that users are not creating anonymous links or sharing sensitive content with unintended recipients.

Confirm Microsoft 365 Backup Coverage

SharePoint Online provides platform resiliency and retention capabilities, but these should not automatically be treated as a complete backup strategy.

Confirm that the organization’s Microsoft 365 backup solution is protecting the newly created sites and document libraries.

Obtain Formal Sign-Off

Department owners should confirm that:

• Required files are present.
• Permissions are correct.
• Business-critical documents open successfully.
• Users can access the new location.
• No unresolved migration failures remain.

Only after formal approval should the original file server or file share be decommissioned.

Final Thoughts

A successful file-share migration is not simply a matter of copying folders into SharePoint Online.

The project should also address:

• Information architecture
• Permissions
• Ownership
• Naming conventions
• Data cleanup
• User training
• External sharing
• Backup
• Governance
• Long-term support

The best migrations improve the environment rather than reproducing the same file-server problems in the cloud.