Office 365 Migration Downtime: Will Your Email Go Down?

Every migration kickoff call includes the same question, usually within the first five minutes: "Will our email go down?" It's the right question. Email is the one system where an hour of silence gets the CEO involved. Here is the honest answer, from someone who has moved 1.4M+ users to Microsoft 365.

The direct answer: done right, users keep sending and receiving throughout

A properly planned Office 365 migration has no email blackout. Users keep working in the old system while 95% of their data copies to Microsoft 365 in the background over days or weeks. They send and receive normally the entire time. The only real risk window is the DNS cutover — the moment MX records point to Microsoft 365 instead of the old server — and even that window is not what people fear it is.

Here is the part most IT managers don't know, and it changes everything: email does not vanish during a cutover. SMTP — the protocol every mail server on earth uses — was designed in an era of unreliable networks. When a sending server can't deliver a message, it does not bounce it. It queues the message and retries, typically for 24 to 48 hours, before giving up. During a cutover, both mailboxes exist. Mail that arrives at the old server before the DNS change propagates lands in a mailbox you still control. Mail that arrives after lands in Microsoft 365. Mail caught in between queues at the sender and arrives minutes later. Delayed, occasionally. Lost, no.

Across 1.4M+ migrated users we have recorded zero data loss, verified with SHA-256 checksums on migrated content, and a 99.8% first-pass success rate. That record exists because the physics of SMTP are on your side — if you don't fight them.

Why mail doesn't get lost during DNS cutover

Three mechanisms protect you, and a competent migration plan uses all of them deliberately.

1. MX TTL is lowered in advance. Your MX record carries a TTL — a cache lifetime that tells the world's DNS resolvers how long to remember the answer. If it's set to 24 hours (common on records nobody has touched in years), some sending servers will keep delivering to the old address for a full day after you change it. The fix is administrative: 48–72 hours before cutover, we drop the TTL to 300 seconds. When we flip the record, the internet converges on the new answer in minutes, not a day.

2. Sending servers retry. Even in the worst case — a resolver with a stale cache pointing at a server that stops accepting mail — the sender's server queues the message and retries on a backoff schedule for 24–48 hours. The sender sees nothing. The message arrives when resolution catches up. This is not a migration trick; it is how SMTP has worked since 1982.

3. Both mailboxes exist during the transition. In a staged or cutover migration, the source mailbox is not deleted at MX flip. Anything that lands there during the propagation tail is caught by a final delta sync and copied across. Nothing falls between the two systems because there is no gap between the two systems.

What CAN actually go down — and when

Now the honest part. Mail flow is the thing people fear and the thing least likely to break. The outages that actually generate Monday-morning tickets are client-side, and they are predictable:

Notice what's on that list: not one item is "email stopped arriving." The server-side mail flow is the hardened, well-engineered part. The client-side experience — profiles, phones, delegates, Autodiscover — is where DIY migrations bleed. Each item is preventable with an hour of preparation: export the full permission map before you start, pre-write the mobile re-add instructions, clear the old Autodiscover records at cutover, and staff for the Monday profile wave. We cover the full failure catalog in Office 365 migration issues and how to fix them.

The 72-hour horror story

This is the migration we get called into after it has already happened, two or three times a year, and it always follows the same script.

An internal admin flips the MX record on a Tuesday afternoon. The TTL was 24 hours and nobody checked it, so for a full day mail splits unpredictably between two servers depending on which resolver a sender happens to use. SPF wasn't updated to include Microsoft's senders, so outbound mail from the new tenant starts landing in recipients' spam folders — and nobody knows, because the sender sees a successful send. DKIM was never enabled on the new tenant. Autodiscover still points at the old server, so half the Outlook clients reconnect to a mailbox that is no longer receiving new mail, and users sit in front of an inbox that looks fine and is quietly a day stale.

Wednesday is spent diagnosing symptoms that look unrelated — "some customers say we're not replying," "my Outlook is fine but my phone isn't." Thursday is spent fixing DNS and waiting out the old TTL. By the time mail flow, SPF, DKIM, and Autodiscover are all correct and propagated, the business has taken roughly 72 hours of degraded or broken email, mid-week, at full staff load. Nothing was lost — SMTP retries saw to that — but from the business's point of view, email was down for three days.

How we make it boring

A good migration is an anticlimax. Ours follow the same shape every time:

1. Pre-stage 95% of the data. Mail, calendars, and contacts sync in the background for days or weeks while users work normally. By cutover night, only a thin delta remains.
2. Pilot first. 10–20 users move a week ahead. Every client-side surprise — a profile quirk, a permission edge case, a stubborn phone model — surfaces on the pilot group, not the whole company.
3. Cut over on a weekend, in a 2–4 hour window. TTL was lowered days earlier. MX, SPF, DKIM, and Autodiscover change together, get verified together, and the final delta sync runs while nobody is emailing.
4. Rollback signed off before we start. The source environment stays intact and reachable. If a verification check fails inside the window, we point DNS back and users never know a cutover was attempted. We have the plan in writing before we touch anything.
5. Hypercare Monday morning. A dedicated team is on deck for the profile wave and the phone re-adds, and stays on for 30 days after.

The result, from the user's chair: they come in Monday, Outlook asks them to sign in with the credentials they were given, and everything is where they left it. A new password prompt. That is the entire visible footprint of a migration done right — and it is exactly what our Microsoft 365 migration services are built to deliver. For how the calendar side of this plays out end to end, see how long an Office 365 migration takes.

Questions to ask any migration provider about downtime

If you're evaluating providers — including us — these five questions separate teams who have done this at scale from teams who will learn on your tenant:

1. "What's your MX TTL procedure, and when do you lower it?" The right answer names a number (300 seconds) and a lead time (48–72 hours before cutover). A provider who hesitates here has not been burned yet, which means you'll be the lesson.
2. "How do you migrate shared mailbox and delegate permissions?" Listen for "we export the permission map before migration and re-apply it post-cutover." If they say permissions come across automatically, they haven't done this — they don't.
3. "What exactly happens to a message sent during the cutover window?" The correct answer explains SMTP retry behavior and the final delta sync. A vague "there might be brief delays" tells you they don't understand the mechanism they're promising to manage.
4. "Show me your rollback plan — before the project starts." A real provider has a written, tested rollback that keeps the source intact until you sign off. If rollback is "we'd figure it out," the meeting is over.
5. "Who is on deck Monday morning, and for how long after?" The cutover weekend is the easy part. The Monday profile-and-mobile wave is where users form their opinion of the whole project. Ask for named hypercare coverage and a duration — ours is 30 days.

Any provider who answers all five crisply has earned a shortlist spot. Any provider who bristles at being asked has answered a sixth question you didn't have to ask.