Email Migration: Guide Without Losing Messages

When Do You Need Email Migration?

Email migration is a sensitive process that requires careful planning. Losing a single important message could mean losing a contract or delaying a government transaction. Therefore, advance planning and testing are not optional.

Common reasons for email migration:

• Moving from one hosting provider to another
• Upgrading from shared hosting to a dedicated server
• Moving from an external email service (such as Google Workspace) to a private server
• Changing the domain name
• Consolidating email after a company merger

Migration Phases

Phase 1: Planning and Inventory

Before touching any settings, document the current state completely:

1. List of all email accounts with mailbox sizes
2. Current DNS records (MX, SPF, DKIM, DMARC, A records)
3. Email client settings for each user
4. Distribution lists and forwarding rules (forwarding rules, aliases)
5. Filters and rules configured on each account

Create a table with this information:

Account	Mailbox Size	Forwarding	Protocol Used	Notes
info@domain.com	2.5 GB	Yes	IMAP	Primary account
ahmed@domain.com	5.1 GB	No	IMAP	Large mailbox
sales@domain.com	800 MB	Yes (3 addresses)	IMAP	Distribution list

Phase 2: Prepare the New Server

Set up the new server completely before starting migration:

1. Create all email accounts on the new server
2. Configure forwarding rules and distribution lists
3. Install the SSL certificate
4. Configure SPF and DKIM records on the new server
5. Test sending and receiving internally before changing DNS

Phase 3: Transfer Messages

Several methods exist for transferring messages from the old server to the new one:

Method 1: imapsync

An open-source tool specialized in migrating email between IMAP servers. It transfers everything: messages, folders, status (read/unread), and flags.

• Suitable for large mailbox transfers
• Supports resumption if the connection drops
• Can run multiple times (transfers only changes)

Method 2: Backup and Restore

If both servers use cPanel, the built-in backup and restore feature can be used:

1. Create a full backup from the old cPanel
2. Transfer the backup file to the new server
3. Restore the backup from WHM on the new server

Method 3: Manual Transfer via Email Client

For small mailboxes, both accounts can be connected in a single email client (such as Thunderbird) and messages dragged from old to new manually.

Phase 4: DNS Switchover

This is the critical moment. After confirming all messages have been transferred:

1. Reduce the TTL for MX records to 300 seconds (24-48 hours before switchover)
2. Change MX records to point to the new server
3. Update SPF and DKIM records
4. Monitor email flow on both servers (old and new) for 24-48 hours

Phase 5: Post-Migration

• Run imapsync one final time to transfer any messages that arrived at the old server during DNS propagation
• Update email client settings for all users
• Test sending and receiving from every account
• Verify SPF, DKIM, and DMARC are working on the new server
• Keep the old server running for one week as a safety net

Common Migration Mistakes

• Forgetting to reduce TTL: Causes DNS propagation delays of hours or days
• Deleting the old server immediately: Messages may continue arriving at the old server after DNS changes
• Not testing email before switchover: Configuration problems appear after it is too late
• Neglecting distribution lists: Email arrives at the account but does not forward to required addresses

Migration with CLOUD

CLOUD (cloud.net.sa) does not migrate data on your behalf because responsibility for custom systems stays with your technical team. However, full support is provided to your team: guidance sessions, configuration reviews, and troubleshooting. Servers come fully equipped with cPanel and pre-configured SPF and DKIM, cutting the work in half.

---

Get Started

Want to try it yourself? Choose the right hosting plan or build your custom server with the specs you need.