Choose a pilot that can fail, and let what it measures change the plan

Chapter 30 left lines in the readiness record that only a rehearsal can establish, and Chapter 33 sizes the waves from rates and hours nobody has measured yet. The attach is Chapter 23, verifying a copy Chapter 8 and the cutover Chapter 9: this chapter decides what they must show on a pilot, and what the result changes.

What does a pilot have to prove, and what does its result change before the first wave?

The decision this chapter leads to is whether the method holds for each destination and route, as written, with changes proved again, or not at all, taken on a written pilot record before the first wave.

Which projects this chapter is for

A move from SharePoint Server 2016 or 2019 to either destination. Two runs come before the first wave, and they prove different things. A rehearsal runs the procedure on copies nobody will use, as Chapter 30's record lists it: a trial attach of copies on Subscription Edition, a copy and a delta into sites nobody uses yet online. A pilot runs it for the people of a few real sites. Microsoft states a pilot's goals: "to validate the process, including performance and user communication, and to get a sample of user feedback" (team sites migration guide, checked on 7 November 2026). The pilot's own sites need Chapter 30's site lines before they move.

Choose the sites for what can go wrong

The simplest site moves cleanly and proves that the simplest site moves. With no unique permissions, no customisation, no large list and few users, its success says nothing about the sites that have them, and its rate nothing about theirs. Microsoft's guidance for upgrading to 2016 prefers all the data, and otherwise "a representative subset of the data" that finds issues with the kinds and sizes of sites, lists, libraries and customisations present (best practices for 2016), and its 2013 page warns that a subset "does not produce a valid benchmark" for how long the whole takes (trial upgrade to 2013). Online, "Files migrate faster than objects and list items" (migration performance guidance, all three checked on 7 November 2026), so each kind of content has its own rate.

We would draw the pilot from Chapter 29's groups so that, between them, its sites hold:

• every group and route the waves will use, including a file share where Migration Manager moves one, since it does not read SharePoint Server (Chapter 29);
• each kind of site Chapter 33 times: a library site, a site of lists and forms, an application with workflows;
• the largest list, library and database, and the deepest unique permissions;
• a kept customisation (Chapter 15) and a search dependency (Chapter 11);
• owners and validators with the hours, and users willing to say what fails.

Microsoft asks for "a small set of users", with no number. On copies, include what matters most: Microsoft's Subscription Edition page begins tests "by validating high-impact or high-profile sites" (upgrade a site collection, checked on 7 November 2026). Where people work in the pilot, we would not choose the most critical site: a pilot exists to find failures, and there each one stops a working team. A pilot that cannot fail has proved nothing.

A copy into SharePoint Online: rehearse, then cut over a few sites

We would rehearse in the tenant that will receive the waves, with the route's settings, machines and account: copy the pilot sites into sites nobody uses yet, then edit, delete and move test items created at the source and run a delta, to see what a rerun does with each (Chapter 29). A Migration API tool's answers to Chapter 29 become observations here. The rehearsal sites keep the access rules and end date Chapter 30 gave them.

Then pilot as Microsoft describes it: an incremental migration "in the background with no user impact", followed by "a cutover event" (team sites migration guide). That is Chapter 9's whole sequence for a few sites, its rollback boundary written before the cutover, because the cutover is real. Its risks:

• Hours. Microsoft applies "tighter throttling limits on background apps" during weekday daytime (migration performance guidance), so a pilot run at a weekend measures a weekend rate.
• Accounts that do not map. Without a mapping, files take "the default permission of the location" (SPMT permissions, checked on 7 November 2026), so the pilot includes accounts that no longer resolve.
• Two platforms. After the cutover, the pilot's users work online while colleagues follow links to the old addresses (Chapter 33), and a rollback would hide what they wrote (Chapter 9).
• Search. Content is "automatically crawled based on a defined crawl schedule", and people see only what they can open (make sure content can be found, checked on 7 November 2026). Microsoft does not publish that schedule, so we do not know how long migrated content takes to appear; we would record when known items from each library first return.

An attach to Subscription Edition: rehearse on copies, then let users work on them

The rehearsal is Chapter 23's sequence on copies of the real databases, on a farm built as production's will be. Microsoft's 2016 guidance asks for multiple tests on "copies of your actual databases", and to "Test the upgraded environment, not just the upgrade process" (best practices for 2016). The Subscription Edition verify page says a trial upgrade finds customisations "that have to be reworked before you attempt to upgrade your production environment", and asks for search queries checked, then: "Twenty-four hours later, view the query reports" (verify database upgrades, checked on 7 November 2026).

We found no Subscription Edition page on a pilot with users. We would put the pilot sites' users on the trial copies for an agreed period, told that nothing they write there survives. We would pilot in production only where the calendar already moves the farm in several windows: its first window then moves whole addresses, with every consequence Chapter 33 lists. Its risks:

• Copies with real links. Even on a copy, "the link to the data source is real" (trial upgrade to 2013): we would point external connections, outgoing email, workflows and integrations at test systems before anyone signs in.
• Copies taken from production. Restoring production's own backups, as Chapter 30 does, touches nothing there; a fresh one taken copy-only leaves its backup sequence as it was (copy-only backups). Microsoft's procedure copies the Search administration database with production's Search service application paused (upgrade service applications, both checked on 7 November 2026), and does not say whether a backup taken without the pause serves.
• A different farm. A farm simplified too far gives no "accurate estimate" of the time, and a virtual one may not perform like physical servers (trial upgrade to 2013).
• The same sites twice. A site collection's ID is registered in the farm: a second attach succeeds, but nobody can browse to it (upgrade content databases, checked on 7 November 2026). A rehearsal farm that becomes production loses its copies first.
• People the conversion skips. Permissions travel as stored (Chapter 23), but a conversion to claims updates only accounts "enabled and queryable by SharePoint" (Convert-SPWebApplication, checked on 7 November 2026), so the pilot includes a disabled one.
• The way back. "Test your fallback plan and make sure that it works before you begin your real upgrade" (trial upgrade to 2013).

What the pilot must prove, and when it is accepted

We would accept a pilot only when every line holds for its destination; a line that was not measured does not hold.

Sources for the table: the pages cited above, and SPMT reports, checked on 7 November 2026. Reports say where to look; only Chapter 8's comparison says what was lost.

Duration counts for Chapter 33 only if measured as the waves will run: the same machines, settings, accounts, hours and parallelism. SPMT's summary report gives each task's duration and GB per hour (SPMT reports); time each validator's acceptance per kind of site too, and keep every figure per kind, never one for the pilot.

Ask the users, task by task

Before the pilot, each owner lists the tasks people do on their site, with Chapter 14's evidence of use, and names who does each. During it, each person records per task: done as before, done differently, or not done, with the date. Their questions go to the helpdesk and into Chapter 30's messages; Microsoft's example is to update "your user communication template to address questions you received from pilot users" (team sites migration guide). We would not average the answers into a score: one person who cannot do their job outweighs ten who can.

Holds, holds with changes, or does not hold

Microsoft's guide uses the pilot "to determine the rest of your migration schedule, and make any needed changes" (team sites migration guide). The decider Chapter 1 named reads the pilot record line by line with the validators, and signs one of three:

• Holds. Every line of the table is accepted, and the first wave starts on the measurements.
• Holds with changes. A setting, a step, a message or a site's disposition changes, each written with its reason, and the part of the pilot it touches runs again, timings included: a changed method is an unproved one.
• Does not hold. A requirement no change meets returns to its chapter, as Chapter 29 returns one that no route meets.

In every case, the record fills Chapter 30's lines: the rehearsal's timings and findings, the baseline's rate, the freeze's window and the users' questions for the messages. Chapter 33 reissues the calendar from its rates, drift and validators' hours.

A pilot is a wave run to learn from: chosen for what can fail, measured as the waves will run, and allowed to change the plan.

Out of scope

Picking the simplest site and calling it a pilot, because it proves only that the simplest site moves. The farm and the attach are Chapter 23, verifying a copy and cutting over Chapters 8 and 9, testing Chapter 32, validation Chapter 34, cutover Chapter 35, rollback Chapter 36 and hypercare Chapter 37. Training, adoption programmes, survey tools, third-party tools, pricing and licensing are not covered.

Before you continue

• Every pilot site was chosen for a named risk, and together they cover every route, each kind of site and the largest objects
• The rehearsal kept production's access rules, changed nothing people use, and pointed live connections at test systems
• Online, the pilot ran Chapter 9's whole sequence at the waves' hours, its rollback boundary written before the cutover
• On Subscription Edition, the trial attach covered the largest database on a farm like production's, and the fallback was tested
• Every difference in the pilot's Chapter 8 record is a limit Chapter 29 listed or a finding with an owner
• Effective access and the same search queries were compared for named people on both sides, a disabled or unmapped account included
• Every user of the piloted sites recorded each task, and no answer was averaged
• The decision is signed, every change was proved again, and Chapters 30 and 33 carry the measurements

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