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.

Measure the source host with a representative mailbox before scheduling. Check connection caps, authentication and mailbox sizes with the provider; increasing a limit may help but does not establish an overnight completion guarantee.

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.

An IMAP import reads messages and folders, not the application data that may accompany a hosted mailbox. Export contacts and calendars through the source product where supported; document rules, aliases, local POP archives and delegation separately. Agree whether those tasks belong in the quote.

Use a representative pilot to check authentication, TLS, nested labels, timestamps, attachments and skipped messages. Source concurrency limits differ by host; neither a fixed connection count nor a universal GB/hour figure should set the deadline. Keep both services available through propagation and reconcile delivery before cancellation.