IMAP to Google Workspace migration

The transfer itself is simple. What varies wildly is the source host. Budget shared hosting typically caps simultaneous IMAP connections per account and per IP, and Google's migration service will happily hit that cap and start retrying. The result looks like a slow migration; it is actually a rate-limited one.

Before we start, we test the source host's connection behaviour with a single representative mailbox and measure actual throughput. That number, not a generic estimate, sets the schedule. Where the host allows it, raising the connection cap for the migration window turns a four-day run into an overnight one.

Google's migration service needs mailbox credentials or an admin-level account with impersonation on the source. On shared hosting there is rarely an impersonation path, which means either collecting per-mailbox passwords or resetting them centrally through the hosting control panel.

Resetting centrally is faster and more secure than emailing round asking for passwords, but it breaks users' existing mail clients immediately, so it must happen inside a communicated window. We supply the user-facing notice as part of the project rather than leaving you to write it the night before.

Server-side filters and sieve rules do not transfer. Neither do webmail address books in most cases, though a CSV export and import usually solves contacts in an afternoon. Aliases and catch-all addresses are configuration rather than data and are recreated in the Google admin console during setup.

Calendar data is a separate matter. Where the source was a plain IMAP host, there is usually no calendar to migrate, which makes these projects considerably simpler than an Exchange move. Where the host ran Zimbra or Kerio, calendars exist and are handled as their own workstream.

The MX change is the cutover. Before it, mail lands on the old host and the migration keeps copying. After it, mail lands in Google and one final delta collects the remainder from the source. That final delta is the reason we insist on keeping the old host paid for at least fourteen days.

Cancelling the old hosting the day after cutover is the single most common self-inflicted disaster in this category. DNS propagation is uneven, and a message can arrive at the old server days later. Fourteen days of overlap costs very little and removes the entire class of problem.