# What one SharePoint cutover weekend actually looks like (hour by hour) > The hour-by-hour runbook for a single SharePoint Online cutover weekend. Lock the source, run the final delta, migrate in waves, and make the go/no-go rollback call at the 6-hour mark, before you're too tired to make it well. [Home](https://tenantcraft.ca/) [Insights](https://tenantcraft.ca/insights) Migration Execute Apr 8, 2026 5 min read Geri Crroj Microsoft 365 consultant, Niagara, Ontario 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 5-minute version Lock the source site collections to read-only. Run the final SPMT delta. Migrate this weekend’s sites in waves. At hour 6, check your results against a failure threshold you set _during planning_, commit or roll back. Validate, then redirect users to the new URLs. Pre-write every email before the weekend starts. ## 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. ![Timeline of a 12-hour SharePoint cutover weekend with the hour-6 go/no-go gate marked](https://tenantcraft.ca/images/cutover-timeline.png) 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 | 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. Permission-only changes can be skipped A delta sync keys off modified dates. A file whose _only_ change since the last pass was a permission update won’t re-migrate, its modified date never moved. For the final pass, set the task to **overwrite all files** so permission changes actually land. **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. The rollback window closes at hour 6 Past the 6-hour mark, users are landing on SharePoint Online, not the source. Rolling back means reconciling that activity. Make the rollback call early, or commit. ## 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 full pre-cutover migration checklist SharePoint Server → SPO Migration Checklist PDF · 7 pages · 44 checkpoints [Email me the PDF](https://tenantcraft.ca/resources/guides/sp2016-eol-checklist) ## 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 out-of-support SP2016 or 2019 farm 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. TWENTY MINUTES, NO PITCH ## Tell me what is stuck. I will tell you what it takes. Same consultant from the first email to the last cutover. If I am not the right fit, I will refer you to someone who is. [Book a 20-min call](https://tenantcraft.ca/contact) [See published rates](https://tenantcraft.ca/pricing) --- _Canonical HTML: https://tenantcraft.ca/insights/migration-day-runbook · Agent guide: https://tenantcraft.ca/llms.txt · Site map: https://tenantcraft.ca/sitemap-index.xml_