Office 365 Migration Plan: The Phase-by-Phase Template

Every failed migration we've been called in to rescue had the same root cause: no plan, or a plan that was really just a date on a calendar. This is the actual project plan we run — five phases, each with tasks, owners, durations, and exit criteria you must hit before moving to the next phase. Copy the tables, put names in the owner column, and you have a working Office 365 migration project plan. Pair it with our Microsoft 365 migration checklist, which covers the item-level detail inside each phase.

Phase 1 — Discovery & Assessment (1–3 days)

You cannot migrate what you haven't counted. Phase 1 produces the inventory every later decision depends on: how many mailboxes, how much data, what talks to your mail server that isn't a human.

What goes wrong in Phase 1: the dependency map gets skipped because "it's just email." Then Monday morning after cutover, the scan-to-email on every copier is dead, invoices from the ERP stop going out, and the backup system has been silently failing to alert for two days. Those devices were relaying through the old server; nobody put them on the list. Walk the office. Look at every device with an Ethernet port. Ask accounting what emails them automatically. This one day of work prevents 80% of day-one tickets.

Phase 2 — Tenant Preparation (1–2 days)

Build the destination completely before a single message moves. A half-configured tenant discovered mid-migration is how weekends get lost.

What goes wrong in Phase 2: two things, repeatedly. First, the security baseline gets deferred "until after migration" — and after never comes; you've now migrated everyone into a tenant with no MFA and basic auth wide open. Do it before users arrive, when there's nobody to disrupt. Second, nobody lowers DNS TTL in advance. If your MX record has a 24-hour TTL and you flip it Saturday night, some mail servers keep delivering to the old system into Monday. Drop TTL to 300 seconds two days early and cutover propagates in minutes.

Phase 3 — Pilot (2–3 days)

Migrate 10–20 real users before you migrate everyone. Not the IT team — they tolerate broken things. Pick people across departments: one from finance with delegate access to a shared mailbox, one heavy calendar user, one road warrior on mobile, one person who lives in a distribution list.

What goes wrong in Phase 3: the pilot passes because it was too easy. Ten IT-adjacent users with clean 2 GB mailboxes and no delegate permissions prove nothing. The failures live in the edges — the executive assistant managing three calendars, the 40 GB mailbox, the shared mailbox with 14 people attached. Put the hard cases in the pilot. A pilot that finds nothing wrong is a pilot that was designed not to look.

Phase 4 — Batched Migration & Cutover (the long pole)

This phase's duration is set by physics: data volume divided by real-world transfer rates, which are throttled by the source system, not by your bandwidth. The strategy that makes cutover weekend boring is pre-staging — copy 95% of the data while users keep working on the old system, then move only the delta at cutover.

What goes wrong in Phase 4: teams skip pre-staging and try to move everything in the cutover window. A 500 GB migration does not fit in a weekend when the source throttles exports — the window blows, Monday arrives mid-copy, and now you're running two mail systems with users split across both. The second failure is a rollback plan that exists only as the sentence "we'll roll back if needed." A rollback you haven't written down, with a decision deadline and a named decision-maker, is not a plan — it's a hope. Sign it off before Saturday.

Phase 5 — Hypercare & Decommission (30 days)

The project isn't done when the data lands. It's done when users stop noticing anything changed and the old system is safely gone.

What goes wrong in Phase 5: decommissioning too fast — the old server gets wiped on day 3, and on day 9 someone discovers a public folder or a forgotten application mailbox that never made the inventory. Keep the source in read-only for 30 days minimum. The opposite failure is never decommissioning: the old server runs for two years "just in case," unpatched, still accepting connections. Both are avoidable — put the decommission dates in the plan now, in Phase 1, and hold them.

Adapting the plan by size

RACI — who does what

R = responsible (does the work), A = accountable (owns the outcome), C = consulted, I = informed. In a 10-user shop one person holds three columns — the point is that every row still has an A, so no decision floats ownerless.

The template

The five tables above are the template. Copy them into a spreadsheet, replace the owner roles with names, replace the duration ranges with dates, and add a status column (Not started / In progress / Blocked / Done). That's a working migration plan — the exit criteria columns are your phase gates, and a phase isn't done until every row in it passes. For the item-level detail behind each row, use the migration checklist alongside it; for execution technique, see our Office 365 migration best practices.