How to Migrate Off SharePoint

SharePoint migrations fail for reasons that have almost nothing to do with moving bytes. Copying files is the easy part, and every tool does it. What breaks is everything around the files.

This guide covers the four things that break and the sequence that avoids them.

Start with a measured inventory#

Not an estimate. Site collections, document libraries, item counts, total size, the largest individual files, the longest paths, and the dates of oldest and most recent activity per library.

Two figures decide the shape of the project. Item count, because migration throughput is measured in items rather than gigabytes and a million small files is slower than a hundred large ones. And last-activity date, because it identifies the libraries nobody has opened in years.

Almost every migration that overruns did so because the inventory was assumed.

Decide what does not move#

The default assumption is that everything comes. It is the most expensive option available, and it imports the problems that motivated the migration.

Three categories usually stay behind. Abandoned sites — team sites created for a project that ended, with no activity for years. Duplicated content, where the same document exists in several libraries because sharing was hard. And content past its retention period, which should be disposed of under the schedule rather than migrated and then disposed of later.

Every item excluded here is an item you do not extract, validate, permission, index or pay to store.

Permissions are the hard problem#

SharePoint permissions accumulate. Inheritance is broken at a library, then a folder, then an item; groups are created for one-off sharing; external sharing links persist. After several years the effective permission set is not documented anywhere and is not reconstructable by inspection.

Reproducing that graph in the destination is the mistake most migrations make, because it transfers the problem rather than solving it.

The workable approach is to map to roles instead. Establish the small set of roles that actually exist — owner, contributor, reviewer, reader, plus any genuine confidentiality boundaries — assign libraries to them, and treat every per-item exception as something requiring justification. The output is a permission model somebody can explain, which is what an access review needs.

Version history: decide per library#

Full history multiplies both volume and elapsed time, sometimes by a large factor. Discarding it loses evidence.

The answer is not uniform. Keep full history where versions are evidence: controlled procedures where an auditor will ask which revision was in force, contracts where the negotiation trail matters, and any regulated record class. Keep the current version only where history is convenience — working documents, drafts, presentations, internal reference material.

Making this decision library by library typically removes most of the history volume while keeping the versions anyone will ever ask about.

Dates and authors must survive#

Created date, modified date and the original author have to arrive intact. If created dates reset to the migration date, every retention calculation in the destination is wrong by the age of the document, and the error is not recoverable once the source is gone.

This is worth testing explicitly in a pilot rather than assuming, because several extraction paths quietly substitute the migration timestamp.

Retention labels do not transfer as labels#

Microsoft 365 retention labels are a platform construct. Extract the label applied to each item as metadata, map each label to a retention class in the destination, and reconcile the counts per class.

Items whose label has no clean mapping need a decision from the records owner. Defaulting them to the longest period is a common shortcut and it quietly creates a permanent archive.

Reconcile before cutover, not after#

For each library: item count in the source, item count in the destination, checksum comparison where the tooling supports it, and a sampled manual comparison of content and metadata. Signed off by the library owner before the source goes read-only.

Reconciliation performed after cutover is auditing. Performed before, it is control — and it is the difference between finding a systematic extraction fault while the source is still writable and finding it afterwards.

Links, then freeze#

Links to SharePoint documents live in emails, tickets, wikis, contracts and other systems, and no inventory finds all of them. So the source should not be switched off on cutover day.

Set it read-only, publish either a redirect or a searchable index mapping old paths to new locations, and keep it reachable for a defined period — commonly six to twelve months — before decommissioning. That period is also the window in which anything the migration missed surfaces while it can still be retrieved.

Where the schedule actually goes#

Not in copying. In the decisions: what stays behind, how permissions map, which libraries keep history, how labels translate, and what to do with the exceptions.

A migration plan that allocates time to those decisions finishes roughly when it said it would. One that allocates time only to throughput does not.