Microsoft 365 Migration Plan: 12-Week Roadmap, Runbook and Checklist

9 min read ยท 2026-10-25

A Microsoft 365 migration plan is the schedule and set of decisions that move your users, mailboxes, files and collaboration tools from an old platform (an on-premises Exchange server, file shares, Google Workspace or another Microsoft 365 tenant) into Microsoft 365, without losing data or stopping work. It covers discovery, tenant setup, identity, a pilot, migration in waves, the final cutover and user adoption.

The roadmap below covers 12 weeks in six phases for a company of a few hundred users. Each phase has steps and a milestone you can check. It is written for IT managers, project managers and consultants who must run the migration and report on it. You will also find a filled-in example, who owns what, a cutover checklist, how to present the plan to leadership and the traps that cause lost mail and angry users on Monday morning.

The roadmap at a glance

Goal: All in-scope users work in Microsoft 365 for mail, files and meetings, data is verified against the source, security settings are on, and the old systems are ready to retire. Duration: 12 weeks

  1. Discovery and scope (Weeks 1-2)

    Know exactly what you are moving, how much of it, and what can break.

    • Inventory users, shared and resource mailboxes, distribution lists, file shares, SharePoint sites and their sizes.
    • List applications that send mail or connect to the old system, such as scanners, ERP alerts and CRM email sync.
    • Identify data you will not move: old archives, departed users, duplicate shares, and agree it with data owners.
    • Choose the migration method for mail and files, using Microsoft's documentation for your source system.

    Milestone: An inventory workbook and a scope document listing what moves, what stays and the method for each workload, signed off by the IT manager.

  2. Tenant, identity and security setup (Weeks 2-4)

    Prepare Microsoft 365 so users land in a secure, working environment.

    • Verify your domains in the Microsoft 365 admin center and plan the DNS records you will change at cutover.
    • Set up identity: cloud-only accounts or directory sync from on-premises Active Directory with Microsoft Entra Connect.
    • Assign licenses by group and set security basics: multifactor authentication, admin roles and sign-in policies.
    • Plan the target structure for files: OneDrive for personal files, SharePoint sites and Teams for shared ones.
    • Set retention, sharing and data loss rules with the security and compliance owner.

    Milestone: A configured tenant with verified domains, synced or created accounts, licenses assigned and MFA enforced for admins, checked against a setup checklist.

  3. Pilot migration (Weeks 4-6)

    Test the whole process with a small group before moving the company.

    • Pick 15 to 30 pilot users from IT and a few business teams, including at least one heavy mail user and one shared mailbox.
    • Migrate their mail, calendars, contacts and files, and set up Outlook, Teams and OneDrive on their devices.
    • Track every issue in a log: missing items, permission errors, mobile setup problems, slow syncs.
    • Time each step and measure data throughput so you can size the real waves.

    Milestone: Pilot users working fully in Microsoft 365 for one week, with a closed issue log and measured migration speed per user.

  4. Communication and training (Weeks 5-8)

    Prepare every user so cutover day is not a surprise.

    • Send a schedule by wave: what changes, when, and what users need to do before and after.
    • Run short training sessions on Outlook, Teams, OneDrive and sharing files.
    • Name local champions in each department who can answer first questions.
    • Prepare help desk scripts and a quick-start guide for the first day.

    Milestone: Every user has received the wave schedule and quick-start guide, and every department has a named champion.

  5. Migration waves and cutover (Weeks 6-10)

    Move users in planned groups and switch mail flow to Microsoft 365.

    • Pre-stage mail and file data in the background for each wave, then run a final sync at the cutover window.
    • Lower the DNS time to live a few days ahead, then switch MX and Autodiscover records to Microsoft 365 at the agreed time.
    • Migrate shared mailboxes and permissions together with the teams that use them.
    • Run a cutover runbook for each wave, with go or no-go checks and a rollback step.
    • Offer floor walkers or a priority help desk queue on the first day after each wave.

    Milestone: All waves migrated, mail flowing through Microsoft 365, and a data check (item counts and sizes) matching the source for every mailbox and share.

  6. Stabilize, adopt and decommission (Weeks 10-12)

    Fix leftovers, confirm adoption and retire the old systems safely.

    • Close open tickets and check that line-of-business apps send mail through the new setup.
    • Review usage in the admin center reports for Teams, OneDrive and SharePoint to spot teams still on old shares.
    • Make old shares read-only, keep backups for an agreed period, then decommission servers.
    • Write the handover: admin documentation, support process and lessons learned.

    Milestone: Old systems read-only or retired as agreed, handover document accepted by IT operations, and the project closed with the sponsor.

Example: a 400-user migration from Exchange and file shares

Picture a professional services firm with 400 users, an on-premises Exchange server near end of support and file servers in two offices. The IT manager has one internal engineer and a Microsoft partner for the technical work. Leadership wants the move done before the server support contract ends.

The lines below show how the template maps to that situation, with owners and milestones.

  • Weeks 1-2 (owner: IT manager): inventory shows a few hundred gigabytes of mail and a much larger file share, much of it unused. Data owners agree to leave old project folders in a read-only archive.
  • Weeks 2-4 (owner: partner engineer): directory sync set up, MFA rolled out for admins, SharePoint sites designed per department.
  • Weeks 4-6 (owner: internal engineer): 25 pilot users moved, issues found with a scanner sending mail and with mobile mail setup, both fixed and documented.
  • Weeks 6-10 (owner: IT manager and partner): four waves by department, each moved over a weekend, with a final sync and a Monday help desk queue.
  • Weeks 10-12 (owner: IT manager): old shares read-only, Exchange server retired after the agreed backup period, handover signed.

Who owns what

A migration touches every employee, so it needs more than IT. Name a sponsor who can approve downtime windows and settle disputes about what data moves. Give each workload a technical owner and each department a business contact.

Put the roles in a RACI and share it at the kickoff. Agree who makes the go or no-go call for each wave and who can approve a rollback.

  • Executive sponsor (COO or CIO): approves scope, downtime windows and budget.
  • Project manager: owns the plan, the RAID log, wave schedule and status reports.
  • Messaging and identity engineer: owns tenant setup, directory sync, mail migration and DNS changes.
  • Files and SharePoint lead: owns site structure, file migration and permissions.
  • Security and compliance owner: owns MFA, retention, sharing settings and data protection rules.
  • Help desk lead: owns first-day support, scripts and the issue log.
  • Department champions: answer first questions and report problems from their teams.

Cutover checklist

Each wave needs a written runbook so that the same steps happen in the same order every time, even at night or on a weekend. Run a dry walkthrough with everyone on the call before the first wave.

Keep the runbook short enough to follow live. If a step fails and there is no fix within the agreed time, roll back and reschedule rather than leaving users half-migrated.

  • Before: DNS time to live lowered, final user list confirmed, backups checked, communication sent, help desk briefed.
  • During: final data sync, DNS records switched, test mail sent in and out, shared mailbox and calendar access checked.
  • Go or no-go: project manager and engineer confirm checks with the sponsor or delegate.
  • After: spot-check a sample of users, monitor mail flow and the help desk queue, log issues and fix times.
  • Rollback: written steps and a time limit for deciding, owned by the messaging engineer.

Risks and dependencies

Most migration problems are known in advance. Write them in a risk log with an owner and a fallback, and review it at every weekly status meeting.

Dependencies usually sit outside IT: a vendor who must update an application, a department that needs a quiet week, or a legal hold on mail that must be kept. Find them in discovery, not on cutover night.

  • Apps that send mail through the old server: owner messaging engineer, fallback a relay or connector configured before cutover.
  • Large or unused file shares: owner files lead, fallback archive rather than migrate.
  • Legal holds and retention requirements: owner compliance owner, fallback confirm settings with legal before moving mailboxes.
  • Slow migration throughput: owner project manager, fallback smaller waves or more pre-staging time.
  • Users on old devices or Outlook versions: owner help desk lead, fallback device check during communication phase.

How to present it to leadership

Leadership cares about three things: business disruption, data safety and the end date. Put the six phases on one slide with the wave dates, and show which teams move when. Make it clear that each wave has a go or no-go check and a rollback.

In weekly status reports, show waves completed, users migrated, data verified, open issues by severity and the next wave date. Keep technical details, like sync errors and DNS records, in the appendix for the IT team. If a wave slips, explain why and the new date in one line.

How to adapt the plan

A small business with under 50 users can often move in one weekend after a short pilot. The phases stay the same, but discovery and training shrink to a few days and there is only one wave. Check the method that Microsoft recommends for your source and mailbox count.

A tenant-to-tenant migration after a merger or a Google Workspace migration adds work: coexistence planning for calendars and free or busy lookups, domain moves that must be timed carefully, and sometimes third-party migration tools. Allow more time for discovery and pilot, and confirm the supported methods in Microsoft's documentation before you commit to dates.

Common mistakes to avoid

  • Skipping discovery leads to surprises like forgotten shared mailboxes, so inventory every mailbox, share and mail-sending application before choosing a method.
  • Moving every old file wastes time and clutters SharePoint, so agree with data owners what to archive and migrate only active data.
  • Turning on MFA on cutover day floods the help desk, so enroll users in MFA during the communication phase.
  • Changing DNS without lowering the time to live first delays mail flow, so lower it a few days before each cutover.
  • Running waves without a rollback plan leaves users stuck, so write go or no-go checks and rollback steps into each runbook.
  • Treating cutover as the end means people keep using old shares, so track adoption reports and set a date when old systems go read-only.

Frequently asked questions

What should a Microsoft 365 migration plan include?

It should include a discovery inventory, the scope and method for each workload, tenant and identity setup, security settings, a pilot, communication and training, migration waves with a cutover runbook, and decommissioning. Each phase needs an owner and a milestone. Add a risk log and a status report format.

How long does a Microsoft 365 migration take?

It depends on the number of users, data volume, source systems and how many workloads you move. A small business can move in a few days, while a few hundred users often take a couple of months or more. Your pilot will give you real speed numbers to plan from.

What is the difference between a cutover and a staged migration?

In a cutover migration, all mailboxes move in one go and mail flow switches at once. In a staged or wave approach, users move in groups over several weeks. Check which methods Microsoft supports for your source system before you choose.

How do you migrate file shares to SharePoint and OneDrive?

Map each share to a target first: personal files to OneDrive, team files to SharePoint sites or Teams. Clean up old and duplicate data, then use a migration tool such as Migration Manager in the SharePoint admin center or a third-party tool. Check permissions after each move.

How do you avoid downtime during a Microsoft 365 migration?

Pre-stage data in the background so the final sync is small, and schedule cutovers outside business hours. Lower DNS time to live beforehand and test mail flow right after the switch. Have help desk staff ready on the first working day after each wave.

Generate this roadmap with AI