A "done-for-you" email migration should mean exactly that — your team keeps working while someone else handles the technical cutover — but knowing what the process actually involves helps you evaluate whether a provider is doing it properly or cutting corners.

Phase 1: Discovery and Planning

Before touching anything, a proper migration starts by cataloguing what exists: how many mailboxes, how much historical mail per mailbox, any shared mailboxes or aliases, and any mail-dependent integrations (a CRM, an invoicing tool) that need to keep working through the switch. Skipping this step is how migrations discover surprises mid-process instead of before starting.

Phase 2: Parallel Setup, No Disruption Yet

New accounts get created on the destination platform while the old system keeps running entirely unaffected — this is the phase where DNS hasn't changed yet, so nothing your team experiences day-to-day is different. Testing happens here: sending and receiving test mail on the new accounts before anyone's real mail depends on them.

Phase 3: Historical Mail Migration

An IMAP-based sync pulls existing mail from the old mailboxes into the new ones, which can take anywhere from minutes to many hours depending on total mail volume — this runs in the background and, done correctly, doesn't require the old system to go offline during the transfer.

Phase 4: The Actual Cutover

MX records switch, redirecting new incoming mail to the new platform. This is the only moment with genuine time-sensitivity: DNS propagation typically completes within a few hours, during which some incoming mail could theoretically arrive at either the old or new system depending on which DNS server a given sender's mail server checks. A well-planned cutover schedules this for a low-traffic window (evening or weekend) specifically to minimize how much mail lands in that transition window.

Phase 5: Verification

Confirming every migrated mailbox actually received its historical mail intact, testing send and receive from each account, and checking that any mail-dependent third-party integrations still function — this step is what separates a migration that's actually finished from one that merely looks finished until the first thing breaks a week later.

What a Good Provider Tells You in Advance

  • The specific cutover date and time window, communicated early enough to tell your team.
  • Whether any brief window of missed mail is possible, and how they minimize it.
  • What happens to the old mail system after cutover (kept briefly as a fallback, or decommissioned immediately).

A migration that goes well is, by design, close to boring for everyone except the person running it — that quiet, uneventful outcome is the actual goal, not a lucky accident.

Questions Worth Asking a Migration Provider Upfront

Before committing, ask specifically: will our old system stay accessible as a fallback during the transition, or does the plan require decommissioning it immediately? What is the specific cutover time window, and can it be scheduled outside business hours? How will we know the migration succeeded before old accounts are removed? Clear, specific answers to these three questions distinguish a provider who has run this process many times from one improvising it for the first time on your account.