How to Migrate Email Accounts Between Hosts

How Email Migration Goes Wrong (and the Safe Order)

In the right order — migrations fail by reordering, not by tooling:

1. Recreate every mailbox on the new host — same addresses and passwords.
2. IMAP-sync historical mail while both servers are live.
3. Lower the TTL on MX records to 300 seconds, a day ahead.
4. Cut MX records over to the new host.
5. Test sending and receiving from outside accounts.
6. Reconfigure or re-login clients, then watch the old server for 72 hours.

Flip MX first and new mail bounces at a host where mailboxes do not exist yet. Cancel the old host early and years of archived mail vanish. Every step below follows this spine, and WebJi®'s business email team runs it free with hosting plans.

Step 1: Recreate Accounts on the New Host

Recreate Accounts on the New Host. Do this on one site or a staging copy first, then check the public URL in a private window so cache does not hide the result. Stop if the page errors, and email support@webji.services with the step name and the exact error before you repeat it on every account. WebJi® support mail is staffed 24/7 in Hindi and English; the phone line +91 141 4941811 is business hours only.

Step 2: Sync Old Mail via IMAP (Tools and Steps)

Copy historical mail while both servers are live, so folders, sent mail and read states match.

• imapsync — the respected command-line tool, syncing folder by folder. Run it twice; the second pass copies only the deltas. Shape: imapsync --host1 old.yourdomain.com --user1 you@yourdomain.com --password1 oldpass --host2 mail.yourdomain.com --user2 you@yourdomain.com --password2 newpass.

• Thunderbird — connect both accounts via IMAP and drag folders across. Fine for a few mailboxes.

• cPanel-to-cPanel — skip per-mailbox sync entirely; a full account transfer carries the mail directories wholesale.

For many users, your host's migration team beats any tool. Low TTL pre-change matters in the next step, not this one.

Step 3: Lower TTL and Cut Over MX Records

The cutover, sequenced to be invisible:

1. A day before: lower the TTL on the MX records (and the SPF TXT, if it will change) to 300 seconds so resolver caches expire fast.
2. Cutover day: recreate the MX records pointing at the new host, and update SPF to authorise the new server's sending.
3. Verify with dig MX yourdomain.com from a couple of networks, and watch propagation on whatsmydns.net.

Because resolvers cache at most five minutes after the TTL drop, the overlap where some senders hit the old server and some the new is brief — and both servers accept mail during it, which is exactly why the old host stays online.

Moving the website and mail together? The free migration (subject to terms and approval) service covers both in one sequence.

Step 4: Test Sending and Receiving

Test Sending and Receiving. Do this on one site or a staging copy first, then check the public URL in a private window so cache does not hide the result. Stop if the page errors, and email support@webji.services with the step name and the exact error before you repeat it on every account. WebJi® support mail is staffed 24/7 in Hindi and English; the phone line +91 141 4941811 is business hours only.

Migrating to Google Workspace or Microsoft 365

Migrating to Google Workspace or Microsoft 365. Do the change this heading names on one site first, then check it in a private browser window or in the mail client, depending on the topic. Change one setting at a time, and undo it if the result is wrong before you try the next. If you want the Jaipur desk to look with you, email support@webji.services — that mailbox is staffed 24/7 in Hindi and English. Phone +91 141 4941811 is business hours only.

WebJi®'s Free Email Migration Option

Free migration is offered subject to terms and approval. It is not an unattended button, and it is not a promise for every custom stack. Open a ticket with the current host login or a full backup, keep the old host online until you have checked the copy, and only then change DNS.