Migrate Bluehost Email to Google Workspace (2026 Guide)

Bluehost runs email on a stock cPanel-and-Dovecot stack, which is good news for migration — IMAP works exactly like the spec, and there's no proprietary API in the way. The bad news is that shared hosting has unpredictable I/O, throttling that kicks in around 5 simultaneous connections per IP, and a webmail layer (Horde and Roundcube) that stashes contacts and rules in places IMAP can't reach. This guide walks the path from Bluehost cPanel email to Google Workspace with the specifics that matter.

What's actually on Bluehost#

Before you migrate, audit. Bluehost mailboxes are typically smaller and simpler than enterprise mailboxes, but they have edge cases that bite if you don't catch them up front.

In the IMAP path: INBOX, sent (folder named "INBOX.Sent" by default, sometimes "Sent" depending on webmail client used), Drafts, Junk, Trash, and any custom folders the user has created. Message bodies, attachments, internal date, flags (read/unread, flagged, answered) all migrate cleanly.

Outside the IMAP path: server-side forwarders (configured in cPanel, not the mailbox), email filters (cPanel's "Email Filters" feature), autoresponders, catch-all addresses, mailing lists, contacts in Horde or Roundcube, calendars in Horde, and any DKIM signing config. None of this comes across in an IMAP sync.

The migration plan should treat the IMAP move and the configuration recreation as two separate workstreams. Both are real work.

Setting up Google Workspace#

Get the destination ready before you touch the source.

Create the Workspace tenant#

Sign up at workspace.google.com. Add your domain and verify ownership via the TXT record Google provides. Do not change MX yet — verification only needs the TXT.

If you only have a few users, the Business Starter plan (30 GB per user) is enough. If anyone's Bluehost mailbox is approaching 30 GB, jump to Business Standard (2 TB) or Business Plus (5 TB). Migration tools will hard-fail when the destination runs out of quota mid-sync, and resuming after a quota bump is messier than starting on the right plan.

Recreate users#

Bulk-create users via the Admin console's CSV import. Match the SMTP address exactly — if Bluehost has sales@example.com, Google should have sales@example.com. Mismatches break message threading and force you to merge mailboxes later.

For aliases (called "additional email addresses" on Bluehost cPanel), add them as alternate email addresses on the matching Google user. For shared/role mailboxes like info@, decide now whether they'll be users with their own license or Google Groups with multiple recipients — the choice affects how mail is stored and searched.

Document forwarders and filters#

Open cPanel → Forwarders. Screenshot or export the table. Same for cPanel → Email Filters. You'll recreate these as Google Workspace routing rules (org-wide) or Gmail filters (per-user). For details on how routing rules in Google compare to other providers' equivalents, the Google Workspace migration guide has a longer treatment.

Pre-flight checks on Bluehost#

Two things to confirm before you start the bulk sync.

IMAP is enabled#

In cPanel → Email Accounts → Connect Devices, you'll see the IMAP settings for each mailbox. The standard config is:

• Server: mail.yourdomain.com (or mail.example.com depending on hosting)
• Port: 993
• SSL/TLS: required
• Auth: PLAIN over SSL

If your domain is new or you've recently changed DNS, mail.yourdomain.com may not resolve. Fall back to the Bluehost shared-server hostname (boxNNNN.bluehost.com — find it in cPanel → Server Information). Avoid using the IP directly; cert validation will fail.

Lower DNS TTL#

24 hours before MX cutover, set your MX record TTL to 300 seconds in cPanel → Zone Editor. The default Bluehost TTL is 14400 (4 hours), which means stale resolvers can route mail to Bluehost for up to 4 hours after you flip DNS. Lower TTL means a tighter cutover window.

If you're not yet comfortable with how MX records work in DNS, our MX record glossary entry covers the basics in a few paragraphs.

Choosing your migration tool#

Three real options.

Google Data Migration Service (DMS)#

Google's free, built-in tool. IMAP source, Gmail destination. Works fine for Bluehost-sized mailboxes because Bluehost mailboxes are usually small.

What DMS does well: bulk migrations of fewer than 50 mailboxes, mailboxes under 10 GB each, organizations that don't need detailed per-message logging.

Where DMS struggles: no delta sync after the first pass (re-runs duplicate), single-threaded, sparse error messages, skips messages over 35 MB.

Desktop IMAP migration#

A local tool authenticates to Bluehost over IMAP and Google over IMAP+OAuth, then copies messages folder-by-folder. Mailbox Taxi is built for this — desktop-first, with per-message logging and resumable syncs that don't reimport everything when you re-run.

Desktop tools win when you need parallelism control, when you want to see exactly which messages failed and why, and when you need to run a delta sync at the end without reimporting your bulk.

Hybrid#

For 50+ user organizations, run DMS for the bulk and a desktop tool for the delta. DMS handles 90% of the volume for free; the desktop tool catches the last 10% (the delta) and gives you the audit trail you'll want when a user asks where their mail went.

Step-by-step migration#

1. Pilot two mailboxes

   Pick a light mailbox (under 1 GB) and a heavy one (over 5 GB). Migrate both end-to-end. Validate folder counts, sent items, and that custom folders survived. Time the heavy one — this is your per-GB throughput number, and you'll multiply it across the rest of the migration.

   If the pilot reveals folder-name issues (Roundcube sometimes creates folders with names like "INBOX.Sent" that map awkwardly to Gmail), fix the folder map in your tool before the bulk run.

2. Capture credentials securely

   Bluehost mailbox passwords are stored as cPanel objects. You can reset any mailbox password from cPanel → Email Accounts → Manage. If you don't know the user's current password, reset it, do the migration, then have the user choose a new one post-migration (or just disable the account if you're decommissioning).

   Store all credentials in a password manager. A spreadsheet or text file is a security incident waiting to happen.

3. Run the bulk pre-sync

   Start 24–48 hours before MX cutover. Bluehost throttles aggressively on shared hosting — you'll see "Too many simultaneous connections" errors if you push past 4–5 concurrent connections per IP. Most tools default to higher concurrency than this; turn it down.

   If you're migrating dozens of mailboxes, stagger the start times. Hitting Bluehost with 50 mailboxes at once from one IP gets you rate-limited fast. Stagger by 5–10 minutes per mailbox start.

4. Cut MX records

   At your scheduled cutover time, log into cPanel → Zone Editor → MX Records. Delete the existing Bluehost MX records and add Google's published MX records (the admin console shows the exact values for your tenant — copy from there, don't memorize).

   Save and wait 5–10 minutes for propagation. Verify with dig MX yourdomain.com @8.8.8.8 and dig MX yourdomain.com @1.1.1.1. Send a test message from an external account.

5. Run the delta sync

   24–48 hours after MX flipped, run a delta against each Bluehost mailbox. Mail that arrived during the propagation window will be on Bluehost; the delta pulls it across. UID-based dedup means messages already migrated won't be duplicated.

   If you want belt-and-suspenders, set a Bluehost-to-Google forwarder on each mailbox at the moment of cutover. That way new mail at Bluehost forwards immediately and the delta will be tiny.

6. Recreate forwarders and filters in Google

   Now's the time. Convert each Bluehost forwarder into a Google Workspace routing rule (Admin console → Apps → Gmail → Routing) or a per-user filter. Rebuild autoresponders inside Gmail's vacation-responder UI. Test a few before declaring done.

7. Update SPF, DKIM, DMARC

   In cPanel → Zone Editor, replace the SPF record. The new value should be v=spf1 include:_spf.google.com ~all (or -all if you want to be strict). Remove any old Bluehost include statements.

   Enable Google-managed DKIM in the Admin console → Apps → Gmail → Authenticate email. Google generates the DKIM key; you paste it into your DNS as a TXT record. DMARC is a separate TXT record at _dmarc.yourdomain.com — start with p=none and tighten to p=quarantine or p=reject once you've verified clean reports for a week.

8. Decommission Bluehost email

   Once delta is clean and validation passes, disable email accounts in cPanel. Don't delete them yet — wait 30 days in case you find a missed message. After 30 days, you can safely remove. If you're keeping Bluehost for web hosting only, just turn off the Email service in cPanel; if you're leaving Bluehost entirely, transfer the domain out and cancel.

Common failure modes#

"AUTHENTICATIONFAILED" on Bluehost IMAP#

Usually a wrong-username problem. Bluehost expects the full email address as username, not just the local part. sales@example.com, not sales. If the full address still fails, the mailbox password may have been changed by the hosting account owner — reset from cPanel.

Folder names with "INBOX." prefix#

Bluehost's Dovecot config exposes folders with an "INBOX." prefix in some configurations: INBOX.Sent, INBOX.Drafts. Some migration tools handle this transparently; others migrate them as literal folders named "INBOX.Sent" on Google. Check your tool's folder mapping settings before bulk.

Messages over the size limit#

Google's 35 MB inbound limit applies to migration. Messages over 35 MB will be rejected by the destination with Message too large for destination. Log them, decide what to do per-message (most are old training PDFs or large image attachments that can be extracted and put in Drive).

Cert mismatch on mail.yourdomain.com#

Bluehost issues a single shared cert for the hosting server hostname (e.g., boxNNNN.bluehost.com). If you connect via mail.yourdomain.com, you'll see a cert mismatch. Most tools have a "trust certificate" option for migrations — use it, but only after verifying you're hitting the right Bluehost server. Don't blindly accept any cert.

Disconnected for inactivity#

Bluehost's IMAP server times out idle connections aggressively — typically after 5–10 minutes without activity. If a migration tool pauses (waiting on the destination, processing a large attachment, etc.), the source connection drops. Most modern tools handle reconnect transparently; older scripts may halt with this error. If you see it repeatedly, your tool isn't sending IMAP NOOP keepalives during long operations. Either switch tools or reduce per-folder batch sizes so individual operations complete in under 5 minutes.

Spam-folder filter false positives#

Bluehost runs SpamAssassin server-side. Messages that scored borderline-spam during their lifetime on Bluehost may have been auto-moved to the Junk folder even though they aren't actually spam. When you migrate Junk, you bring all of that history with you. Decide before migration whether to include Junk — many migrations skip it entirely as an opportunity to leave old spam behind.

Sent items missing dates#

A small subset of older Bluehost-hosted mailboxes (typically those upgraded from very old Horde-only configurations) have sent items with the wrong internal date — usually all stamped with the date of the mailbox migration rather than the original send date. This is a quirk of how older Horde stored outbound copies. IMAP exposes whatever internal date the server has. There's no clean fix on the Google side; if dates are critical for compliance, do a one-time correction after migration using a script that reads message headers and updates internal date.

Comparing destinations#

If you're still weighing destinations, the Bluehost to Office 365 path is roughly equivalent in effort but uses Microsoft's IMAP migration service instead of Google's DMS. For single-user migrations, the simpler Bluehost to Gmail path skips the Workspace tenant setup and just adds the Bluehost mailbox to a personal Gmail account.

For organizations with multiple cPanel-based hosts (Bluehost, HostGator, SiteGround, A2), the cPanel to Google Workspace walkthrough generalizes this guide and is worth reading if you have a mixed environment.

Post-migration validation#

Per-user:

• Folder count matches between Bluehost and Google.
• Message count per folder is within 1%.
• Sent items are visible and ordered correctly.
• Test message from external Gmail and external Outlook.com lands in the right place.
• Mobile client picks up the new account.

Per-tenant:

• SPF includes _spf.google.com and excludes any Bluehost host include.
• DKIM signs outbound mail (check the headers of a test message).
• DMARC reports start arriving (set rua= to a real address you read).
• All forwarders recreated.
• All autoresponders rebuilt.
• Catch-all behavior verified if applicable.

If both checklists pass, the migration is done. Wait 30 days before deleting source mailboxes. Cancel the Bluehost email service when you're sure nothing is missing.