Migrating to SharePoint Online

The tooling

• Migration Manager — the SharePoint admin center surface for at-scale migrations, built on the SharePoint Migration Tool (SPMT) engine. It orchestrates agents, tasks and reporting for large moves.
• SPMT — the standalone/scriptable engine for file shares and on-prem SharePoint.
• Connectors for cloud sources (file shares, on-prem SharePoint, and other cloud providers) let you migrate without manual export/import.

Common sources: file shares (SMB), on-prem SharePoint Server, and other cloud storage. The engine supports incremental passes — run a bulk copy, then delta passes to catch changes, then a final cut-over — so you don't freeze the source for the whole project.

Permission-mapping fidelity (the hard part)

Moving files is easy; moving who can see them is where fidelity is lost:

• On-prem/AD identities must map to Entra identities; unmapped principals drop or land as broken permissions.
• File-share NTFS ACLs translate imperfectly to SharePoint's group/level model — granular per-file ACLs can explode into unique permissions (the broken-inheritance sprawl the whole governance module warns about). A migration is a chance to re-architect permissions, not faithfully reproduce a mess.
• Sharing links and external access don't carry from a file share — they're re-created in SharePoint's model.

The other fidelity traps

• Path length — deep source folder trees can exceed SharePoint's ~400-character path limit and fail to migrate (sync-client concept); flatten or restructure.
• Version history — SPMT can bring versions, but this multiplies migrated volume and storage; decide how many versions are worth moving.
• Checked-out / locked files and open files may be skipped.
• Unsupported characters / file types / oversized files are excluded and must be remediated at source.
• Metadata and timestamps — created/modified/author can be preserved by the tools, but custom metadata needs column mapping or it's lost.

The failure modes

• Migrating the permission mess. Faithfully reproducing file-share ACLs imports years of oversharing into a Copilot-readable estate — remediate during migration, not "later".
• No incremental cut-over plan — a single big-bang copy means a long source freeze and stale data; use incremental + final delta.
• Ignoring the failure report — SPMT produces per-item success/failure logs; skipped items (path, type, size, checkout) are silent data loss if not reviewed.
• Underestimating version bloat — bringing full history can multiply the target footprint and cost (storage-model concept).

What to watch (proofs)

• Migration reports: Migration Manager / SPMT per-task summary — items migrated vs skipped/failed, with reasons (the fidelity truth).
• Permission spot-checks: post-migration Get-SPOSiteGroup and item-level Check Permissions on sampled content — do the right people (and only them) have access?
• Path/name exceptions: the failure log's path-length and invalid-character entries — the remediation backlog.
• Storage delta: target Get-SPOSite <url> | fl StorageUsageCurrent vs source size — versions and duplication made visible before they surprise the bill.