# Building a SharePoint migration plan: triage first, dates later > Migration plans slip because they are a date with a content list attached. The plan that holds is a triage, where two of the four buckets never move at all. Here is how to inventory it, size the waves from Microsoft's published ceilings, and sequence the work. [Home](https://tenantcraft.ca/) [Insights](https://tenantcraft.ca/insights) Migration Plan Aug 16, 2026 4 min read Geri Crroj Microsoft 365 consultant, Niagara, Ontario ## 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. The 5-minute version 1. **Inventory with SPMT’s scan**, not SMAT. SPMT 4.0 and later has assessment built in. 2. **Triage every site into four buckets.** Two of them never migrate. 3. **Size waves from Microsoft’s published ceilings.** Small files run 40 times slower than large ones. 4. **Migrate evenings and weekends.** Throttling is tighter on weekday daytime and cannot be lifted, by anyone, including support. 5. **Rebuilds are a separate project.** Forms and workflows do not belong in a wave plan. ## 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. ![Four triage buckets. Retire: no activity in 12 months and no owner anyone can name, delete after a notice period, do not migrate. Archive: kept for retention but never edited, export or keep read-only, do not migrate. Move: live libraries and lists people used this month, straight SPMT move, this is your wave plan. Rebuild: InfoPath forms, 2013 workflows and custom solutions, scoped separately, this is where the hours go.](https://tenantcraft.ca/images/migration-triage-buckets.png) Every site lands in exactly one Only the Move bucket becomes a wave plan. Retire and Archive are decisions, not migrations. 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](https://tenantcraft.ca/insights/infopath-alternatives-sharepoint-forms) and the [SharePoint 2013 workflow post](https://tenantcraft.ca/insights/sharepoint-2013-workflow-replacement-spmt). ## Step 3: size the waves from real ceilings Microsoft publishes throughput ceilings, and they are not close to each other. ![Microsoft's published migration throughput ceilings. Light content such as ISO files and video, 10 TB per day, big files move fastest. Medium content such as Office files around 1.5 MB and list items, 1 TB per day, the realistic case for most SMB estates. Heavy content such as small files around 50 KB and list items with custom columns, 250 GB per day, a 40 times drop where small files are the trap.](https://tenantcraft.ca/images/migration-throughput-ceilings.png) Microsoft's published ceilings Average file size, not total volume, is what decides your calendar. 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](https://tenantcraft.ca/insights/permissions-cleanup-before-migration). 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](https://tenantcraft.ca/insights/migration-day-runbook). 7. **Validate** on a [schedule, not a checklist](https://tenantcraft.ca/insights/post-migration-validation-pass). 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. Running the inventory? The discovery worksheet covers what to capture per site. SharePoint Discovery & Inventory Worksheet PDF · 7 pages [Email me the PDF](https://tenantcraft.ca/resources/guides/sharepoint-discovery-inventory) TWENTY MINUTES, NO PITCH ## Tell me what is stuck. I will tell you what it takes. Same consultant from the first email to the last cutover. If I am not the right fit, I will refer you to someone who is. [Book a 20-min call](https://tenantcraft.ca/contact) [See published rates](https://tenantcraft.ca/pricing) --- _Canonical HTML: https://tenantcraft.ca/insights/sharepoint-migration-plan · Agent guide: https://tenantcraft.ca/llms.txt · Site map: https://tenantcraft.ca/sitemap-index.xml_