Lift-and-shift never works for shared drives. A pragmatic, permission-preserving migration sequence we use with mid-market clients.
Why Lift-and-Shift Fails Every Time
On-premises file servers accumulate 10-20 years of folder structures that were never designed for SharePoint's architecture. Deeply nested folders, path lengths that exceed SharePoint's 400-character limit, files with unsupported characters in the name, and permission inheritance chains that nobody fully understands — these are standard. Migrating the folder structure as-is produces a SharePoint site nobody wants to use, with permissions that break on day one. The migration must begin with a content audit, not a file copy.
The Content Audit Phase
Use ShareGate or Microsoft's own Migration Assessment Tool to scan the source file server and produce a report showing: total data volume, file path lengths, unsupported characters, files not accessed in the past 3 years, and unique permission groups. This typically takes 2-3 days for a 5TB server. The output usually surprises clients — 30-40% of files on a typical corporate file server have not been accessed in over two years and can be archived before migration, cutting the migration scope in half.
The Permission Challenge
SharePoint's permission model is fundamentally different from NTFS. On-prem file servers often have hundreds of unique permission entries per folder with no clear ownership. Before migrating, you need to map NTFS groups to Microsoft 365 security groups or SharePoint groups. Where NTFS has a custom permission for a single user, determine whether that should become a site member permission or a unique permission — unique permissions in SharePoint are technically supported but operationally difficult to manage at scale. The goal is to move toward a cleaner, flatter permission model, not replicate the old one.
Migration Sequence That Works
Run the migration in four waves: Wave 1 — non-critical department folders to validate tooling and permissions. Wave 2 — mid-tier departments with a user champion in each. Wave 3 — sensitive data with strict permission validation before cutover. Wave 4 — executive and legal content with the most scrutiny. Use a 2-week parallel-run period where both the old server and SharePoint are live, then cut over with a read-only lock on the file server for 30 days before decommissioning. Do not decommission until users have genuinely stopped going to the old path.
- Lift-and-shift fails — begin with a content audit to identify stale data, path length violations, and permission complexity
- 30-40% of corporate file server data is typically unaccessed for 2+ years and can be archived before migration
- Map NTFS permissions to M365 groups before migrating — do not replicate complex NTFS structures in SharePoint
- A four-wave migration with a 30-day parallel-run period before decommissioning prevents data loss and user disruption