Email migration is one of the most anxiety-inducing infrastructure changes you can make. Get it right and nobody notices — email continues to flow seamlessly. Get it wrong and emails are lost, deliverability tanks, and your business communication grinds to a halt. The stakes are high, but with proper planning and a methodical approach, you can migrate without losing a single email.
This guide provides a step-by-step migration plan that covers pre-migration preparation, the migration itself, and post-migration verification.
Pre-Migration Planning: 2-4 Weeks Before
Start by documenting your current email configuration completely. Record all email accounts, aliases, distribution groups, and forwarding rules. Export DNS records (MX, SPF, DKIM, DMARC, CNAME, TXT). Document any server-side rules, auto-responders, and custom configurations. Note your current email client settings (server addresses, ports, encryption) so you can update them during migration.
Choose your migration window — a period of low email traffic, typically a weekend or evening. Plan for the migration to complete within your maintenance window, but have a rollback plan in case something goes wrong. Notify your team about the upcoming migration, what to expect, and who to contact if they experience issues.
Setting Up the New Server
Configure your new email server completely before the migration. Create all user accounts, aliases, and groups. Configure SPF, DKIM, and DMARC for the new server (you may need to update SPF to include both old and new server IPs during the transition). Install and test SSL certificates. Configure spam filtering, antivirus, and any server-side rules. Send test emails to and from the new server using a test domain or temporary DNS entries to verify everything works.
Do not change your production DNS records until the new server is fully configured and tested. The new server should be able to receive and send email independently before you direct traffic to it.
Email Data Migration
Migrate existing email data using IMAP sync tools. imapsync is the gold standard for IMAP-to-IMAP migration — it copies all emails, folder structures, and flags from the old server to the new server. It handles interruptions gracefully and can be run multiple times to sync changes.
Run the initial sync well before the DNS cutover — migrating years of email can take hours or days depending on volume. Then run a final sync immediately before changing DNS records to capture any emails received between the initial sync and the cutover.
Verify the migration by comparing folder structures, email counts, and spot-checking specific emails on both servers. Automated tools can compare email counts per folder, but manual verification of important emails provides additional confidence.
DNS Cutover: The Critical Moment
The DNS cutover is when you change your MX records to point to the new server. This is the moment of truth. Before changing MX records, reduce the TTL on your MX records to 300 seconds (5 minutes) at least 48 hours in advance. This ensures the DNS change propagates quickly once you make it.
During the cutover, update MX records to point to the new server. Update SPF records to include the new server's IP and remove the old server's IP (or include both during the transition period). Monitor the new server for incoming email — you should see emails arriving within minutes. Keep the old server running and monitoring it for any emails that arrive due to DNS caching (some servers may continue sending to the old IP for up to 48 hours).
Post-Migration Verification
After the DNS cutover, verify email delivery in both directions. Send test emails from external accounts (Gmail, Outlook) to your domain and verify they arrive on the new server. Send test emails from your new server to external accounts and verify they are delivered (not spam-filtered). Check email headers for proper SPF, DKIM, and DMARC authentication. Monitor server logs for delivery errors or rejection messages.
Keep the old server running for at least 7 days after migration to catch any delayed deliveries. Configure forwarding from the old server to the new one so any emails that arrive at the old server are automatically forwarded. After 7 days with no traffic to the old server, you can safely decommission it.
Client Reconfiguration
Update email client settings on all user devices. If the server hostname changes, users need to update their incoming and outgoing server addresses. If you use auto-discovery (Autodiscover for Outlook, autoconfig for Thunderbird), configure it on the new server first so clients that re-detect settings will find the correct configuration automatically.
Provide clear, step-by-step instructions to your team for updating their email clients. Include screenshots for each major client (Outlook, Apple Mail, Thunderbird, mobile clients). Have IT support available during the transition for users who need help.
Common Migration Problems and Solutions
If emails are still arriving at the old server after the DNS change, DNS caching is the likely cause — wait for TTL expiration or contact the sending organization to flush their DNS cache. If outgoing emails from the new server are being rejected, check that the new server's IP has a proper PTR record and is not on any blacklists. If DKIM verification fails, verify that the DKIM public key in DNS matches the private key on the new server — this is a common issue when migrating between different email platforms.
ZeonEdge provides managed email migration services that handle every aspect of the migration process. Learn more about our email migration services.
Alex Thompson
CEO & Cloud Architecture Expert at ZeonEdge with 15+ years building enterprise infrastructure.