Microsoft 365 · Migrations

Microsoft 365 migration checklist.

A Microsoft 365 migration is the planned move of your email, files, identities and devices into a Microsoft 365 tenant. Done properly it follows the same disciplined sequence whatever you’re moving from — discovery, licensing, identity, mail, files, devices, a security baseline, then a single clean cut-over. This is that checklist, in order.

By Rob Smith Published 3 Jun 2026 Reviewed Jun 2026 8 min read
KEY TAKEAWAYS
  • Most of the work is before the cut-over — discovery, licensing and identity decide whether the switch is smooth.
  • Pre-sync mail and files so the actual cut-over is a single planned window, not a scramble.
  • Build the security baseline — MFA, conditional access, device management — in from the start, not afterwards.
  • A typical UK SMB migration runs four to eight weeks depending on user count and data volume.

Before you start: scope it honestly

The single biggest cause of a painful migration is skipping discovery. You can’t move what you haven’t counted. Before any data shifts, get a clear picture of users, mailboxes, shared mailboxes, distribution lists, data volumes, devices and the apps your team genuinely depends on. Everything that follows is sized off this. This checklist is source-agnostic — if you’re coming specifically from Google, pair it with our Google Workspace to Microsoft 365 migration guide for the source-specific mapping.

The full checklist, in order

  1. Discovery & audit. Count users, mailboxes, shared mailboxes, distribution lists and aliases. Measure data volumes for mail and files. Inventory devices, browsers and the line-of-business apps people actually use. Note who owns DNS for your domain.
  2. Licensing. Map users to the right Microsoft 365 plan — Business Basic, Standard or Premium — based on whether they need desktop Office apps and how much security and device management you require. Pricing is per user, per month and varies by plan and commitment. Order licences with a little headroom.
  3. Tenant setup & identity. Provision the Microsoft 365 tenant, verify your domain, and stand up identity in Entra ID. Decide on cloud-only versus hybrid identity, create or sync user accounts, and plan group structure.
  4. Security baseline. Before users sign in for real, enable multi-factor authentication, set conditional access policies, and configure malware protection and a device-management baseline. These are the controls that also underpin Cyber Essentials — build them now, not later.
  5. Mail migration. Pre-sync mailboxes, shared mailboxes and calendars into Exchange Online ahead of the switch. Recreate distribution lists, shared mailboxes and permissions. Plan MX, SPF, DKIM, DMARC and autodiscover records so mail flow can be flipped cleanly.
  6. Files migration. Move personal files into OneDrive and shared or team data into SharePoint, mapping existing folder structures and access permissions. Pre-stage large data sets early so the final delta sync is small.
  7. Devices & apps. Enrol devices into management, deploy the Microsoft 365 desktop apps where licensed, and configure Outlook, OneDrive sync and Teams. Test sign-in and conditional access on a pilot device.
  8. Pilot. Migrate a small representative group first. Confirm mail flow, calendar, files, sign-in and apps all work, and fix anything before the wider rollout.
  9. Cut-over. Run the final delta sync, switch DNS and mail flow in a planned window — often a weekend — and confirm new mail lands in Microsoft 365. Communicate the window and what users should expect.
  10. Post-migration. Verify all mailboxes and files, reconnect Outlook and OneDrive on each device, run user onboarding, and monitor for a couple of weeks. Decommission the old platform only once you’re confident, and confirm backup is protecting the new tenant.
A good migration is boring on cut-over day — because all the thinking happened weeks earlier.

Where things usually go wrong

Three recurring traps catch unprepared migrations. First, DNS surprises: nobody can find who controls the domain, or TTLs are too long, so mail flow stalls. Lower TTLs days in advance. Second, permissions drift: shared mailbox access and folder permissions don’t carry across unless they’re explicitly mapped. Third, treating backup as optional: Microsoft 365 replicates your data but is not a backup. A third-party backup of the new tenant should be live before you decommission the old system.

Do it once, do it right

None of this is exotic, but it rewards method over improvisation. If you’d rather not run it in-house, our managed M365 migrations follow exactly this sequence, and our Microsoft 365 management keeps the tenant healthy afterwards. The goal is the same either way: a Monday morning where the team opens Outlook and everything is simply where it should be.

FAQ

Questions we get asked.

How long does a Microsoft 365 migration take?

For a typical UK SMB, four to eight weeks end to end, depending on user count and data volume. Most of that is discovery, licensing, identity and pre-staging data; the actual cut-over of mail and files is usually a single planned window, often over a weekend, so the team comes back to a working tenant on Monday.

Will we lose email during the migration?

No. A well-run migration pre-syncs mailboxes into Microsoft 365 before the cut-over, then switches mail flow during a planned window. Messages arriving during the switch queue at the sending server and deliver once DNS propagates. With MX and autodiscover records planned in advance, users typically notice nothing beyond re-opening Outlook.

How is this different from a Google Workspace migration?

The checklist is the same — discovery, identity, mail, files, devices, security baseline, cut-over. What differs is the source mapping: Gmail to Exchange Online, Google Contacts and Calendars, Drive and Shared Drives to OneDrive and SharePoint, Google identity to Entra ID. We cover that path in our dedicated Google Workspace to Microsoft 365 guide.

Should we set up security before or after the migration?

Before. MFA, conditional access and a baseline malware and device-management policy should be in place as users start signing in, not bolted on later. Building the security baseline in from the outset avoids a window where new accounts are exposed and means Cyber Essentials controls are ready from day one.

PLANNING A MOVE?

A migration
that’s boring.

Book 30 minutes. We’ll scope your users, data and devices, map the cut-over, and give you a realistic timeline — so the only thing your team notices is that everything works.

TIMELINE
4–8 wk
CUT-OVER
1 window