Keeping Email Flowing During a Migration

Email is the part of a migration people worry about most, because nobody wants to lose a message. The good news: with the right order of steps, your email moves across and keeps flowing. Here’s how it works and how to avoid a gap.

Your mailboxes and messages transfer

A full cPanel migration brings your email accounts, their passwords, and the messages stored in them across to iWebVault. So your inbox history arrives intact.

Delivery is controlled by MX records

Where new mail is delivered depends on your domain’s MX records. Until DNS points to iWebVault, new mail still goes to your old host. After cutover, it comes here. The brief window during propagation is where care is needed.

Avoiding a mail gap

1. Migrate the account (mailboxes and existing mail come across)
2. Switch DNS so MX points to iWebVault
3. During propagation, check mail on both old and new servers
4. Once propagation completes, all new mail arrives on iWebVault

If you use external email

If your email is on Google Workspace or Microsoft 365, it’s not in cPanel at all — it’s defined by your MX records. When you migrate, make sure those external MX records are preserved so mail keeps going to your provider, not to iWebVault.

How mail delivery is actually decided

Every time someone sends you an email, their mail server looks up your domain’s MX records to decide where to deliver it. Those MX records are the single control point for mail routing. Before you switch DNS, they point at your old host; after, they point at iWebVault (or your external provider). Understanding this makes the whole continuity picture clear.

The propagation window for mail

During DNS propagation, some sending servers will have the old MX cached and some the new — so for a short window, mail can land at either your old host or iWebVault. This is why you keep the old account live and check both inboxes for a day or two after cutover. No mail is lost; it’s just briefly split across two places until propagation settles.

Migrating stored mail

Your existing mailboxes and the messages in them transfer as part of the cPanel migration, so your inbox history is on iWebVault before you cut over. For very active mailboxes, the few messages that arrive between the backup and the cutover are the ones to reconcile — checking both servers during the window catches them.

External email providers

If your email is on Google Workspace or Microsoft 365, your mail never touched cPanel — it’s defined entirely by your MX records pointing at Google or Microsoft. The critical step when migrating is to preserve those exact MX records so that after cutover, mail still flows to your provider and not to iWebVault. We’ll confirm those records with you before you switch.

Email clients and devices

If you host mail on iWebVault, your customers’ email apps may need updated incoming/outgoing server settings (the new server hostname) once mail moves here. Webmail works immediately. For desktop and phone clients, supply the new mail server settings so they reconnect smoothly after cutover.

A safe email cutover sequence

1. Migrate the account so mailboxes and stored mail are on iWebVault
2. Confirm mailboxes are present in the new cPanel
3. Switch DNS / MX as planned
4. Check both old and new inboxes during propagation
5. Update device mail settings if hosting mail on iWebVault
6. Retire the old account only after a clean day of mail on iWebVault

MX records are the master switch

It bears repeating because it’s the crux of email continuity: your domain’s MX records decide where every incoming message is delivered. Nothing else routes your mail. Before cutover they point at your old host; after, at iWebVault or your external provider. Get the MX records right and email continuity takes care of itself; overlook them and mail goes astray. Everything else in this article serves that one principle.

The propagation window, handled

During DNS propagation, some sending servers hold the old MX and some the new, so for a short window mail can arrive at either your old host or iWebVault. This isn’t loss — it’s a temporary split. Keeping the old account live and checking both inboxes for a day or two after cutover ensures you see every message regardless of which server it landed on, until propagation settles and everything arrives on iWebVault.

Stored mail versus new mail

Distinguish two things: your existing stored messages, and newly arriving mail. Stored messages transfer as part of the cPanel migration, so your inbox history is on iWebVault before cutover. New mail follows the MX records. The only messages needing reconciliation are those that arrive in the gap between the backup and the cutover — which checking both servers during the window catches.

Device and client settings

If you host mail on iWebVault, webmail works immediately, but desktop and phone email apps may need updated server settings — the new mail server hostname for incoming and outgoing mail. Supply those settings to your users (or yourself) so clients reconnect cleanly after cutover. This step doesn’t apply if you use external email, where the provider’s settings are unchanged.

A safe, ordered email cutover

1. Migrate the account so mailboxes and stored mail are on iWebVault
2. Confirm the mailboxes are present in the new cPanel
3. For external email, confirm the correct MX records are ready to keep
4. Switch DNS / MX as planned during a quiet window
5. Check both old and new inboxes throughout propagation
6. Update device mail settings if hosting mail on iWebVault
7. Retire the old account only after a clean day of mail on iWebVault

What’s next

• Pointing Your Domain to iWebVault
• DNS Propagation — What to Expect
• What Actually Transfers in a Migration

Still stuck? Our team can run or finish the migration for you — open a support ticket and we’ll take it from there.