Building a SharePoint migration plan: triage first, dates later

What hurts

Most migration plans are a date with a content list attached. They slip because nobody asked the only question that shrinks the work: what shouldn’t move at all?

There’s a second problem. The tool people reach for to inventory a farm, the SharePoint Migration Assessment Tool, reaches end of support on October 1, 2026. Its identity mapping has been broken far longer, since June 30, 2023, when Azure AD Graph was deprecated underneath it. If your plan starts with “run SMAT”, it starts with a dead tool.

Step 1: inventory, with the tool that still works

Point SPMT’s scan at the farm. It reads without changing anything and produces the content inventory plus a risk list.

Capture six things per site: total size, file count, average file size, last modified date, the owner’s name, and whether anything custom is attached. Average file size matters more than people expect, and I’ll come back to why.

The owner column does the most work. No owner anyone can name is an archive candidate, not a migration candidate. That single rule usually removes more from the project than any technical decision you’ll make.

Step 2: triage into four buckets

Every site lands in exactly one.

Click to zoom

The split between Retire and Archive is the one people collapse, and it costs them. Retire is content nobody needs and nobody will miss. Archive is content you are legally required to keep but nobody edits, which means it needs a retention answer, not a migration slot. Moving it just relocates the problem into a tenant you now pay for.

Rebuild is not a bucket you schedule alongside the others. It’s a parallel project with its own hours, covered in the InfoPath replacement post and the SharePoint 2013 workflow post.

Step 3: size the waves from real ceilings

Microsoft publishes throughput ceilings, and they are not close to each other.

Click to zoom

Read that as a planning constraint, not a promise. Two estates of 500 GB can differ by weeks: one is scanned PDFs and video, the other is 400,000 small Office documents with custom columns. The second is the one that surprises people.

Three rules that come with it:

• Keep the queue under 5,000 migration jobs. That’s jobs queued, not jobs processing. Over-queuing loads the database and slows everything down.
• Run parallel tasks against different site collections, which is where parallelism genuinely helps.
• Use app-based authentication. Migration is a background task, and running it in user mode triggers heavier throttling.

Step 4: know what will be rejected

Three service limits reject content outright, and the scan finds all of them before a cutover weekend does:

• 400 characters for the entire decoded file path, including the file name.
• 250 GB maximum file size.
• 100,000 items in a single list or library before performance degrades or migration fails.

Fix these at the source. Renaming a folder on a file share is cheap; discovering a 480-character path at hour four of a cutover is not.

How to fix it

The order matters more than the tooling.

1. Scan the farm with SPMT and get the inventory.
2. Triage every site into the four buckets, with an owner’s name against each.
3. Audit permissions on the source, before anything moves. That’s its own day of work.
4. Sequence the Move bucket into waves, sized from the ceilings above and the average file size in your scan.
5. Scope the Rebuild bucket separately, with its own hours and its own sign-off.
6. Run the cutover on the hour-by-hour runbook.
7. Validate on a schedule, not a checklist.

Steps 1 and 2 are most of the value. An estate that arrives at step 4 with half its sites already retired is a project with a real date on it.

Bottom line

The triage produces the schedule, and it’s the step where the project gets small enough to finish.

Do the inventory before anyone commits to a date. Built the other way round, the plan opens with a number nobody can defend, and the first wave is where that shows.