Before the opinion: here is where migration project time actually goes, based on the pattern that shows up across most SharePoint tenant-to-tenant moves.
| Phase | Typical share of project time | Can it run without downtime? |
|---|---|---|
| Pre-migration audit and cleanup | 20 to 30 percent | Yes, fully live |
| Bulk content transfer | 40 to 50 percent | Yes, source stays read-write |
| Delta sync and reconciliation | 10 to 15 percent | Mostly, short read-only tail |
| Cutover, links, and verification | 5 to 10 percent | No, requires the locked window |
| Unplanned rework (throttling, mapping errors) | Variable, often underestimated | Depends on what fails |
Most project plans still treat all of this as one undifferentiated block called "the migration," booked as a single weekend, with the whole tenant assumed to be off limits the entire time. That assumption is where most SharePoint migration schedules go wrong, and it is worth unpacking why.
The window people plan for is bigger than the window they need
A tenant-to-tenant SharePoint migration does not actually require the source to go read-only for the whole duration. Bulk transfer of content, the phase that consumes the largest share of total project time, can run against a live source. Users keep working; the migration tool reads content in the background. What genuinely requires a locked window is much narrower: a final delta sync to catch anything changed since the bulk pass, followed by cutover activity such as redirecting links, updating DNS if a vanity domain is involved, and a verification pass before announcing the new environment as authoritative.
That narrower window, done well, is frequently a matter of hours rather than the multi-day weekend blackout that gets booked by default. The gap between the two comes down to whether the migration is planned as one monolithic event or as a staged pipeline with a clearly bounded cutover at the end.
The realistic downtime for a well-prepared migration is the delta sync plus cutover, not the whole transfer. Teams that book a weekend for the entire process are usually budgeting for the bulk transfer time, which never needed to be downtime in the first place.
Where the "variable" row actually bites
The line item most project plans underestimate is the last one in the table: unplanned rework. Three sources account for nearly all of it in practice. The first is version history volume that was never audited before the project started; a library with years of untrimmed versions can multiply transfer time several times over compared to its current working content size, and that multiplier is invisible until the transfer is already running. The second is Microsoft 365 throttling, which slows or queues requests once a tenant crosses certain rate thresholds during sustained bulk activity, turning an estimated overnight transfer into one that spills into the next business day. The third is permission and metadata mapping surprises: lookup columns pointing at lists that don't exist in the destination structure, or unique permission trees that weren't accounted for during scoping, discovered only when the migration tool hits them mid-run.
None of these three are unavoidable. All three are things a pre-migration audit surfaces cleanly, well before a cutover date is ever booked. Running a version history and storage audit ahead of time (see the piece on why version history quietly fills your storage budget) and trimming aggressively before the transfer starts removes the single biggest source of unplanned volume. Mapping permissions and metadata dependencies during scoping, rather than discovering them live, removes the second and third.
What a realistic plan looks like
A realistic migration plan separates the phases that can run live from the one that cannot, and budgets contingency against the causes of rework rather than against the transfer itself. In practice that means: run the audit and version trim weeks ahead of any cutover date, so the transfer volume booked into the schedule reflects trimmed content rather than years of accumulated bloat. Run the bulk transfer against a live source over however many days the volume genuinely requires, since nobody is locked out during this phase. Reserve the locked cutover window for what it is actually needed for: the final delta, the link and DNS changes, and verification, which is a matter of hours for most site or tenant migrations once the heavy lifting is already done.
ShareMaster's Clone Master transfers bulk content while the source site stays live, which is what keeps the locked cutover window down to a short final sync and verification pass rather than the whole transfer. For the mechanics of running a cross-tenant site move end to end, the guide to migrating a SharePoint site to another tenant walks through the staged approach in detail, and the migration throttling limits reference is worth checking before booking a transfer window on a large tenant.