SharePoint Migration: Sites, Files & Permissions Done Right

SharePoint migration is where email-migration confidence goes to die. Mail is one data type with one permission model. SharePoint is sites, libraries, lists, item-level permissions, metadata columns, version history, and fifteen years of workflow debt — and half of it will not move with a copy job. We have migrated 1.4M+ users to Microsoft 365, including a 4.14 PB shared-drive project across 93 drives, and the pattern holds: the file copy is the easy part. The permission map and the things that don't migrate are the project.

What a SharePoint migration actually involves

When people say "sharepoint migration" they usually mean the documents. The documents are maybe 40% of the work. A real inventory covers:

• Sites and subsites. Classic subsite trees flatten badly in SharePoint Online, where the modern model is flat site collections joined by hub sites. Every subsite deeper than one level is a restructuring decision, not a copy.
• Document libraries and lists. Libraries move well. Lists with lookup columns, calculated columns, or 5,000+ items need attention — lookups break if the target list migrates after the list that references it.
• Permissions. SharePoint groups, AD groups, item-level unique permissions. Every library where someone clicked "stop inheriting permissions" in 2017 is a landmine you have to map. We map every permission before cutover — the alternative is a Monday of "I can't open my folder" tickets.
• Metadata. Created/Modified dates, authors, custom columns, managed metadata term sets. The good tools preserve these. A naive drag-and-drop into a browser sets every Modified date to migration day and every author to the admin account — and destroys any retention or search logic built on those fields.
• Workflows and forms. SharePoint 2010/2013 workflows and InfoPath forms do not migrate. Ever. More on that below, because it is the single most under-scoped item in every quote we review.

SharePoint Server 2013/2016/2019 to SharePoint Online

On-premises SharePoint Server to SharePoint Online is the classic sharepoint migration to office 365 path, and the version you start from decides the tooling:

Note the 2016 and 2019 dates: both leave extended support on the same day in 2026. If you are still on either, you no longer have a "later" — the only supported on-premises landing zone is SharePoint Server Subscription Edition, and if you are going to re-platform anyway, SharePoint Online is the cheaper move for most organizations.

Two structural realities of this path:

• Classic to modern is a redesign, not a setting. SPMT copies content into modern sites, but classic web parts, custom master pages, and farm solutions do not come along. Budget time to rebuild landing pages with modern web parts.
• Full-trust code dies at the boundary. Any farm solution (WSP) your 2013/2016 farm runs has no equivalent in SharePoint Online. The replacement is SPFx or Power Platform, and that is development work, not migration work.

File server to SharePoint: the permission problem

A file server to sharepoint migration looks simpler than server-to-online — it's just files, right — and is routinely harder, because NTFS and SharePoint disagree about what a permission is.

NTFS to SharePoint permission mapping is the hard part. NTFS supports deny ACEs, per-folder inheritance breaks at unlimited depth, and grants to machine-local groups. SharePoint has no deny, discourages deep unique permissions, and only understands Entra ID identities. In every file-server project we run, the first deliverable is an ACL export (icacls or a scanner) and a mapping decision for every distinct ACE pattern. Typical findings on a 15-year-old file server: hundreds of broken-inheritance points, dozens of dead SIDs from deleted users, and at least one business-critical share secured by a local server group that exists nowhere in Entra ID.

Flatten the inheritance. The wrong move is to faithfully recreate 400 unique-permission folders in SharePoint. Item-level permissions in SharePoint Online are a performance and governance liability — Microsoft's own guidance caps unique scopes per library, and past a few thousand they degrade sharing operations. The right move is to restructure: one site (or library) per real security boundary, permissions granted at the site level via groups, and the deep NTFS exceptions either promoted to their own library or deliberately retired. This is a conversation with the business, and it is why we schedule permission-mapping workshops before we copy a single byte.

The path length limit. The full decoded URL in SharePoint Online — site, library, folders, filename — is capped at 400 characters. File servers hit 260-character Windows paths for decades and users learned to nest anyway. Long paths must be shortened or restructured pre-migration; the tools report these as failures, not warnings.

Illegal characters and names. Files and folders containing " * : < > ? / \ |, names ending in a period, or reserved names like CON and PRN will not land. Leading/trailing spaces get silently trimmed. SPMT and Migration Manager can auto-rename some of these; we prefer a pre-migration scan-and-fix script so the file the user finds is the file they expect.

Tenant-to-tenant SharePoint moves

Mergers and divestitures add a layer: SharePoint Online to SharePoint Online across tenants. Microsoft's Cross-Tenant SharePoint/OneDrive migration feature handles OneDrive well and SharePoint sites with real limitations — it moves the site but not everything in it (flows, some list types, and site customizations stay behind), it requires per-user licensing, and it is one-directional. For anything beyond straightforward site content, this is where third-party tools earn their keep, because they migrate sharing links, preserve granular permissions across the tenant boundary, and let you re-map identities between two different Entra directories. The identity mapping file — old UPN to new UPN — is the artifact that makes or breaks these projects. The mail side of the same merger has its own sequence; we covered it in our tenant-to-tenant migration walkthrough.

Tools: SPMT vs Migration Manager vs ShareGate/Quest/AvePoint

Our rule across all Microsoft 365 migration services engagements: native Microsoft tools first, paid tools only when the scenario requires them — and when it does, the client buys the license directly, so there is no markup and no lock-in.

Honest guidance: for a file server to SharePoint Online with a sane structure, SPMT or Migration Manager does the whole job for free. We reach for ShareGate when the project is really a restructure wearing a migration costume — heavy subsite flattening, cross-tenant with identity mapping, or hundreds of permission exceptions that need bulk re-mapping. The broader tooling landscape, including the mail-side tools, is in our migration tools comparison.

What breaks and why

This is the section to forward to whoever signed off on "it's just a file copy."

• Workflows do not migrate. SharePoint 2010 and 2013 workflow engines are retired in SharePoint Online — 2010 workflows stopped in 2020, 2013 workflows are shut off for existing tenants as of April 2026. Nothing converts them automatically. Every workflow must be inventoried, triaged (a surprising number are dead), and the survivors rebuilt in Power Automate. Budget it as development.
• InfoPath is dead. Forms open in SharePoint Online today only via a compatibility layer that Microsoft has scheduled for removal (InfoPath Forms Services in Microsoft 365 retires July 2026). Rebuild in Power Apps or plain lists. There is no converter worth trusting.
• Customizations stay behind. Farm solutions, custom master pages, JSLink customizations, classic web parts — none of it crosses. Modern equivalents exist (SPFx, list formatting) but they are rewrites.
• Checked-out files migrate empty-handed. A file checked out with no checked-in version has no published content for the tool to copy. Run a check-in sweep on every library first; we script it.
• Version history has practical limits. SPMT migrates versions, but "all 400 versions of every file" multiplies migration time and storage. We usually agree a cap — the last 10 or 25 versions — with the records owner, in writing.
• Sharing links and shortcuts break. Old URLs, "Add shortcut to OneDrive" links, and mapped drives all point at the old location. Plan redirects where possible and a communications cutover where not.

None of this is a reason to stay put. It is a reason to inventory before you quote. The failure modes overlap heavily with mailbox projects — our Office 365 migration issues rundown covers the shared ones.

A realistic timeline

For a mid-size sharepoint online migration — say 2–5 TB, 200 users, one farm or file server:

• Week 1–2: Assessment. SPMT/Migration Manager scans, ACL export, workflow and InfoPath inventory, path-length and illegal-character report. Output: a migration map the business signs.
• Week 2–3: Remediation. Check-in sweep, path shortening, dead-SID cleanup, target architecture built (sites, hubs, groups).
• Week 3–4: Pilot. One or two real departments — 10–20 real users, real permissions, real daily work in the new sites. Pilots with test accounts find nothing; pilots with real users find everything.
• Week 4–6: Staged waves plus incremental passes. Bulk copy runs first; incremental passes pick up changes; source goes read-only only for the final delta. Cutover itself lands in a weekend window.
• Week 6–10: Hypercare. 30 days of fast-lane support, permission corrections, and link fixes while usage patterns settle.

Throughput planning: SharePoint Online migration API ingestion is measured in hundreds of GB per day per migration stream in practice, and it varies with file count more than file size. A million 50 KB files moves slower than a thousand 50 MB files. Size the calendar by item count, not just terabytes.

How we run it

The process behind our zero-data-loss record across 1.4M+ migrated users:

1. Inventory everything, quote nothing before the scan. Assessment reports plus ACL exports before a fixed price.
2. Map every permission before cutover. Every NTFS ACE pattern gets an explicit SharePoint decision — site permission, library permission, or retired. The business owner signs the map.
3. Native tools first. SPMT and Migration Manager unless the scenario genuinely needs ShareGate/Quest/AvePoint — and then you buy the license directly.
4. Verify with checksums. We verify migrated content against source with SHA-256 hashes on sampled and high-value libraries. "The tool said complete" is not verification.
5. Pilot with 10–20 real users, staged waves after, source read-only for the final delta, and any DNS or access cutover in a 2–4 hour weekend window.
6. 30-day hypercare, because the second week is when someone opens the quarterly-close folder for the first time.

FAQ

How long does a SharePoint migration take?

A single small site: days. A 2–5 TB file server or farm with 200 users: 6–10 weeks end to end, of which the actual copying is the smallest part. The 4.14 PB project ran as a months-long program of parallel streams. Item count and permission complexity drive the schedule more than raw size.

Does SharePoint migration move permissions?

SPMT and the paid tools can carry SharePoint-to-SharePoint permissions and map NTFS ACLs to SharePoint roles, within limits — no deny rules, no local groups, and identities must resolve in Entra ID. The honest answer is that permissions are re-engineered, not copied, on every file-server project we have run.

Is the SharePoint Migration Tool really free?

Yes. SPMT and Migration Manager are free with your Microsoft 365 subscription and handle the majority of straightforward migrations. Paid tools are justified by restructuring and tenant-to-tenant complexity, not by copy speed.

What happens to our SharePoint workflows?

They do not migrate. Inventory them, kill the dead ones, rebuild the live ones in Power Automate. Treat it as a separate development workstream with its own budget.