Migrating from On-Prem File Server to OneDrive/SharePoint: Permission Model Overhaul, SPMT Config, Sync Conflicts, and Backup Compliance — A Field Guide

Key Takeaways

• Permission models don’t map 1:1. NTFS ACLs and SharePoint permission groups are fundamentally different. Attempting to migrate ACLs directly creates a maintenance nightmare of broken inheritance that will haunt you for years.
• Run SPMT in Scan Only mode first. On a 400GB migration, we found 3,000+ files that would fail due to path length limits. The scan report saved us from a migration that would have silently dropped files.
• OneDrive vs SharePoint is a governance decision, not a storage decision. Define the boundary before you migrate, or you’ll end up with a “cloud file server” that’s worse than the on-prem one you replaced.
• Microsoft 365 is not your backup. Version history won’t save you from ransomware or accidental site deletion. You need immutable, off-tenant backups — S3 Object Lock or equivalent.
• Lifecycle management starts on day one. If you don’t define site creation approval workflows and retention policies at migration time, you’ll be doing a second “cleanup migration” in three years.

1. The Core Problem: That Nine-Year-Old File Server

Let me set the scene. There’s a recurring post on Reddit — someone’s customer is running a Windows Server 2008 file server that’s nine years old, and they need to move 400GB to OneDrive. The comments are a mix of sympathy and horror, not because the task is technically hard, but because they’re asking the wrong questions at the wrong time.

I hit the same wall last year with a manufacturing client. Their file server held 1.2TB of data — CAD drawings from 2008, HR records, finance exports, and a bunch of folders nobody could attribute to any living employee. The first thing we did wasn’t planning the migration. It was two weeks of data triage. We ended up migrating only 600GB — the rest went to cold storage or got deleted outright.

Migration is never a technology problem. It’s a governance problem.

Microsoft’s official line is that you can use Migration Manager or the SharePoint Migration Tool to move content for free. Sounds straightforward. Then you hit the permission model mismatch, the path length limits, the backup gap, and the “who owns this folder” question — and you realize the documentation glosses over all the painful parts.

2. Architectural Deep Dive: Why You Can’t Just Drag and Drop

2.1 The Fundamental Difference Between a File Share and SharePoint

An on-prem file server is a shared hard drive. SharePoint is a collaboration platform. That sounds like philosophy, but it determines your entire technical approach.

The 260-character path limit is the silent killer. On-prem you might have D:\Projects\2024\Q3\ClientName\Deliverables\Final\Approved\... — already pushing 200 characters. Move that to SharePoint and sync it via the OneDrive client, and the local path gets prefixed with C:\Users\username\OneDrive - CompanyName\..., blowing straight past the limit. Files sync fine server-side but the client throws errors — or worse, silently skips them.

2.2 The Permission Model Redesign

Here’s what I consider the single most underestimated part of the entire process.

On-prem NTFS permissions are usually a mess — security groups nested inside other security groups, an explicit deny rule on one file for one user, and nobody remembers why. None of that maps cleanly to SharePoint.

SharePoint’s permission model is built on permission groups: Site Owners, Site Members, Site Visitors. You can create custom permission levels, but the granularity is nowhere near NTFS. You can’t say “in this folder, Zhang San can read file A but not file B” — not without breaking inheritance on every single file, which is the one thing every SharePoint admin will tell you to avoid at all costs. It tanks performance and makes management exponentially harder.

So before you migrate, you must do permission triage:

1. Export your current NTFS ACLs — PowerShell or icacls, doesn’t matter.
2. Redefine access by business role — not by file, by folder/site.
3. Identify personal folders — D:\Users\zhangsan\ style structures map directly to that user’s OneDrive. Microsoft’s Migration Manager can auto-detect home directories and map them to OneDrive.
4. For team-shared directories, decide: SharePoint team site or communication site?

A mapping rule that’s served me well:

2.3 OneDrive or SharePoint? Answer This Before You Migrate

There’s a People Also Ask question that keeps coming up: “Is it better to use OneDrive or SharePoint?”

The answer: they’re not alternatives. They’re complementary.

I’ve seen companies shove everything into OneDrive and try to do team collaboration via personal share links. That breaks the moment someone leaves — their files vanish with their account, there’s no site-level permission management, and search becomes useless.

I’ve also seen the opposite: personal files crammed into SharePoint team sites, blowing up site quotas and making it impossible for users to find anything.

My rule of thumb:

• If only you edit it, but others need to view it — OneDrive, share link.
• If multiple people edit it or it needs version history — SharePoint document library.
• If it belongs to a project with a defined lifecycle (engineering deliverables, bid documents) — SharePoint, with metadata and approval flows.
• If it’s not active data anymore, just “might need it someday” — don’t put it in the cloud at all. Cold storage.

3. Real-World Implementation: Migrating a 400GB File Server

3.1 Pre-Flight Checklist

Before you touch a single file:

1. Harden your Microsoft 365 tenant first. That Reddit question about “first determine if there are valid requirements” is spot-on. If you haven’t enforced MFA, configured conditional access, and set up information protection — stop. Fix security before you move data. Otherwise you’re moving your unsecured front door to a bigger house.
2. Update OneDrive sync client on every machine.
3. Assess bandwidth. 400GB over a 100Mbps uplink is 9 hours of pure transfer — before SPMT scanning overhead and API throttling. Plan for 2-3x that in real time.
4. Check for problem file types. 10GB database backups and massive AutoCAD assemblies technically work (SharePoint’s single-file limit is 250GB), but anything over 15GB is a terrible experience. Those belong in Azure Blob or stay on-prem.

3.2 SPMT: Scan First, Migrate Second

SPMT is genuinely the best free option for small-to-medium migrations. But I cannot stress this enough: run it in Scan Only mode first. It produces a JSON report listing every file that will fail.

The scan report catches the usual suspects:

• Illegal characters in filenames (" : < > | ? * plus # % in certain contexts)
• Paths exceeding 400 characters
• Zero-byte files
• Files locked by another process
• Duplicate folder structures

Our 400GB scan surfaced 3,000+ files that would fail on path length alone. Fixing that meant either shortening paths with a script or flattening the folder structure — a decision that required business buy-in, because folder structure often encodes organizational logic.

A working SPMT task configuration looks like this:

{
  "Tasks": [
    {
      "SourcePath": "\\\\fileserver\\Projects\\Alpha",
      "TargetSiteUrl": "https://yourtenant.sharepoint.com/sites/AlphaProject",
      "TargetList": "Shared Documents",
      "MigrationType": "Structure",
      "MigrateFiles": true,
      "MigrateFolders": true,
      "MigrateFileSecurity": false,
      "MigrateListSecurity": false,
      "MigrateNavigation": false,
      "MigrateAudit": false,
      "UserMappingFile": "C:\\Migration\\userMap.csv",
      "Premodded": false,
      "SkipFilesWithExt": [".tmp", ".bak", ".lnk"],
      "SkipHiddenFolders": true
    }
  ]
}

Pay attention to MigrateFileSecurity and MigrateListSecurity. Default is false, meaning SPMT won’t carry over your NTFS ACLs. Flip them to true and SPMT will attempt the conversion — but I’ll warn you now: that conversion is imperfect and produces a proliferation of broken inheritance that makes day-to-day management miserable. My strong recommendation: migrate without permissions, then rebuild permission groups natively in SharePoint. More upfront work, but the only path to something maintainable.

3.3 Bulk Home Drive Migration with PowerShell

If your file server has user home directories (D:\Home\zhangsan style), you can batch-generate SPMT tasks from Active Directory.

The community post on migrating home drives to OneDrive lays out the core flow:

1. Export users and their home directory paths from local AD.
2. Generate SPMT batch task JSON — one task per user.
3. Run SPMT from the command line against the batch file.

This PowerShell generates the batch tasks:

# Export users and home directory mappings from AD
$users = Get-ADUser -Filter {HomeDirectory -like "\\fileserver\Users\*"} -Properties HomeDirectory | 
    Select-Object SamAccountName, HomeDirectory

$tasks = @()
foreach ($user in $users) {
    $splat = @{
        SourcePath = $user.HomeDirectory
        TargetSiteUrl = "https://yourtenant-my.sharepoint.com/personal/$($user.SamAccountName)_yourtenant_com"
        TargetList = "Documents"
        MigrationType = "Structure"
        MigrateFiles = $true
        MigrateFolders = $true
        MigrateFileSecurity = $false
    }
    $tasks += $splat
}

$tasks | ConvertTo-Json -Depth 3 | Out-File "C:\Migration\HomeDrivesTasks.json"

Here’s the trap: the OneDrive URL format. The /personal/ segment must be the user’s UPN, URL-encoded — zhangsan@yourtenant.com becomes zhangsan_yourtenant_com. If you’re not sure, hit the user’s OneDrive as an admin and copy the exact URL. Guessing wrong means SPMT fails silently on every task.

3.4 Sync Conflicts and Client Deployment

This is the step you do after data migration completes but before users start hammering the system.

OneDrive sync client has a setting called Files On-Demand. Without it, users’ local disks fill up with cloud content — brutal when you have large CAD files or design assets. With it, files exist only in the cloud until a user double-clicks them.

But Files On-Demand creates its own problem: users who select everything and choose “Always keep on this device” have effectively disabled the feature.

Then there’s the co-authoring issue. There’s a thread on r/excel about a SharePoint-hosted Excel file being edited simultaneously by 5-8 people through the web version, with Power Query refreshes triggering Power BI report updates throughout the day. Migrating to SharePoint makes this kind of concurrent editing the norm — and Excel’s calculation engine in the browser behaves differently than the desktop version. Complex workbooks frequently fail with “refresh failed” or “engine timeout.”

My advice: identify all macro-enabled files (.xlsm) and complex Power Query workbooks before migration. These are not suitable for concurrent online editing. Either split them into smaller data modules or — for critical financial files — enable “Require Check Out” on the document library. Yes, it’s an old-school experience. It’s also the difference between a clean close and a corrupted workbook on month-end.

3.5 Backup: The Question Everyone Avoids

There’s a painfully honest post on r/microsoft365: “If Microsoft 365 goes down, so does our backup plan.” That’s the reality for 90% of organizations that migrate to M365.

Microsoft’s terms of service are explicit: M365 is not a backup solution. SharePoint Online has built-in version history (500 versions), but if someone deletes a document library — or ransomware encrypts the whole site — version history won’t save you. You need site-collection-level restore, and Microsoft’s retention policies and Litigation Hold are fiddly to configure and poorly understood by most admins.

Our team’s approach: configure SharePoint Online backup to Amazon S3 with S3 Object Lock in compliance mode. That means even the tenant admin can’t delete backup files — ransomware-proof.

Third-party options: AvePoint, Veeam, CommVault all have mature M365 backup products. Azure Backup has limited M365 support, which surprises people. The bottom line: moving to the cloud doesn’t outsource backup responsibility. Regulatory retention requirements (SEC 17a-4 for financial firms, for instance) demand immutable, WORM storage — S3 Object Lock is currently the most cost-effective route.

3.6 Incremental Migration with Migration Manager

If your migration window spans weeks — or the source file server is still being actively written to by business units — you need incremental migration: one full pass, several delta passes, then a final delta on cutover day before you flip DNS.

Migration Manager (found in the M365 admin center under “Migration”) supports this flow. Architecturally, it’s an Azure-hosted agent service (connector) that pulls data from your file server into SharePoint Online. Compared to SPMT’s push model, Migration Manager pulls — which makes better use of Azure bandwidth and is more resilient to local network interruptions.

Real-world experience: Migration Manager’s advantages are automatic retry of failed items, scheduled execution, and no data loss from local network hiccups. The downside: you need to configure an Azure connector, which is an extra layer of complexity for SMBs without an Azure subscription.

4. The On-Prem SharePoint Endgame

There’s a People Also Ask question: “Is SharePoint on premise going away?”

Straight talk — SharePoint Server 2019 mainstream support has ended. 2016 is out of support. 2013 was buried years ago. SharePoint Server Subscription Edition (SE) is the current on-prem version, supported via subscription licensing. But read Microsoft’s body language: every innovation — Copilot, Viva, advanced metadata management — is Online-only.

If you’re running SharePoint 2013/2016 on-prem and considering migration — you’re not alone. But your task isn’t “migrate to SharePoint Online.” It’s to inventory what you have first, because on-prem lists, workflows (especially 2013 workflows, which Microsoft has explicitly stopped maintaining), and InfoPath forms (dead) don’t migrate to Online. At all.

SPMT migrates list data and document libraries. Workflows and custom code need rewriting — in Power Automate. That’s a budget line nobody anticipates.

5. Best Practices Summary Table

6. Lifecycle Management: What Happens After Migration

There’s a thread on r/sharepoint asking how everyone handles SharePoint lifecycle management — a great question, because migration is the beginning of a chronic condition, not the cure.

Define a lifecycle policy for every SharePoint site:

1. Active sites (0-18 months): full functionality, regular backups, active owners.
2. Inactive sites (18-36 months): set to read-only, remove user permissions, keep search indexing.
3. Archived sites (>36 months): move to an archive site collection, disable collaboration features, admin-only access — but here’s the gotcha: Microsoft 365 Archive for SharePoint only reached GA in 2025, and it defaults to communication sites only. Team site archival support is still limited.

The reality: most organizations have no lifecycle policy at all. Sites multiply, content becomes redundant, and you end up with a “cloud file server” — just with quota limits instead of disk space.

The only way to avoid this: establish a site creation approval workflow from day one. Every new site requires IT approval, a stated business purpose, and an expected lifecycle. It feels bureaucratic. A year from now, you’ll be grateful.

7. FAQ

Q1: Which migration tool is best for SharePoint migration?

Microsoft’s SPMT is the most reliable free option for small-to-medium migrations (<1TB). For larger volumes or incremental sync needs, use Migration Manager. Enterprise requirements — complex permission mapping, cross-domain migration, massive concurrency — warrant commercial tools like Sharegate (now Simeon Cloud) or AvePoint, which offer finer-grained delta sync and permission reporting. On a budget, SPMT is free and supports PowerShell batch configuration.

Q2: Is it better to use OneDrive or SharePoint?

Depends on file type and collaboration needs. Personal files (only you edit, others view) go in OneDrive. Multi-editor documents, project files, anything needing metadata and approval flows go in SharePoint document libraries. Mixing them is the biggest mistake — you ruin OneDrive’s personal space and turn SharePoint sites into unsearchable dumps.

Q3: Is SharePoint on premise going away?

Mainstream support has ended or is ending. SharePoint 2013/2016 are out of support; 2019 mainstream support has expired. Microsoft maintains Subscription Edition (SE) as the on-prem option, but all new features are Online-only. If you’re running legacy on-prem, now is the migration window — but don’t attempt a direct lift-and-shift. Do data cleanup and process redesign first.

Q4: How to migrate OneDrive to SharePoint?

Single-user OneDrive to SharePoint team site: use SPMT — source is the OneDrive URL, target is the SharePoint library URL. For bulk scenarios (e.g., a departing employee’s OneDrive needs to move to a department site), use PowerShell to generate SPMT batch tasks. Note: OneDrive for Business migration has no “incremental” concept — it’s full migration then delete source, or have the user copy manually. No official tool supports OneDrive-to-OneDrive incremental sync; third-party tools like Sharegate do.

8. References & Community Insights

• Migrate content to OneDrive in Microsoft 365 - Microsoft Learn
• Migrate file shares to SharePoint and OneDrive - Microsoft Learn
• SharePoint Migration Tool (SPMT) overview
• r/microsoft365 discussion: M365 backup to Amazon S3
• r/sharepoint discussion: Lifecycle management practices
• r/excel discussion: Concurrent Excel editing and refresh issues

Closing Thoughts

There are a thousand technical approaches to this migration. What actually determines success is whether you’ve answered the question of why you’re migrating.

If the file server is just old — a new server might be cheaper and simpler. If you need employees to access files from anywhere, collaborate in real-time, and let Copilot search your corporate knowledge — then migrate. But don’t treat M365 as an “unlimited shared hard drive.” It’s an information architecture that requires governance.

It took us three months to migrate that Windows Server 2008 box’s 600GB. Looking back, the real time sink wasn’t transferring bytes — it was the business meetings about “which files are still needed, who gets access, how long do we keep them.” The technical execution was the easy part.

✅ All agents reported back! └─ 🟡 HN: 1 story │ 209 points │ 96 comments