Choose a route for each group of sites, and accept what it leaves behind

Chapter 1 put the tool last, and the chapters since have decided what a tool must carry or may drop: the structure (Chapter 12), access (Chapter 13), workflows (Chapter 19), each site's destination (Chapters 23 and 24) and what does not move at all (Chapter 26). Chapter 24 listed the routes Microsoft documents. This chapter turns the decisions into requirements and reads each route against them: what it carries and leaves, how it scans, reruns and reports, how fast it goes, and who answers when it fails.

Which route carries what each group of sites needs, and what does every candidate leave behind that a recorded decision must cover?

The decision this chapter leads to is a route for every group of sites, chosen against written requirements, with what it leaves behind listed and accepted before the first wave.

Which sites this chapter is for

Every site collection whose disposition is to migrate, and any file shares that move with them. Into Subscription Edition, Microsoft documents one route, the database attach of Chapter 23, so a group there is a set of content databases; Microsoft's migration tools and the Migration API write only into Microsoft 365 (Chapter 24), and a tool that copies into a farm is a claim to prove. Online, a group is the site collections that share a destination, a source version and requirements, so one route and one rehearsal serve them all.

Requirements first

A decision becomes a requirement when it says what must arrive and how anyone will know. "Keep the permissions" is not one. "Access granted through the site's own SharePoint groups arrives with their members, and named people keep the same effective access" is, because a route does it or does not, and a comparison on a copy (Chapter 8) says which. For each group, write one line per decision a route touches: structure and terms from Chapter 12, access from Chapter 13, identities from Chapter 21 and Chapter 24, workflows from Chapter 19, the reruns Chapter 9 plans. Content a disposition leaves inside a site, old versions or a retired library, is a requirement too: the route must leave it and say so.

Sources for the table: upgrade overview, upgrade content databases, SPMT overview, Migration API, SPMT permissions, user mapping file, manifest files, SPMT settings, release notes, content package, troubleshooting, SPMT FAQ, web parts through the API and incremental migration, all checked on 7 November 2026; workflows follow Chapter 19. "Not documented" means we found nothing on Microsoft's pages, not that no tool does it.

A feature list says what a route can carry. Your requirements say what it must, and only a copy shows what it did.

The attach: the database, without the farm

An attach carries what the content database holds and nothing the farm configured, so a Subscription Edition group leaves behind the right-hand column of Chapter 23's table. Its scan is Test-SPContentDatabase, its report the Upgrade Status page and the upgrade log, and it has no rerun. Microsoft's procedure gives no rate: parallel attaches start "several minutes" apart, a wait that "varies depending on the number of site collections, or the speed of the database server hardware" (upgrade content databases). Time the largest database on a copy.

What Microsoft's tool leaves

The scan in the SharePoint Migration Tool (SPMT) reports custom solutions and features, unknown content types, custom pages other than wiki and web part pages, and custom workflows as unsupported (scan codes, checked on 7 November 2026). SPMT does not migrate master pages, InfoPath forms or custom list forms (SPMT FAQ), a page customised away from its template, or navigation that matches no predefined template (troubleshooting). It takes terms from one default term store (managed metadata, checked on 7 November 2026) and says nothing about their IDs, which Chapter 12's single copy preserves: where a group uses both, test the pair on a copy.

SPMT's filters are how a site leaves content behind on purpose: a version limit, hidden files, files created or modified before a date, extensions, subsites, lists and content types (SPMT settings). Each filter is a Chapter 26 disposition with an owner, and SPMT's reports count what it left as filtered out (SPMT reports, checked on 7 November 2026), which Chapter 8's record lists as not compared, by decision.

SPMT signs in as a person unless it runs as a registered application with a certificate (certificate authentication, checked on 7 November 2026), the identity Microsoft asks migrations to use.

Tools built on the Migration API

Microsoft says SPMT "and other third party vendor tools use the SharePoint API for migration" (migration performance guidance, checked on 7 November 2026). The API processes the jobs a tool submits "on a best-effort basis, without Service Level Agreement (SLA) or guaranteed performance" (Migration API); what the tool reads, and from which versions, is its own claim. Where the API does not reach, Microsoft tells vendors to use Graph, and CSOM only as a fallback, which throttles more (vendor guidance, checked on 7 November 2026).

Ask any such tool, and keep the answers beside the requirements:

• which source versions it reads, Subscription Edition included if a group needs it;
• what it imports through the API and what through Graph or CSOM, and whether it runs as a registered application and waits as Retry-After says;
• its answer to each row of the table, including what a rerun does with edits on both sides, deletions, moves and permission-only changes;
• which reports it writes, item by item, and who supports it: for a tool's configuration, Microsoft sends you to its vendor (migration performance guidance).

Migration Manager, other tenants, and a Subscription Edition source

Migration Manager reads file shares and other cloud storage, not SharePoint Server (Migration Manager FAQ). For file shares, its rerun carries a permission change only with the file itself, unless you choose to overwrite everything (delta sync), and its file share reports "expire in 90 days" (reports), all checked on 7 November 2026. SPMT's FAQ suggests Migration Manager for orchestrated throughput, but for a farm the scale-out it documents is SPMT on several machines in parallel (SPMT FAQ).

Cross-tenant migration moves sites already online to another tenant, once and with no incremental passes, into sites that must not yet exist, with workflows, apps and flows rebuilt (cross-tenant migration). That page says sites "can now be moved"; Microsoft's landing page still calls it a private preview (migrate to Microsoft 365), both checked on 7 November 2026. It matters only when a group's content already lives in another tenant.

From Subscription Edition, we know of no documented route online. A farm attached now and copied online later has an open dependency, not a plan: record it with the date it falls due, and trust a tool only after it has read a copy of such a farm.

Throughput and throttling

Microsoft's estimates are maxima per day by weight of metadata: 10 TB for large files such as video, 1 TB for Office files of about 1.5 MB, 250 GB for list items with custom columns or files of about 50 KB. It asks for a support request for a migration over 100 TB due within 30 days (migration performance guidance). SPMT's performance scores "can't predict how fast the migration performs" (SPMT reports); its summary report gives GB per hour for each task on your own content, and that is the rate to plan with.

Microsoft applies "tighter throttling limits on background apps" during weekday daytime hours, allows more on evenings and weekends in the tenant's region, expects app-based authentication, and lifts no throttling on request (migration performance guidance). The applications in a tenant share one resource bucket, a sync client running beside a migration may trigger throttling, and a client that ignores Retry-After may be throttled further (throttling, checked on 7 November 2026). We would plan two routes in one tenant as one load.

Reports, and who answers

Every route's report is the producer's account (Chapter 8): keep it as context, never as proof, and export it before it expires. Name each route's support path before the first wave. The attach is the upgrade Microsoft supports. SPMT problems go to Microsoft through the admin centre, with the tool named (migration performance guidance); we found no lifecycle page for it, so we do not know what notice its end would carry. The Migration API has no SLA, and a vendor's tool is its vendor's to support.

One route per group, and the list it leaves

We would start each group from Microsoft's tool and move it to another route only for a named requirement SPMT cannot meet, proved on a copy. A requirement no route meets is not a tooling question. It returns to its chapter: rebuild or modernise first (Chapter 28), retire, accept the loss in writing, or choose another destination and record the blocker as Chapter 24 does.

Then write the decision per group: the route, its settings, and what it leaves, each line with the limit or decision behind it, the owner who accepted it and what replaces it. That list becomes the "not compared" half of Chapter 8's record: a limit of the route, declared before the wave, rather than a defect found after it.

Out of scope

Waves are Chapter 33, the pilot that proves a route Chapter 31, verification and cutover Chapters 8 and 9, classic pages Chapter 28 and archiving first Chapter 27. Third-party tools are not named or compared, and pricing and licensing, cross-tenant included, are not covered.

Before you continue

• Every decision from Chapters 12 to 28 that a route touches is a written requirement with its test
• Every site collection that migrates belongs to one group, with its destination, source version and requirements
• Each group has one route, and every requirement has that route's documented answer or a recorded gap
• Everything each route leaves, filters included, is listed with its reason, the owner who accepted it and what replaces it
• Every claim Microsoft does not document, and every Subscription Edition source, is proved on a copy before a group depends on it
• The plan uses rates measured on your own content, runs as an application off-peak, and treats routes in one tenant as one load
• Each route's reports are exported before they expire, and its support path is written down

Download chapter 29 (PDF)Same text, same tables, same sources as this page.