Cut over without losing the truth

Chapter 8 proved what moved. This chapter is about the harder operational fact: while you were proving it, people kept working. Every document edited after the baseline is a document your verification never saw, and the gap between the two only closes on purpose.

When is it safe to point people at the new estate, and what evidence makes it safe?

Which destination this chapter is for

This chapter is written for content that arrives by copy: a move into SharePoint Online with the SharePoint Migration Tool or the Migration API, in passes, under throttling, closed by deltas.

An upgrade from SharePoint Server 2016 or 2019 to Subscription Edition is not a copy, and none of the copy mechanics below applies to it. Microsoft supports it only by database attach (copy databases to the new farm, checked on 1 November 2026), so there are no passes and no deltas to shrink: the 2016 or 2019 databases are set read-only before the backup, people keep reading the old farm and nobody can change it, and that freeze lasts from the backup until the cutover decision. Chapter 23 sets out the sequence.

Both destinations share the rest of this chapter's discipline: verify before cutover, decide by evidence, and write the rollback boundary before anyone is pointed at the new estate.

A migration is not a copy operation

A copy has a start and an end. A migration of a living estate has a start and a decision, and between them the source is being edited by the same people whose work you are moving. Plan it as a copy and the project produces its own failure: the longer the copy takes, the more the source has drifted by the time it finishes, and the "completed" report describes an estate that no longer exists.

The correct mental model is a sequence of passes that each shrink the difference between the two sides, closed by a short freeze, a final delta, a verification, and a decision. Microsoft's own guidance for migration points the same way: keep the destination unactivated for users while the source remains active for reading and writing, and switch users only after completion (Migration API best practices, checked on 18 August 2026).

The baseline, the initial pass, and the deltas

Baseline first. The baseline read from Chapter 8 is taken before the initial pass, and it does double duty here: it is the before-state for verification, and it is the yardstick for how much the source drifts per week, which you will need to size the freeze.

The initial pass moves the bulk. It is the longest pass and the least urgent one: the source is fully live. Throttling in SharePoint cannot be disabled and a support ticket does not lift it; background migration traffic gets meaningfully more throughput during evenings and weekends in the tenant's region, and migrations should run with app-based authentication, not as a signed-in user, because user-mode migration triggers heavier throttling (migration performance guidance, checked on 18 August 2026).

Measure what changed meanwhile. After the initial pass, read the source again and diff against the baseline: that number, items changed per week, is the drift rate. It tells you two things the plan needs: how big each delta pass will be, and how short the final freeze can afford to be.

Delta passes shrink the gap. The SharePoint Migration Tool supports exactly this shape: a saved task rerun later moves only new or updated files, and on the destination side it performs an incremental check, skipping a file whose source modified time is not newer than the target's (SPMT supported features, checked on 18 August 2026). Each pass is smaller than the last if the drift rate is stable, so the sequence converges. Treat a delta as additive: Microsoft's description of reruns does not say that deletions and moves in the source reach the destination, which is one more reason the final verification compares reads instead of trusting pass reports.

Freeze only what must be frozen

The freeze is the most expensive line in the plan, because its cost is paid by every person who cannot work. Three rules keep it honest.

Freeze late. The freeze exists to stop drift during the final delta and verification, nothing else. With a measured drift rate and converging deltas, the final delta is small, so the freeze is days, not weeks.

Freeze narrowly. A freeze is per estate, not per organisation. The site collections in this wave freeze; everything else keeps working. Chapter 33 sizes the waves so that this line can be drawn, and weighs a single cutover for all users, which Microsoft recommends, against one per wave.

Freeze read-only, never No Access. A site set to No Access is locked for users and for tooling: Microsoft's migration assessment documentation states plainly that locked sites cannot be migrated because the tooling is unable to read the contents, and its scans skip them (Locked sites scan, checked on 18 August 2026). The lock that looks safest is the one that kills your final delta and your verification read in the same stroke. Read-only stops the drift and keeps every read working; it is the only lock this plan uses.

The final delta, and verify before cutover

With the source read-only, run the final delta, then take the verification read of the destination and produce the Chapter 8 record against the baseline and the deltas' combined result. This is the step that turns the cutover from a hope into a decision:

Cutover is a decision supported by evidence, not the moment a migration tool reaches 100%.

Size this window for throttling: the Migration API processes jobs on a best-effort basis with no guaranteed performance (Migration API introduction, checked on 18 August 2026), so the plan gives the final delta a buffer measured from your own earlier passes, not from a vendor's average. If the verification comes back with findings, the freeze holds while they are resolved or explicitly accepted; a finding accepted at cutover is a risk someone signed, which is a decision, and a finding nobody read is not.

The cutover itself

Pointing people at the new estate is mechanics plus communication, and both were prepared before the freeze started:

• Addresses. Everything that carried the old URLs: bookmarks and links inside migrated documents, navigation, DNS names where used, and the redirects that will catch what you cannot rewrite.
• Integrations. Every system that read from or wrote to the source, redirected and tested against the destination before the freeze, on a copy already populated by the passes. Cutover should be the day integrations switch, never the day they are first tried.
• People. The communication is short and concrete: what moved, the new address, what is read-only where, and who to call. Send it twice, before the freeze and at cutover; the second one is the one people read.

Hypercare

For a fixed period after cutover, days for a small wave and two weeks for a large one, the migration team is visibly reachable and the old estate stays read-only and untouched.

Triage against the record. When someone reports "my file is missing", the verification record answers whether it ever existed in the baseline, was migrated, or was unknown at verification. Without the record every report is an archaeology project; with it, most are a lookup.

Rollback ends where the destination's writes begin

Rollback is often written as one line: unlock the old site and point people back. That line holds only while the destination has accepted no write. Pointing people back at it hides every change made since cutover, and the business has already been told those changes succeeded.

So the rollback plan is one procedure per state, written before cutover:

Three rules make the table usable:

• One writer at a time. The cutover is a recorded instant at which write authority moves. The source stays read-only from then on, and a rollback makes the destination read-only before the source accepts a single write.
• After the first accepted write, the default is to fix forward. A rollback from that point is a reverse migration of every change since cutover, with its own verification record, planned as one rather than improvised in an incident call.
• No rollback is promised as lossless without evidence. The plan says which changes would survive a rollback and how that is proved. Where it cannot be proved, the plan says so, and the decision to proceed is signed with that limitation.

On Subscription Edition the fallback Microsoft documents is the original farm: the backups taken before the upgrade keep the data "in a safe state if you must enable the original farm again" (copy databases to the new farm, checked on 1 November 2026). We have found nothing that establishes an upgraded database can be attached back to SharePoint Server 2016 or 2019, so the fallback is the preserved source, never the upgraded copy, and everything written to the new farm after cutover is outside it.

Decide in advance what would trigger a rollback, who decides, and until when the option stays open. After that date the destination is the system of record and problems are fixed forward.

Decommission only after the evidence survives on its own

The last step is the one that makes Chapter 8 non-negotiable. Decommissioning the source destroys the only independent witness of what the estate contained; after that day, the verification record is the before-state. So the gate for decommission is not a calendar date. It is a property: the verification record exists, its findings are resolved or signed, its digest has been recomputed by someone other than its producer, and it is stored somewhere that outlives the project. Where Migration Manager moved file shares, its file share reports "expire in 90 days" and "Microsoft doesn't retain the log files" (Migration Manager reports, checked on 7 November 2026), so they are downloaded into that archive before then. We recommend archiving it with the sign-off papers, because that is the shelf people will search two years later. Only then does the read-only source become a decommission candidate, on whatever retention the organisation owes it.

Out of scope

This chapter schedules and closes a wave whose content, destination and verification method were decided in earlier chapters. It does not choose the waves; that is Chapter 33. It does not verify content; that is Chapter 8, and this chapter only decides when that verification runs. Tenant-level rollout beyond SharePoint, and the modernisation work waiting on the other side of the move, belong to Parts III and IV.

Before you continue

• The drift rate of the source is measured from two reads, not estimated
• Delta passes are scheduled, and each one is smaller than the one before it
• The freeze is scoped to the wave, starts after the last routine delta, and is read-only, never No Access
• The final delta has a buffer sized from your own passes, not from a vendor average
• The verification record is produced against the final state before anyone is pointed at the destination
• The destination is named: a copy into SharePoint Online follows this chapter's passes, an attach to Subscription Edition Chapter 23's sequence
• Rollback criteria, owner, expiry and a procedure for each state were written before cutover, and write authority moves at one recorded instant
• The source is decommissioned only after the verification record is archived and independently checked

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