How to Move Email from cPanel Hosting to Google Workspace

Moving email from cPanel hosting to Google Workspace is a sequence-sensitive operation. Create the Workspace accounts first, pull existing messages across via IMAP before the cutover, then switch the MX records and disable local mail delivery in cPanel so the old server stops intercepting new mail. Getting the order wrong — flipping MX before the import is underway — is the most common cause of a messy migration.

This guide covers the full cutover: the IMAP import, the DNS changes, the cPanel step that most tutorials skip, a rollback path if something goes wrong, and what differs depending on your hosting panel or registrar.

The short answer#

The correct sequence is: create Google Workspace users, run the Data Migration Service or a third-party IMAP importer to pull existing messages, lower your domain TTL to 300 seconds the day before, update MX records to Google's mail servers, wait for propagation, then open cPanel Email Routing and switch from Local Mail Exchanger to Remote Mail Exchanger.

Step six is the one tutorials most often omit. Even after your MX records point to Google, cPanel can still catch inbound mail locally if the Email Routing setting is left on automatic or local. Mail quietly accumulates on the old server, never reaching Workspace, until the setting is corrected. This is the step almost everyone forgets — and it is the one that produces the most confusing failure mode, because everything else looks right.

Before you start#

Gather these before touching anything. Migrations stall most often because a credential or access detail is missing mid-step, which is exactly the wrong moment to be hunting through dashboards.

• Google Workspace Admin Console access — you need to create users and run the Data Migration Service. Domain verification is required if the domain is not already added to Workspace.
• cPanel access at the hosting account level — you need Email Routing to disable local delivery, and for the IMAP migration source, the password for each mailbox or an admin-level IMAP credential.
• Domain DNS access — at your registrar or a DNS host such as Cloudflare. You will edit MX records and optionally lower TTLs before the cutover.
• A complete list of every cPanel mailbox being moved, with the current IMAP password for each account. The Data Migration Service authenticates as each individual user to pull their mail.
• At least two hours of buffer around the DNS change. Do not schedule the MX cutover at the end of a business day when you cannot monitor it.
• An external email address (outside your domain) to send test messages from once the MX records are live.

Steps: the full cutover#

Work through these in order. Do not skip step one and do not update the MX records until the import is already running and has pulled the bulk of the existing messages.

1. 1

   Create Google Workspace user accounts

   In the Google Admin Console, go to Directory then Users and add every person who needs a Workspace account. Each user's primary address must exactly match the address they currently have on cPanel — for example [email protected]. For teams larger than a few people, the bulk user CSV upload is significantly faster than adding accounts one at a time. Assign licences before proceeding. Users do not need to log in yet.

2. 2

   Lower your domain TTL

   At your DNS host, find the existing MX records and lower their TTL to 300 seconds (5 minutes). This step is optional but pays off immediately during rollback or in the event of a mistake: a low TTL means DNS changes propagate within minutes rather than hours. If the TTL is currently 86400 (one day), lower it now and then wait for that original TTL to expire before continuing — resolvers that already cached the old answer keep it until the TTL they received runs out.

3. 3

   Start the Data Migration Service import

   In the Admin Console, go to Account then Data Migration. Select Email as the migration type and IMAP as the source. Enter your cPanel server's IMAP hostname — typically the same as your hosting server's address, or mail.yourdomain.com — on port 993 with SSL. Provide the cPanel mailbox credentials for the first user and map that mailbox to the corresponding Workspace account. Repeat for each mailbox or upload a CSV for bulk configuration. Start the migration. It runs in the background and can take hours for large mailboxes. Do not wait for it to finish before moving on — start the DNS changes once it has pulled most of the historical messages.

4. 4

   Update MX records to Google

   Delete your existing MX records, then add Google's five mail server entries. Set ASPMX.L.GOOGLE.COM at priority 1. Set ALT1.ASPMX.L.GOOGLE.COM and ALT2.ASPMX.L.GOOGLE.COM both at priority 5. Set ALT3.ASPMX.L.GOOGLE.COM and ALT4.ASPMX.L.GOOGLE.COM both at priority 10. Save the changes. With the TTL lowered in step two, most resolvers will pick up the new records within 15 minutes.

5. 5

   Disable local mail delivery in cPanel

   Log in to cPanel for your domain, open the Email section and select Email Routing. If the setting reads Automatically Detect Configuration or Local Mail Exchanger, change it to Remote Mail Exchanger. This tells cPanel to stop intercepting inbound mail and let it pass through to the external mail server — in this case Google. Save the setting. Without this change, cPanel continues to accept and store mail for your domain locally even though the MX records now point to Google's servers.

6. 6

   Verify delivery end-to-end

   Send a test message to an address on your domain from an external account that is outside your domain. Confirm the message arrives in Gmail — in the Google Workspace inbox, not in cPanel webmail. Open the message headers and confirm the mail passed through Google's servers (look for Received: from aspmx.l.google.com or similar). Let the Data Migration Service complete its remaining import passes. Once all mailboxes show a migration complete status, the cutover is done.

How the steps differ by hosting panel#

The Google Workspace side of this migration is identical regardless of where the old email is hosted. What changes is where to find the Email Routing equivalent and how the IMAP source connection is addressed. The table below covers the panels most commonly encountered in this migration.

What to do when it doesn't work#

Most cPanel-to-Workspace migration failures map to one of five causes. Before changing anything, check the actual state of both the MX records (using a public DNS lookup tool) and the Email Routing setting in cPanel — they can disagree with each other in ways that are not obvious at a glance.

A faster way to manage the inbox after migration#

The migration is a one-time job. Once your domain's mail flows into Google Workspace, the ongoing work — sorting, triaging, following up, drafting replies across a newly populated inbox — is what actually consumes time. A Workspace inbox can be just as overwhelming as a cPanel one, and migrations often surface a backlog of messages that need immediate attention.

AI Emaily connects to Google Workspace and Gmail accounts and brings AI-powered triage, draft generation, and Copilot mode to the inbox you have just moved into. In Copilot mode the agent suggests actions and drafts replies, but nothing sends without your approval. It also connects to standard IMAP accounts, so if you are running a phased migration with some mailboxes still on the old host, both can be managed in one place. We build AI Emaily, and it comes with a 7-day free trial on the Pro and Autopilot plans.