Migrate Bluehost to Gmail: cPanel to Google Workspace Plan

Bluehost email is the legacy in a lot of small-business setups: it came with the hosting, nobody thought hard about it, and now the team wants Google Calendar, Meet, and Drive next to their inbox. Moving the mail itself is the easy part. The trap is that Bluehost is cPanel underneath, the MX record is split between a public DNS view and an internal "Email Routing" setting, and Google's own Data Migration Service does not handle either of those well. This guide walks the actual operational path, including the cPanel-specific landmines.

What you keep and what you don't#

Over IMAP you move mail and folder hierarchy. Specifically:

• Every message, including read/unread state
• Folder structure, with one folder becoming one Gmail label
• Flagged or starred messages
• Sent mail and drafts (assuming the IONOS-style folder naming, which Bluehost respects)

What you do not move over IMAP and need to handle separately:

• Contacts — export per-user from Bluehost webmail as vCard, import into Google Contacts
• Filter rules — recreate in Gmail
• Forwarders — recreate as Google Workspace aliases or groups
• Autoresponders — recreate in Gmail's vacation responder
• Webmail "address book" entries — same as contacts

Inventory all of these from cPanel before any data movement. Skipping the forwarders specifically is the single most common cause of bounced mail after MX cutover.

Bluehost specifics that change the plan#

Bluehost is not a mail platform; it is shared cPanel hosting with email accounts as a feature. That has three practical effects:

1. IMAP throttling is per shared IP, so if your domain shares a server with someone running heavy mail flows, you compete with them for connection slots.
2. The MX record has two places to set it: public DNS and the internal "Email Routing" setting. Both must agree.
3. Mailbox passwords are set per-account in cPanel, not federated with any other identity. You set them, they live in cPanel, that's the only place they exist.

This guide assumes a standard Bluehost cPanel layout. Some legacy Bluehost accounts ride on HostMonster servers or older shared hosts; the panels look slightly different but the steps are identical.

Provisioning Google Workspace#

In the Workspace admin console:

1. Verify your domain. Google supplies a TXT record. Add it under cPanel, Domains, DNS Zone Editor. Verification usually completes within an hour.
2. Buy seats. Buy one extra for the catch-all and any service mailbox.
3. Create each user. Match the primary email exactly to the Bluehost source.
4. Create Google Groups for any Bluehost mailing lists or forwarders that send to multiple recipients.
5. Set up Google Workspace aliases that mirror Bluehost aliases.

For IMAP authentication into Gmail during the migration, you have two viable options:

• Per-user app passwords with IMAP enabled in Gmail settings for each user. Tedious for more than 10 users.
• OAuth with service account and domain-wide delegation. Configure once in Google Cloud Console, authorise the migration scope, and the tool impersonates each user during the copy. This is the right choice for any non-trivial migration.

The migration plan#

1. Lower MX TTL early

   In cPanel, Domains, DNS Zone Editor, edit the MX record. Drop TTL to 300 seconds. Save. Wait at least 24 hours so resolvers update.

2. Reset Bluehost mailbox passwords

   From cPanel, Email Accounts, set or reset each mailbox password. You need these to authenticate from the migration tool against Bluehost IMAP. Store them somewhere your tool can read at run time.

3. Pre-stage the bulk IMAP copy

   Start the Bluehost-to-Gmail migration. Users keep working on Bluehost. Expect 1 to 2 GB per hour throughput with around five concurrent connections per mailbox; pushing higher trips Bluehost's throttling.

4. Send the user comms

   Two days out, send a short note: when the change is happening, that their address stays the same, that historical mail will already be in the new mailbox, and which mail client setup steps they'll need on cutover day.

5. Flip the public MX record

   In cPanel, Domains, DNS Zone Editor, replace existing MX with Google's five hosts at their respective priorities:

   • ASPMX.L.GOOGLE.COM priority 1
   • ALT1.ASPMX.L.GOOGLE.COM priority 5
   • ALT2.ASPMX.L.GOOGLE.COM priority 5
   • ALT3.ASPMX.L.GOOGLE.COM priority 10
   • ALT4.ASPMX.L.GOOGLE.COM priority 10

   Save.

6. Change Email Routing to Remote

   This is the Bluehost-specific gotcha. In cPanel, go to Email, Email Routing. Find your domain. Change it from "Local Mail Exchanger" (or "Automatic") to "Remote Mail Exchanger". Save. Without this, Bluehost keeps delivering inbound mail to its own local mailboxes even though the public MX says Google.

7. Run the delta sync

   Right after MX flips, run a delta pass from Bluehost to Gmail. This catches any messages that arrived at Bluehost during the cutover window. Usually a few hundred messages.

8. Update SPF, DKIM, and DMARC

   Update SPF in cPanel DNS Zone Editor:

   v=spf1 include:_spf.google.com ~all

   Enable DKIM in Workspace admin: Apps, Google Workspace, Gmail, Authenticate email. Add the generated key as a TXT record at google._domainkey.yourdomain in cPanel.

   Add or keep a DMARC record. Start permissive: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.

9. Reconfigure clients

   Walk users through removing the old Bluehost account in their client and adding the new Workspace account. Workspace auto-configures from the email and password on most clients.

Gmail behaviour to expect#

A few things will look different in Gmail compared to Bluehost webmail:

• Folders become labels. Your Bluehost folder Projects/Clients is a Gmail label with the same nested name. Messages can hold multiple labels in Gmail, even though Bluehost treats each message as belonging to one folder.
• A message that existed in two Bluehost folders ends up in Gmail once with two labels. Good migration tools do this correctly. Bad ones duplicate the message.
• All Mail. Gmail has a special label that holds every message ever, regardless of label. Use it for total-count verification rather than per-folder counts.
• Conversation view groups threads. If your users hate this, they can turn it off in Gmail settings, but it stays on for a lot of users without complaint.

Common errors and how to handle them#

• Too many simultaneous connections from Bluehost. Drop to five workers per mailbox. Bluehost shared hosting throttles around 10.
• AUTHENTICATIONFAILED against Bluehost. Username must be the full email address. Password must be exactly what you set in cPanel; copy-paste it rather than re-typing.
• Connection unexpectedly closed. Bluehost kills long IMAP sessions after about 30 minutes. Use a migration tool that reconnects automatically and resumes from where it left off.
• OAuth2 token expired against Gmail. Refresh tokens for the migration scope expire after seven days of inactivity. If your migration paused for the weekend, refresh before resuming.
• Lookup failed against Gmail. Destination mailbox has not finished provisioning. New Workspace mailboxes take 5 to 30 minutes to be ready for IMAP traffic.
• Message too large for destination. Gmail allows up to 50 MB inbound over IMAP. Larger messages need a separate one-off export to MBOX.

Where Mailbox Taxi fits#

Mailbox Taxi treats Bluehost cPanel IMAP and Gmail as two standard endpoints, automatically reconnects when Bluehost drops sessions, deduplicates cross-folder messages on the Gmail side, and keeps a per-message manifest for resumable delta passes. If you would rather see the Microsoft destination path, the Bluehost to Office 365 guide is the corresponding writeup. For a generic cPanel source explanation that isn't Bluehost-specific, the cPanel to Gmail walkthrough is shorter. And the broader Google Workspace migration playbook covers tenant setup, SSO, and the post-cutover security baseline.

Validation in the first hour#

After MX cutover and Email Routing change:

• Send a test from an external Gmail to a migrated mailbox. It should appear in the Workspace inbox within 30 seconds.
• Send outbound from the Workspace account to an external address. Inspect headers; SPF should pass, DKIM should be signed by Google.
• Run dig MX yourdomain to confirm Google's five MX hosts are live.
• Spot-check three mailboxes against Bluehost source: pick one heavy user, one light, one shared. Folder counts plus All Mail count should match within 1%.
• Open a fresh client on a test user's machine. Workspace auto-configures from email and password on Outlook 2019+, Apple Mail, and most mobile clients.

For the mechanic of what an MX flip is doing under the hood, the MX record glossary is the brief explainer.

Decommissioning Bluehost mail#

Keep Bluehost mailboxes paid and reachable for 30 days after cutover. Use that window to:

• Confirm reliable inbound mail delivery to Workspace
• Catch any forwarder or alias you missed
• Verify every client device is reconfigured

After 30 days, the Bluehost email product can be cancelled while the hosting subscription stays (if the website still lives there). Delete the Maildir on the cPanel side as a final cleanup. The domain itself can stay at Bluehost or move to a different registrar separately; that's not part of this migration.