Switching your organization’s business email provider is notoriously stressful. If a customer sends an invoice or purchase order during the changeover and receives a 550 bounce or dropped socket, business halts. Here is the exact phased playbook WigoSend uses to guarantee zero lost mail.
The live email migration paradox#
Every email transition involves two parallel streams of state: incoming mail delivery (governed by the DNS MX record) and historical mail storage (synced via IMAP or API connectors). The biggest mistake IT teams make is flipping the MX record first and hoping to sync gigabytes of historical mail after the fact.
When you flip MX prematurely, users log in to empty mailboxes while historical messages take 18 to 36 hours to ingest. Employees panic, search queries fail, and business communication breaks down.
WigoSend's migration engine solves this with a three-stage phased approach: Warm Background Pre-Sync, Dual-Delivery MX Flip, and Delta Ingestion.
“Never make MX cutover the start of your migration. MX cutover should be the ceremonial ribbon-cutting after 98% of the data already lives safely at the destination.”
Step 1: TTL reduction and the pre-sync phase#
At least 48 to 72 hours before the planned cutover, reduce the Time-To-Live (TTL) on your domain's MX and SPF records to 300 seconds (5 minutes). This ensures that recursive DNS resolvers around the globe purge stale caches quickly once the real switch occurs.
Simultaneously, initiate WigoSend's automated background IMAP sync. Our migration workers authenticate to the legacy server (Google Workspace, Microsoft 365, or cPanel) and replicate past folders, attachments, and flags directly into the pre-provisioned WigoSend mailboxes.
Non-destructive replication
WigoSend's IMAP sync engine operates in read-only mode with fetch batching. It never touches, archives, or flags original messages in your source mailbox.
; Step 1: Reduce TTL to 300s 48h before cutover
@ 300 IN MX 10 smtp.google.com.
@ 300 IN TXT "v=spf1 include:_spf.google.com ~all"Step 2: Dual delivery & the MX cutover#
Once initial synchronization reaches 100%, update your DNS zone with WigoSend's primary MX record. Because your TTL was already reduced to 300 seconds, external mail transfer agents (MTAs) start routing new incoming messages to WigoSend within minutes.
During this window, any trailing messages delivered to the old server due to slow upstream DNS resolvers are caught by WigoSend's automated delta polling process.
; Step 2: Point MX to WigoSend high-availability endpoints
@ 300 IN MX 10 mx1.wigosend.com.
@ 300 IN MX 20 mx2.wigosend.com.
@ 300 IN TXT "v=spf1 include:_spf.wigosend.com ~all"Step 3: Delta catch-up & cutover confirmation#
Our migration daemon runs continuous delta sync passes every 15 minutes, comparing internal UID sets against the legacy server. It fetches any email that slipped into the old mailbox between the initial sync and the global DNS propagation cutoff.
Once zero new items are observed across 3 consecutive cycles and 24 hours have elapsed, the legacy subscription can be safely retired with absolute confidence.
| Migration Stage | Incoming Traffic Target | User Interruption | Risk Level |
|---|---|---|---|
| Phase 1: Pre-sync | Legacy Provider | Zero (background ingest) | None |
| Phase 2: MX Cutover | WigoSend (propagating) | Zero (both servers open) | Minimal |
| Phase 3: Delta sync | WigoSend primary | Zero (reconciling legacy mail) | Zero |
| Phase 4: Completion | WigoSend 100% | Complete modern workspace | Zero |
Handling DNS propagation latencies#
Even with short TTLs, some misconfigured ISP recursive resolvers ignore TTL values under 1 hour. Because WigoSend keeps the delta synchronization active for up to 7 days post-cutover, those trailing deliveries are automatically discovered and moved to the user's active inbox.
Summary: The five migration rules#
1. Pre-provision every mailbox and alias before touching DNS.
2. Lower TTL to 300 seconds at least 48 hours in advance.
3. Sync 100% of historical mail into the destination prior to cutover.
4. Update MX and SPF records simultaneously.
5. Run delta verification sweeps until the old server has received zero mail for 24 continuous hours.
Ready to plan your cutover? Use our interactive Migration Engine and Readiness Checklist, explore WigoSend Mail capacity plans, or request free assisted concierge migration for enterprise teams.
Published by Alex Mwangi
Founding Engineer & Systems Architect at WigoSend. Specializing in high-reliability email routing, data sovereignty, and communication infrastructure.
Engineering & protocol notes delivered to your inbox.
No marketing spam. Only technical deep-dives on email protocols, DNS, and platform updates once or twice a month.