Free Data Migration Cutover Plan Template
Migrations do not fail at the copy, they fail at the edges: permissions that did not come across, a wave sized from a lab measurement, and the delta nobody ran. This plan sequences a 60-day estate move as waves rather than a weekend, with a pilot that has to be signed off before wave one, a delta sync behind every wave, and two pre-logged risks that account for most of the overruns.
No credit card. Opens as a real project on the Free plan.
The download is a 14-task plan with phases, durations and milestones, ready for Excel or Google Sheets. It carries no dates, so set your own start, or paste it into the Gantt chart generator to have the schedule built for you. Want to compare the plans side by side first? Every one of them is on the project plan template page, with the rows shown before you download.
What’s inside
The full cutover plan is below, all 14 tasks across Discovery, Design, Pilot, Waves and Cutover, each with its description, duration and priority. Open the template and every date is scheduled from today, ready to compress around your own change window.
14
Scheduled tasks
5
Phases
4
Milestones
~9
Weeks end to end
Why this plan moves in waves
A big-bang cutover assumes two things that are rarely true: that you know your throughput, and that nothing changes in the source while you copy it. Neither survives contact with a live tenant. Microsoft 365 throttles migration traffic per tenant and publishes no number you can plan against, so the only honest throughput figure is one you measure against your own target, which is why proving it is a task in the Design phase rather than an assumption underneath the schedule. And the source keeps being used throughout, so anything migrated on day 30 is stale by day 40 unless a delta runs behind it.
Waves fix both. A wave is sized to the throughput you actually measured, and it is grouped by OWNER rather than by volume, so the people who share files with each other move together and nobody spends a fortnight collaborating across the migration boundary. The delta syncs run behind the waves during coexistence, which keeps the final pass small. That is the whole trick of a calm cutover: by the time you freeze the source, the last delta is minutes rather than days, and the endpoint switch, DNS, MX, or a mapped drive, is the cheapest step in the plan.
The pilot is the gate, and it is deliberately a gate rather than a phase you can overlap. One willing team, small enough to redo and representative enough to learn from, migrated and then reconciled against the baseline counts taken in Discovery. If you did not take those counts you cannot reconcile anything, which is why recording them is its own task before a single byte moves. Permissions are where the pilot earns its place: broken inheritance, nested groups and per-item permissions rarely survive intact, and finding out which ones during your final wave is what turns a cutover weekend into a cutover week.
The plan, phase by phase
Discovery4 tasks
Inventory the source estate
Site collections, mailboxes, file shares, group memberships. Record volume in GB and item counts, both matter to throughput.
Name a data owner for every workload
One accountable owner per site, share or mailbox group. Unowned data is what stalls a wave.
Record baseline counts for reconciliation
Item counts and totals per workload, captured before anything moves. You cannot reconcile against a number you did not take.
Agree what does not move
Archive, leave in place, or delete. Every GB ruled out here is throughput you get back later.
Design3 tasks
Map identities and group membership
Source accounts and groups to target accounts and groups, including the ones that will not exist on the other side.
Map permissions, and decide where inheritance breaks
Broken inheritance and per-item permissions rarely survive intact. Decide now which are recreated and which are dropped.
Choose the tooling and prove throughput
Measure GB per hour against the live target, not a lab. Throttling is the number every wave plan depends on.
Pilot3 tasks
Run a pilot wave with one willing team
A team that will tell you what broke. Small enough to redo, representative enough to learn from.
Reconcile the pilot against the baseline
Item counts, permissions, and a sample opened by a real user. Sign-off is the gate to wave 1.
Write the user comms and the rollback note
What changes, when, what to do if it looks wrong, and what the rollback actually is. Send before the wave, not during it.
Waves2 tasks
Migrate in waves by owner, not by volume
Group a wave around people who work together, so a half-migrated team is never trying to share a file across the boundary.
Run delta syncs behind each wave
Source stays live during coexistence, so everything already moved keeps changing. Delta until the final pass is small.
Cutover2 tasks
Final delta, then switch the endpoint
Freeze the source, run the last delta, then move DNS, MX or the mapped drive. The switch is the cheap part if the delta is small.
Decommission the source and reclaim licences
Read-only first, then decommission on a date you announced. Licences and storage are the savings the business was promised.
Milestones
Four checkpoints land on the timeline as diamonds: the pilot sign-off that gates wave one, the point where every wave has migrated, the production cutover itself, and the decommission that ends the licence spend.
Pilot signed off
Day 27 of the plan
All waves migrated
Day 46 of the plan
Production cutover
Day 54 of the plan
Source decommissioned
Day 59 of the plan
Frequently asked
Does this work for a SharePoint or Microsoft 365 migration?
Yes, that is what it is built for. The phases are workload-agnostic on purpose: discovery and ownership, identity and permission mapping, a gated pilot, waves with delta syncs, then the endpoint switch. That shape is the same whether you are moving SharePoint sites, Exchange mailboxes, a file server, or an Azure tenant-to-tenant move. The two pre-logged risks, throttling and permission mapping, are the two that bite hardest on Microsoft 365 specifically.
How is this different from your Microsoft Project migration template?
That one moves a scheduling tool: it exports .mpp files and Project Online OData, maps enterprise custom fields, and decommissions MS Project. This one moves an estate: identities, permissions, mailboxes, sites and shares, in waves. If you are migrating your project data into Onplana, use that one. If you are running an IT migration and need a plan for it, use this one.
Why waves instead of one cutover weekend?
Because a big-bang cutover assumes you know your throughput and that nothing changes in the source while you copy. Tenant throttling makes the first assumption unsafe and normal work makes the second one false. Waves let you size each batch against throughput you have actually measured, and the delta syncs behind them keep the final pass small enough that the endpoint switch is quick. A weekend cutover is still possible for a small estate; the plan compresses.
What do the baseline counts in Discovery actually do?
They are what reconciliation compares against. Item counts and totals per workload, taken before anything moves, so that after the pilot you can answer "did everything arrive" with a number instead of a spot check. It is the one task that is worthless if you do it late, which is why it sits in Discovery rather than next to the reconciliation task it feeds.
Is 60 days realistic?
For a mid-sized estate, yes, and the shape holds either way. Small estates finish faster, mostly by compressing the Waves phase into one or two batches. Large or heavily-permissioned estates spend longer in Design and in Waves, and that is the right place to spend it: the throughput measurement and the permission mapping are what make the wave schedule honest. The phases do not change.
Start with the plan already built
Open the Data Migration Cutover template free and your phases, tasks, and milestones are scheduled before the kickoff meeting. No credit card, no time limit.