Most migration write-ups stop at “and then you cut over.” This one starts there. The planning is done, the source farm is mapped, and now you have a weekend to move people onto SharePoint Online without breaking their Monday.
This is the runbook for one cutover weekend, one wave-weekend. For a small tenant, that single weekend may be the whole migration. For something bigger, say 80 sites of real content, it’s one of several wave-weekends. Migration runtime scales with data volume, not site count, and a tenant of any real size won’t reliably move in a single 12-hour day. The shape of the day below is what each of those weekends looks like.
The cutover window, hour by hour
Here’s the shape of a single 12-hour cutover weekend. Treat the hours as a rhythm, not a stopwatch, your data volume sets the real pace.
The runbook at a glance
One cutover weekend. The hour-6 gate is the only decision point that matters.
T-1 day: an interim delta. The day before cutover, run an interim SPMT delta against the source. This catches most of the recent edits while users are still working normally, so the final delta after the lock has less to move. This is not the final pass, it’s a head start.
Hour 0: lock the source. SharePoint Server locks at the site-collection level, not the web-application level. There’s no one-click “lock the whole farm” button. Either go through Central Admin → Application Management → Configure quotas and locks and set each site collection to Read-only, or script it: Get-SPSite -WebApplication <url> | Set-SPSite -LockState ReadOnly. Then send the pre-drafted “we’re migrating today” email. Communications first, technical changes second.
Hours 0–2: the final delta. With the source locked, re-run your saved SPMT migration tasks. A re-run is the delta sync; SPMT transfers only new and changed files. There’s no separate “cutover” command or flag. SPMT is a GUI plus a PowerShell module (Register-SPMTMigration, Add-SPMTTask, Start-SPMTMigration), and the delta is just running the task again.
Hours 2–8: wave migrations. Migrate this weekend’s sites in waves. Microsoft does recommend running parallel tasks against different site collections to improve throughput; parallelism genuinely helps as long as you stay under roughly 5,000 jobs queued. On a small solo migration, though, there’s still a real case for sequential waves. It’s easier to monitor one wave at a time, triage failures cleanly, and keep your rollback boundaries crisp. That’s an operational choice, not a speed claim. Pick whichever keeps you in control of the weekend.
Hour 6: the go/no-go decision. This is the rollback checkpoint. Check each completed wave against the failure threshold you set during planning. If you’re under it, you commit. If you’re over it, you stop and triage. After hour 6, enough content has moved that user activity starts landing on SharePoint Online. Rolling back from that point means reconciling that activity, which is harder than fixing forward.
Hours 8–10: validation. Permission spot-checks across a sample of migrated sites, retention rules firing correctly, and a link-fix-up scan for cross-site references. Don’t expect search to be complete, more on that below.
Hours 10–12: link and redirect cutover. You can’t CNAME an internal hostname onto a *.sharepoint.com site, so this isn’t a DNS flip. It’s a redirect cutover: update intranet links, set up redirects from old URLs, and send the comms that point everyone at the new .sharepoint.com addresses. Validate single sign-on from a clean browser session, then post the “we’re live” message.
What goes wrong, and what to do about it
Three failure patterns dominate cutover weekends.
Throttling. Microsoft throttles background apps (migration, backup, DLP) harder during weekday daytime hours, measured in your SharePoint tenant region’s time zone, and eases off evenings and weekends. You can’t disable it or get it waived with a support ticket. So run cutovers off-peak: overnight, weekends. That’s most of why a cutover is a weekend.
Permission drift. Even after a clean pre-cutover audit, some sites will have permission-mapping issues. How many depends entirely on the hygiene of your source; there’s no universal percentage. The fix isn’t a number to memorise. It’s a decision you make in advance. Set your own go/no-go failure threshold during planning so the hour-6 call is mechanical, not a tired judgement call.
Search index lag. SharePoint Online indexes continuously. Individual items usually surface within an hour, but fully indexing a large migration can take anywhere from a day to several days. There’s no fixed window. Tell users to expect incomplete search for a day or two, and tell them before they go looking and panic.
Most migration disasters are communication failures, not technical ones.
Pre-write the comms
The single highest-leverage thing you can do before cutover weekend: pre-write three emails, T-7, T-1, and day-of. Include screenshots of what users will see, the expected outage window, and one named point of contact. Write them when you’re calm and rested, not at hour 4 of a cutover.
Most migration “disasters” are communication failures. The content moved fine; nobody told the people who depend on it what to expect. Comms cost you an hour the week before. Skipping them costs you a Monday.
The window holds because of the prep
A cutover weekend feels like the migration. It isn’t. It’s the visible 12 hours of work that started weeks earlier: the source mapping, the cleanup, the interim deltas, the comms drafts. A weekend that goes smoothly is almost always a weekend that was boring, and it was boring because the hard decisions were already made.
Two of those decisions matter most. The first is your failure threshold. Decide it during planning, write it down, and let the hour-6 gate be a mechanical check against it rather than a judgement call made by a tired person at 2 AM. The second is the discipline to actually use that gate, to roll back when the numbers say roll back, even when you’ve already invested six hours.
If you’re staring at an SP2016 farm and a deadline and you’d rather not learn this rhythm under fire, that’s a reasonable thing to talk through before you commit a weekend to it. A short discovery call can sort out whether your tenant is a one-weekend job or a several-weekend one, no pitch, just a straight read on the work in front of you.