Start the waves only on a readiness record that names what is not yet true

Chapter 2 counted the estate, and Parts II to IV decided what happens to it: each site's use (Chapter 14), disposition (Chapter 26), destination (Chapters 23 and 24) and route (Chapter 29). Different people own them, and nothing yet says whether together they suffice. This chapter gathers them into one readiness record, per wave and per site, and adds what no earlier chapter checked. It is the go or no-go before the go or no-go each cutover takes (Chapter 9).

What has to be true, recorded and owned, before the first site moves?

The decision this chapter leads to is a go or no-go for starting the waves, taken on a written readiness record in which each line is established, not established with an owner and a date, or a finding.

Which projects this chapter is for

A move from SharePoint Server 2016 or 2019, attached to Subscription Edition or copied into SharePoint Online and verified as Chapter 8 sets out. The record is read for the sites proposed for the first wave, then before each later wave; ordering them is Chapter 33.

One record, two levels, three states

Site lines repeat for every site collection: its usage class, confirmed by its owner; its disposition; its destination, every blocker answered; its route and what the route leaves; Chapter 8's baseline read; a dated scan. Wave lines are shared by every site in the wave:

Established means the evidence sits beside the line. Not established names why, an owner and the date by which it will be. A finding is a difference from what the plan assumed, fixed or accepted in writing by the owner of what it affects.

What Microsoft's assessment tools report, and what they do not

Support for the SharePoint Migration Assessment Tool (SMAT) ended on 1 October 2026, its download is gone, and its page sends SharePoint Server scans to the SharePoint Migration Tool (SPMT) (SMAT, checked on 7 November 2026). Microsoft's team sites migration guide still says to run SMAT (checked on 7 November 2026): follow SMAT's own page.

SPMT 4.0 and later scans one site or many, showing an inventory, its migration risks and a downloadable report (SPMT scan). Its documented codes include custom solutions, features and content types, unsupported pages and workflows, counts over the limits, lookups outside the scan and blocked script (scan codes, both checked on 7 November 2026). A site it could not read shows "Can't access": a gap in the scan, not a clean site (Chapter 8). Microsoft documents the codes, not the report's columns, so we do not know whether it counts use; no code concerns use or identity mapping, which SMAT's reports (Chapter 2) and its identity tool (SMAT, above) covered. Chapter 14's classes and Chapter 24's mapping stay lines of their own.

For an attach, Test-SPContentDatabase lists what a content database references but the web application that will host it lacks, and -ExtendedCheck also flags an authentication mode, claims or classic, that differs between versions (Test-SPContentDatabase, checked on 7 November 2026). It changes nothing, works on a database that is not attached, and can load one enough to block its use, which is why Chapter 15 runs it on copies. Nothing on its page covers use, identities, service applications or what the farm runs that no content references. Microsoft adds two conditions: every database at version 16.0.4351.1000 or higher, or the upgrade is blocked (upgrade overview), and consistency errors checked and repaired before the backup (copy databases, both checked on 7 November 2026). On the rehearsal farm, with the decided customisations installed, the test must come back empty or name only what Chapter 15 accepted.

We would repeat each scan in the week before its wave, so that a new finding is a line, not a surprise.

A backup is proved by a restore

A backup job that reports success is the producer's account of its own work. SQL Server's RESTORE VERIFYONLY checks that a backup is complete and readable, and "does not attempt to verify the structure of the data" (RESTORE VERIFYONLY). SQL Server's guidance is plainer: "You don't have a restore strategy until you test your backups", by restoring a copy onto a test system and running DBCC CHECKDB against it (back up and restore). SharePoint Server's guidance asks for practice recovery operations, which also show whether the recovery time objective is met (backup best practices, all three checked on 7 November 2026).

On an attach the backups are the move, one restored and checked before the others and the originals kept in reserve (copy databases, above); online they protect the read-only source that is Chapter 9's fallback. Either way, the line is established when a restore on another server came back clean and was timed against the recovery time objective its business owner set, with the keys it needs located, Secure Store's pass phrase among them (Chapter 10). A backup is proved by a restore, never by the job that reported it.

A baseline is measured before anything changes

Microsoft's capacity guidance names a farm's measures: requests per second at peak, daily requests without authentication handshakes, unique users per day, the median server-side latency and the slowest 5% of requests, with processor and memory, read from the IIS and ULS logs of an existing farm (capacity planning, checked on 7 November 2026). That page is written for SharePoint Server 2013, and we found no later version. Take the baseline on the old farm over a window with its peaks and a month end, before the databases go read-only: after an attach, the new farm is compared with it.

Throughput is the other half. Online, Microsoft throttles background work harder during weekday daytime hours (migration performance guidance), and names the speed at which the source can be read as a bottleneck to test for (SPMT performance, both checked on 7 November 2026). We would measure both in the rehearsal, at the hours the waves will run: Chapter 29's rate on your own content, and the old farm's counters against its baseline. Together they show which side limits the rate, and what the copy costs people still working. For an attach, Microsoft's procedure gives no rate (Chapter 29): the rehearsal times backup, copy, restore and attach on real databases, the largest included, and those times size the freeze.

Environments, and the rehearsal they exist for

Microsoft's page on verifying Subscription Edition upgrades names a trial upgrade as the place to find what has "to be reworked before you attempt to upgrade your production environment" (verify database upgrades); we found no Subscription Edition page on running one. Microsoft's guidance for the upgrade to 2016 asks for a test environment "as similar as possible to your real environment", "copies of your actual databases" and several test runs (best practices for 2016, both checked on 7 November 2026). Restoring production's backups onto that rehearsal farm proves two lines at once.

Online, Microsoft's Entra guidance offers a separate tenant for validating tenant-wide changes, which "reduces, but doesn't fully remove" the need for care in production (primary production tenant, checked on 7 November 2026). We would use one for tenant-wide settings, and rehearse the copy into the tenant that will receive the waves, in sites nobody uses yet, because its identities and throttling are those the waves will meet. Rehearsal copies are production content, and we would give them production's access rules and an end date.

The rehearsal itself is Chapter 31; here it needs an owner and a date before the decision, and its results fill the lines above.

The freeze and the messages are decisions with owners

On an attach the freeze runs from the backup to the cutover decision: Microsoft's sequence sets the databases read-only first, so users "can continue to view content" but cannot change it (copy databases, above). Online, it covers each wave's final delta, read-only and never No Access (Chapter 9). Either way, write the decision: which sites or databases, from when, until when at the latest, who may grant an exception, and what each integration that writes does meanwhile (Chapter 22). Each site's owner agrees the dates; the decider approves the whole.

Where a database is read-only, some tasks that seem available "return errors", and Microsoft asks you to set expectations for what users can still do (read-only databases, checked on 7 November 2026). Its migration guide asks for "clear statements of timing, expectations, and impact to the individual", and a helpdesk trained before the cutover (team sites migration guide, above). The record holds who sends what, to whom and when, Chapter 9's two messages included: a template is not readiness, a named sender with a date is. It also names, for each wave, Chapter 1's decider, the validators and the person who can say stop, each available for the window.

Go, or no-go

The decider decides with the record open, not a summary of it. Go when every line the first wave depends on is established, or is a finding fixed or accepted in writing, and every other line is at worst not established, with an owner and a date before the wave that needs it. Anything else is a no-go, with the lines that decided it written beside it. The decision, dated and signed, joins the records Chapter 9 keeps.

A readiness record is read line by line. No number of green lines outvotes the backup nobody restored.

Out of scope

The rehearsal and the pilot are Chapter 31, testing Chapter 32, the order of the waves Chapter 33, validation Chapter 34, cutover Chapter 35 and rollback Chapter 36. Backup and recovery design, high availability, farm sizing, communication templates, training, adoption and licensing are not covered.

Before you continue

• Every site proposed for the first wave has its class, disposition, destination, route, baseline read and a dated scan, each with an owner
• Every scan finding is decided, "Can't access" included, and every database for an attach is at 16.0.4351.1000 or later, free of consistency errors and tested on a copy
• Every backup the waves rely on was restored on another server, checked and timed, and the keys it needs are located
• The baseline covers a stated window with the old farm's peaks, and the rehearsal measured the migration rate and the farm's load together
• The rehearsal environment holds production content under production's access rules, and Chapter 31's rehearsal has an owner and a date
• The freeze has a scope, dates, an owner for exceptions and a plan for every integration that writes, read-only and never No Access
• Messages, senders and dates are written, the helpdesk is briefed, and the decider, validators and who can say stop are named
• Every line is established, not established with an owner and a date, or a finding, and the decision was taken on the lines, never on a total

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