Accept each wave on criteria written before it, signed by the people who use it

Chapter 8 compares two reads of a copy, Chapter 23 reads every attached database three ways, and Chapter 9 closes a copy wave on a verification record. Each proves what the migration team did. None says whether the business can work on what arrived, and only the business can say that. This chapter is the layer above them: what each wave's owners accept, on what evidence, who signs, and what happens when a criterion fails.

How do you know the migration worked, rather than merely finished?

The decision this chapter leads to is one of three for each wave, taken on criteria written before it: accept it, every line signed by the owner of what it protects; fix what failed and test it again; or roll it back.

Which waves this chapter is for

Every wave in Chapter 33's calendar, to either destination: SharePoint Server Subscription Edition by database attach, or SharePoint Online by copy with the SharePoint Migration Tool (SPMT) or a tool on the Migration API. Migration Manager takes part only for file shares moving with the sites: it "doesn't support the migration of content from SharePoint Server" (Migration Manager FAQ, checked on 7 November 2026).

Acceptance runs inside an attach's read-only window or a copy's freeze, after the technical verification and before Chapter 35's cutover decision. Chapter 30's readiness record named the validators, the evidence and the window, and Chapter 33 sized each wave to its validators' hours; this chapter spends them.

Verification proves the move; acceptance proves the work

Chapter 8's record and Chapter 23's readings belong to the migration team: did what the source held arrive, did each database upgrade. Acceptance belongs to the validators Chapter 1 named: does the site do what they use it for. A migration lead cannot validate content, Chapter 1 said: the migration team signs the verification, never the acceptance.

We recommend writing the acceptance record before the wave, with the people who will sign it: one line per site and criterion, holding the test, what passes, the evidence kept and the signer. Written afterwards, a criterion takes the shape of whatever the destination turned out to do. Each line ends in one of Chapter 30's three states: established, with its evidence and a signature; a finding, fixed or accepted in writing by the owner of what it affects; or not established, with an owner and a date.

The criteria, destination by destination

Sources for the table: upgrade service applications, SharePoint Workflow Manager on a new farm, search diagnostics, managed metadata migration, make sure content can be found and Page Diagnostics, all checked on 7 November 2026.

Validators test with items created for the test and listed in the record. Editing the business's own files makes the destination differ from Chapter 8's record, and on a copy a rerun skips a destination file newer than its source (Chapter 9). A test that runs a workflow or an integration into another system is agreed first with that system's owner (Chapter 22), so that nothing outside SharePoint takes a test for real work.

Accepting an attach to Subscription Edition

Acceptance starts when Chapter 23's readings are clean for every database behind the address, and the search line comes last: the new farm's index "is empty" until "a full crawl of the entire indexed corpus" runs after the content databases are upgraded (upgrade service applications, above), and the crawl log and health reports "only contain information after a full crawl has completed" (search diagnostics, above).

Microsoft's checklist for the upgraded environment asks whether service applications are configured as intended, "Are all features associated with the sites working?", whether queries return appropriate results and, "Twenty-four hours later", what the query reports show (verify database upgrades). Its checklists for upgraded sites add large lists, throttled by default, and pages whose images, style sheets, themes or scripts broke; each site's administrator can read its own Upgrade Status page (upgrade a site collection, both checked on 7 November 2026). We would make each question a line of the record, beside Chapter 23's functional checks.

The new farm keeps every address (Chapter 23), so validators test it before the address moves, and Microsoft does not document how they reach it meanwhile. We would point only the validators' own machines at it, by a recorded name-resolution entry removed at cutover, so that they test the addresses, links and customisations people will use.

Three risks belong to this destination:

• The window is the read-only period. Every hour of acceptance, the full crawl and the day before the query reports included, is an hour in which nobody can change the old farm (Chapter 33).
• Features the old farm ran may be off. Microsoft's updates from August to October 2026 turn off SharePoint 2010 workflows, the ToolPane, ImportWeb, ExecuteProxyUpdates, GetDataFromDataSourceControl and file-based BDC model import, each turned back on for a site collection by its own cmdlet (August, September and October 2026 notes, checked on 7 November 2026). A site that relied on one can fail its test here, the right place to find out, and its owner decides as Chapter 19 does for workflows: rebuild, or a dated exception.
• One failed site holds its address. The address cuts over once (Chapter 33), so one site's unresolved finding holds every database behind it.

Accepting a copy into SharePoint Online

Acceptance starts after Chapter 9's final delta and Chapter 8's record against the final state, in destination sites nobody else uses yet: Microsoft's guidance is to "deactivate the target site for users until migration completion" (Migration API, checked on 7 November 2026). Its assessment pages give the test to the site's own people: "Site owners performing user acceptance testing (UAT) on their content should validate that their sites migrated correctly" (checked-out files), and content in another language needs "someone that speaks the language the content is in" (site template language, both checked on 7 November 2026). Both document SMAT, now out of support (Chapter 30); the advice outlives the tool.

A copy translates, and its risks sit in the translation. Identities and access arrive as the mapping allowed (Chapter 24). SPMT takes terms from the one term store set as default, and more than one default "can break managed metadata columns" (managed metadata migration, above). Every address changes (Chapter 12), and Microsoft does not document that SPMT rewrites links inside documents, so each recorded link is opened, never assumed. Workflows and forms arrive rebuilt or not at all (Chapters 19 and 20), so they pass against a specification, never against memory.

Two criteria need time inside the freeze:

• Search. The tenant crawls "based on a defined crawl schedule", Microsoft does not document how long a copied site takes to appear, and reindexing a site "can cause a massive load on the search system" (crawl site content, checked on 7 November 2026). We would wait for the site's content rather than reindex it to hurry.
• Performance. "Load testing isn't allowed on SharePoint Online" (throttling, checked on 7 November 2026), and Page Diagnostics' page load time depends on "network latency, the performance of the computer" and the browser (Page Diagnostics, above). The old farm's server-side baseline measures something else; the same tasks, timed from the same desks, compare.

A failure whose cause lies in one site holds that site alone; a cause in the route holds every wave using it (Chapter 33).

When a criterion fails

A failed line has three exits, and the record says which was taken, by whom and when:

• Accept the finding. The owner of what it affects signs that the site goes with the difference, and the date of its fix, if there is one. A view throttled on a large list, accepted with a date for its index, is a decision; a finding nobody read is not (Chapter 9).
• Fix it and test again. Repeat the failed line and every line the fix touches: a permission fix touches search, a term set fix every view filtered on it. The fix and the repeat fit the window, or the window grows with its owners' agreement (Chapter 33).
• Roll back. When nobody accepts the finding and no fix fits the window, the wave, or on a copy the site, returns to its source, decided by whoever Chapter 9's plan names. Before cutover it sits in the first of Chapter 9's states, the destination having accepted no business write; the procedure is Chapter 36's.

Only a line that cannot be read before people arrive may stay not established, with an owner and a date inside hypercare (Chapter 37): performance under real load is the usual one. A validator who has not signed by the end of the window has not accepted, and the wave fails its verification and stops the next, as Chapter 33 writes.

Who signs

Each line is signed by the owner the table names for it, the infrastructure owner being whoever took Chapter 30's baseline; the migration team signs Chapter 8's record and Chapter 23's readings. The wave is accepted when every line is signed, and the decider reads those lines, never a summary of them, when Chapter 35 takes the cutover decision.

A tool that finished has accepted nothing. A wave is accepted line by line, by the people who use it.

Out of scope

Chapters 8, 9 and 23 own the technical checks used here. The pilot is Chapter 31, testing Chapter 32, cutover Chapter 35, rollback Chapter 36, hypercare Chapter 37 and measuring success Chapter 40. Automated interface testing, load testing and continuous monitoring, which is operations, are not covered.

Before you continue

• The acceptance record, with each site's tests, pass conditions, evidence and signers, was written before the wave
• Acceptance began after Chapter 8's record or Chapter 23's readings were clean, and after the full crawl on an attach
• Validators tested before cutover, at the addresses people will use, with test items listed in the record
• Workflows, forms and integrations passed their specifications, every run into another system agreed with its owner
• Performance was compared on timed tasks; only lines that need real load stay open, with an owner and a date
• Every failed line records its exit: accepted in writing, fixed and retested with what the fix touched, or rolled back
• Every line is signed by the owner of what it protects, and no wave passed on a validator's silence
• The decider read the signed lines, never a total, before the cutover decision

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