How to Migrate from IMAP to Gmail

Moving mail off a generic IMAP host into Gmail or Google Workspace is mostly straightforward, but the corners catch people. The destination handles folders as labels. Throttle limits on the Gmail side will silently slow a large run. Personal Gmail and Workspace use entirely different tools. This guide walks through the bulk path — the Workspace admin's Data Migration Service — for the typical case of moving a domain off a cPanel, IONOS, Bluehost or other generic IMAP host onto Google Workspace, and notes where the single-mailbox path differs.

Pick the right destination first#

There are three destinations people mean when they say "Gmail," and the tooling is different for each.

Google Workspace (business). This is the bulk migration path. You get the Data Migration Service in the admin console, which can pull from any IMAP source and run multiple users in parallel. If you're moving more than a handful of mailboxes, you want Workspace.

Personal @gmail.com. Single-mailbox only. The user goes into Gmail Settings → Accounts and Import → Check mail from other accounts, and Gmail itself fetches via IMAP. There is no admin console and no parallelism. Fine for one person migrating themselves; impossible at scale.

Google Workspace Essentials or no-Gmail SKUs. Mail is not part of the SKU. You need a Workspace plan that includes Gmail before any of this matters.

This guide assumes destination Google Workspace. If you're consolidating personal accounts the steps map but you'll be doing them one user at a time.

Before you start#

You need the destination ready and the source accessible. Specifically:

• A verified domain on Google Workspace, with users created at the destination addresses you intend to migrate to.
• Gmail enabled on each destination user (not assumed — check License assignments).
• A Super Admin account in the Workspace tenant for running the Data Migration Service.
• The source IMAP host name (commonly mail.yourdomain.com, imap.secureserver.net, or a host-specific address), port 993, and TLS.
• A credential set: either a single source admin account that can read all source mailboxes via IMAP, or per-user passwords. Most generic IMAP hosts do not offer admin impersonation, so plan on per-user credentials.
• A pilot of two or three test users to validate the full path before committing to a full batch.

Throttling on the Gmail side#

Workspace's Data Migration Service is engineered around Google's own IMAP behavior, so you don't see throttling in the same in-your-face way you would running an ad-hoc IMAP-to-IMAP migration. The underlying limits are still there:

• Roughly 2 GB of mail per IMAP connection within a rolling window before Google starts slowing the connection down.
• Per-user daily caps on the volume of mail that can be inserted via IMAP, measured in messages and total bytes rather than gigabytes flat.
• Per-IP connection rate limits when many users on the same source IP try to talk to Gmail at once.

DMS spaces out work to stay inside these. The relevant operational impact is that a 50-GB mailbox is not going to migrate in two hours, no matter how fast the source is — plan for an overnight run per oversized mailbox.

If you ever see Too many simultaneous connections or Temporary system problem. Try again later on the destination side, you've hit one of these limits and DMS will back off automatically.

Folders versus labels: what users will see#

Gmail does not have folders. It has labels. The Data Migration Service preserves the source folder structure by creating a label per source folder, including nested labels for nested folders (using / as the separator in label names). A message that lived in two folders on the source — possible with IMAP servers that store the same message under multiple paths — appears once in Gmail with both labels.

This is fine for most users but will catch out anyone with deep folder trees they navigate by clicking. Send a short note ahead of cutover explaining that:

• Their old folders are now labels in the left sidebar.
• Mail no longer "lives" in a folder — it lives in All Mail, with labels attached.
• Archiving in Gmail removes Inbox but keeps the label, which is closer to how IMAP folders worked than they might expect.

For the deeper background on how IMAP semantics map onto Gmail, the IMAP protocol glossary and the broader IMAP migration guide both go further than this single post needs to.

Migration steps#

1. Prepare the destination Workspace tenant

   In the Google Admin console, confirm the destination domain is verified and that every user in scope has a Gmail-enabled license assigned. Sign in to Gmail as one of the destination users at least once to ensure the mailbox is provisioned — if you skip this, DMS may report the user as not ready.

   If you're consolidating multiple domains, add each as a secondary domain before starting. Mail destined for a not-yet-added domain will fail provisioning at the destination.

2. Gather source credentials and enable IMAP

   On the source IMAP server, confirm IMAP is enabled and reachable on port 993 with TLS. Test from outside your network using Telnet or openssl s_client to rule out firewall surprises later.

   If the source enforces 2FA — common on hosts that have added security recently — generate an app password for each user, or have users do it themselves with clear instructions. Track which users still need passwords; this is usually the longest-running blocker in the entire project.

3. Open Data Migration Service in the admin console

   In the Workspace admin console, go to Data, then Data Migration. Click Set Data Migration Up, choose Email as the migration source, and select Other IMAP server when prompted for the source type.

   The connection setup screen asks for the source IMAP server host name, port (993), and the protocol. Enter these once at the migration level — they apply to every user in the batch.

4. Configure source authentication

   DMS supports two modes: a single privileged source account that can read all mailboxes, or per-user credentials. The privileged-account path is rare on generic IMAP hosts; most teams provide per-user credentials in the next step.

   When DMS asks for connection protocol, choose the option that matches your source (almost always IMAP over TLS on port 993).

5. Add users and set the date range

   For each user in scope, add their source email address, source password (or app password), and destination Workspace user. You can do this manually for small batches or by uploading a CSV for larger ones.

   Set the migration start date. Most teams choose all mail; if you only want recent mail (last 12 months for example), set the date filter here. Folder exclusion is also available at this stage — useful for skipping a large but unimportant archive folder.

   Start the migration. DMS shows per-user status: queued, in progress, completed, or failed.

6. Monitor and re-run failures

   DMS exposes a status table with per-user counts of messages migrated and any errors. Common failure modes are bad credentials (most often the source password being reset or the app password expiring), rate limits on the source IP, and folder-name encoding issues on older IMAP servers.

   Re-run failed users individually. DMS picks up where it left off rather than re-pulling messages that already came across, so retrying is cheap. Watch for users that complete with a much smaller message count than expected — usually a sign that the source skipped a folder it couldn't read.

7. Cut over MX records

   With initial sync complete and recent mail synced through DMS's ongoing pulls, lower the MX TTL at your DNS provider to 300 seconds at least 48 hours before cutover. On cutover, change the MX records to Google's listed values (typically smtp.google.com or the regional equivalent).

   After MX propagation, leave DMS running for another 24–48 hours to catch any mail that landed on the source during the window, then stop the migration in the console.

Gotchas to plan for#

A few things consistently surprise teams running IMAP to Gmail migrations.

Spam and trash do not migrate by default. DMS skips Spam and Trash. If a user genuinely needs old spam (rare) or trashed items they expect to find, surface this in pre-migration comms.

Threading is recomputed. Gmail's conversation view groups messages by Subject and References headers. After migration, threads will look different from what users saw on IMAP. Most users notice this once and move on; a few will think mail is missing. It isn't — it's threaded.

The "All Mail" label. After migration, every message has an All Mail label in addition to whatever source-folder label it carried. This is normal Gmail behavior and not a sign of duplication.

App password resets break in-flight migrations. If a user regenerates their source app password while DMS is mid-migration for them, DMS will start failing for that user with AUTHENTICATIONFAILED. Avoid asking users to rotate passwords during the migration window.

If you're working from a host-specific source, the cPanel to Gmail walkthrough and the Bluehost to Gmail walkthrough cover host-specific authentication quirks that this guide skips over.

Errors you'll actually see#

The error strings worth recognizing on an IMAP to Gmail run.

• AUTHENTICATIONFAILED — wrong source credential, expired app password, or IMAP disabled on the source mailbox.
• Too many simultaneous connections — the source server is rate-limiting. DMS handles this gracefully; ad-hoc tools do not.
• STARTTLS handshake failed — TLS version mismatch on the source. Confirm port 993 with TLS, not port 143 with STARTTLS.
• Temporary system problem. Try again later — Google-side throttle. DMS retries automatically; if you see it in third-party logs, slow down.
• Folder UTF-7 conversion error — non-ASCII folder name on a legacy IMAP source. Rename or skip the folder.

For app-password specifics on Gmail, the Gmail app password troubleshooting page covers generation, rotation and the most common failure modes.

Communicating with users#

A short pre-migration note prevents most of the support load. Tell users:

• The cutover date and time.
• That their folders will appear as labels in Gmail, and what that means in practice (clicking a label shows the same mail; archiving a message removes Inbox but keeps the label).
• That calendar and contacts are handled separately, with a link to whatever you're using for those.
• What to do on cutover day (sign in to Gmail at the Workspace address, no action needed if Outlook is the client of choice and they'll keep using it via IMAP against Workspace).

FAQ#

For a wider view of email migration including planning, fallback, and post-cutover validation, the complete email migration guide and the Google Workspace migration guide both go deeper than a single provider-pair post can.