A Zero-Downtime Microsoft 365 Migration Playbook

A Microsoft 365 migration sounds risky because the failure mode is so visible: a morning where nobody can send email. The good news is that downtime is almost entirely a function of preparation. Do the unglamorous staging work, and cutover becomes a non-event.

Phase 1: Inventory everything

Before any data moves, you need a clear picture of what exists:

• Mailboxes, their sizes, and shared or delegate access.
• Distribution lists, shared mailboxes and resource calendars.
• Files and where they live today, plus who owns and shares them.
• Identity, how people sign in now, and what they will use after.

Surprises discovered mid-cutover are what cause outages. Surprises discovered during inventory are just tasks.

Phase 2: Plan identity and DNS first

Identity decides the user experience. If you are introducing single sign-on, sort that out early, see our guides on rolling out Okta SSO and connecting Okta to Microsoft 365.

DNS is where migrations most often go wrong. Your MX, SPF, DKIM and DMARC records control whether mail is delivered and trusted. Getting them right is so important we wrote a dedicated guide to email deliverability. Plan the records before cutover; do not improvise them on the day.

Phase 3: Stage the data ahead of time

This is the secret to zero downtime. Copy the bulk of mailbox and file data into Microsoft 365 while the old system is still live. Users keep working; the migration runs quietly in the background. When most data is already across, the final sync is small and fast.

Cutover should move a day of email, not a decade of it. Everything else is pre-staged.

Phase 4: Pilot, then migrate in waves

Never move everyone at once. Start with a small pilot group, ideally including a few patient, vocal users and someone from IT. Fix what the pilot surfaces. Then migrate the rest in waves by team or department, so any issue affects a handful of people, not the whole company.

Phase 5: Cut over and verify

On cutover, you complete the final data sync and update DNS to point mail at Microsoft 365. Then verify deliberately:

• Send and receive test mail, internal and external.
• Confirm SPF, DKIM and DMARC are passing.
• Check shared mailboxes, calendars and mobile devices.
• Keep the old system reachable for a short overlap as a safety net.

The mistakes that cause downtime

In our experience, nearly every painful migration traces back to one of these: skipping inventory, leaving DNS to the last minute, trying a big-bang cutover, or not piloting first. Avoid those four and “zero downtime” stops being a marketing phrase and becomes the normal outcome.

Our cloud and infrastructure team runs Microsoft 365 migrations as embedded pods, with a rollback plan at every step. If you are planning a move, book a free working session and we will map your cutover.