How to Migrate Email Accounts

The safe order for moving email to a new host

Create the same mailboxes on the new server, copy old mail over IMAP while both servers run, lower the MX TTL a day ahead, then switch MX and SPF and test from an outside account. Keep the old host online for 72 hours.

1. Create every mailbox on the new server with the same address, a quota at least as large as the old one, and the same aliases and forwarders.
2. Copy historical mail over IMAP while both servers are live. Run the sync twice; the second pass picks up mail that arrived during the first.
3. Compare folder counts and check the Sent folder before you touch DNS. A sync that missed a prefix is the usual cause of "my old mail is gone".
4. A day ahead, lower the TTL on the MX records to 300 seconds, so a mistake can be reversed in five minutes instead of a day.
5. On cutover day, change the MX records, the SPF include and the DKIM record together. Half a change sends legitimate mail to spam.
6. Send from an outside account and read the headers for spf=pass and dkim=pass. Then send from the new mailbox to that outside account.
7. Leave the old server running for 72 hours. Mail sent during propagation can still land there, and you want it copied, not bounced.

Flip MX before the mailboxes exist and new mail bounces. Cancel the old host on day one and the mail that arrived during propagation disappears. The rest of this page is the detail behind each step.

Step 1: create the same mailboxes on the new server

Every address must exist on the new server before MX points at it. In cPanel that is Email, then Email Accounts, then Create. Use the same local part, and set a quota that fits the old mailbox plus room to grow.

• Aliases and forwarders: recreate them now, because a missing alias silently bounces customer mail.
• Catch-all: only if you already ran one, and only after you have checked what it was collecting.
• Quota: a 2 GB mailbox copied into a 1 GB quota fails halfway, and the failure looks like a sync bug.
• Passwords: set them now so clients can be reconfigured without a second change later.

If you are also moving the website, do the mailbox work first. DNS changes for the site and for mail are separate records, and mixing them in one window makes a failure harder to read.

Step 2: copy old mail over IMAP

Copy historical mail while both servers are live, so folders, sent mail and read states arrive intact. Nothing here changes DNS, so a mistake costs time rather than deliverability.

• imapsync from a terminal, one mailbox at a time: imapsync --host1 mail.oldhost.com --user1 you@example.com --password1 OLDPASS --host2 mail.webji.in --user2 you@example.com --password2 NEWPASS --automap. Run it again after it finishes.
• Thunderbird with both accounts added over IMAP, dragging folders across. Fine for one or two mailboxes, slow beyond that.
• cPanel to cPanel: use the host's account transfer instead, which copies the mail directories wholesale and keeps folder names exact.

You know the copy worked when the folder list matches, the message counts are within a few of each other, and a search for an old invoice finds it on the new server. Differences usually come from a folder prefix the tool did not map.

Step 3: lower the TTL, then switch MX and SPF

Lower the TTL before you change anything. A record with a 24-hour TTL keeps sending mail to the old server for a day after you edit it, which is how a clean migration turns into a week of missing messages.

• In the DNS zone, set the TTL on the MX records to 300 seconds and save. Do this at least a day before the cutover.
• Copy the exact MX hostnames and priorities the new host publishes. A wrong priority sends mail to the backup path first.
• Replace the SPF include with the one the new host publishes in its mail settings, and add the DKIM TXT record it generated. Keep one SPF record, not two.
• Check with dig +short MX example.com from two networks, and confirm the SPF with dig +short TXT example.com.

DMARC stays as it is unless the reporting address changes. If you never published one, this is a good week to add a monitor-only record, but not on cutover day.

Step 4: test, then keep the old host for 72 hours

Send from an outside account such as Gmail to the new mailbox, then reply from the new mailbox. In Gmail, open the message, choose Show original, and read the authentication results for spf=pass and dkim=pass.

• Inbound: a message from outside lands in the inbox, not spam, and the headers show both checks passing.
• Outbound: the reply arrives, and the recipient sees the right display name and signature.
• Clients: phone, desktop and webmail all send through the new server, with the new SMTP hostname.
• Old host: still running, still accepting mail, still reachable by IMAP for the final delta sync.

After 72 hours, run the sync one last time, export a backup of the new mailboxes, then cancel the old account. That order means the last copy exists before anything is deleted.

Moving cPanel mail to Microsoft 365 or Google Workspace

Both platforms accept an IMAP migration from a cPanel mailbox, and both migrate mail only. Contacts, calendars and tasks need a separate export, so plan for that before the cutover rather than after.

Microsoft 365 requires the destination mailbox to exist before the migration starts, and IMAP does not carry contacts or calendar items. New mail sent to the old address after the migration is not copied, so the MX change is still yours to make.

Google Workspace uses the Admin console data import tool: connect the source over IMAP, map each address to a Workspace user, then start the import. Organisations with more than 20 users upload a CSV, one import covers up to 1,000 users, and a delta import picks up what arrived afterwards.

For either, the sequence on this page still applies: mailboxes first, copy second, DNS last. The console changes; the order does not. The Google Workspace and Microsoft 365 pages cover the mailbox plans.

What goes wrong after a mail cutover

Four failures cover most of the support tickets that follow a mail move. Each has one cause and one fix.

A fifth case looks like a failure but is not: mail sent to the old address during propagation lands on the old server, which is why it stays online for 72 hours and gets one last sync.

What WebJi® does for an email migration

WebJi® moves mailboxes, aliases and stored mail between cPanel accounts as part of its free migration service, subject to terms and approval. Send the domain, the mailbox list and the current host to support@webji.services and the team schedules the copy.

Business email hosting starts at ₹2,520 a year for five 5 GB mailboxes, before 18% GST, with IMAP and POP access, spam filtering and webmail. The 10 GB plan is ₹4,200 a year. If the domain itself is moving too, start with domain transfer so the DNS zone is in one place.

Support answers by email in Hindi and English 24/7, with an average first reply under 60 minutes. The office phone is not a support line, so send the migration request in writing.