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?

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 sequence below is that advice made into a plan with evidence at each step.

The cutover sequence as a timeline: baseline read, initial pass, measured delta, delta passes, a freeze only at the end, final delta, verification against the final state, and then the cutover decision, with hypercare and decommission after it. The source stays live for almost the whole sequence; the freeze is days, not weeks.

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, because nobody is waiting on it: the source is fully live. Expect it to be throttled and plan around that instead of against it. 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, and it is a measurement, not a guess. 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). Two properties of deltas matter for the plan. Each pass is smaller than the last if the drift rate is stable, so the sequence converges. And a delta is an additive mechanism: deletions and moves in the source do not reliably propagate as deletions in 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. Waves were sized in Part I precisely so that this line can be drawn.

Freeze read-only, never No Access. This is a documented trap. 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.

Two source locks compared: read-only stops user writes while migration tooling and the verification read keep working; No Access stops everything, including the final delta and the verification itself, and Microsoft's tooling skips sites locked that way.

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 with the throttling reality in mind: 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. The link inventory came from Part II; cutover is when it is spent.
  • 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, and the rollback you can still afford

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. Two disciplines during hypercare:

  • 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 criteria were written before cutover. Rollback is only cheap while the source is intact and read-only: it is unlocking a site. Define, in advance, what would trigger it, who decides, and until when the option stays open. After that date the destination is the system of record and problems are fixed forward. A rollback decided by criteria is an operation; one improvised in an incident call is a second migration.

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. 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 was Part I. 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
  • Rollback criteria, owner and expiry date were written before cutover
  • 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.

Send us a message

Email

Contact