How to Migrate from Amazon WorkMail to Google Workspace

Amazon WorkMail shuts down on March 31, 2027. If your team already lives in Gmail and Google Docs, Google Workspace is a reasonable place to land. Here's the move, in the order that avoids losing mail.

One thing to know up front: Google copies mail from WorkMail over IMAP, and IMAP carries email only. Calendars and contacts are a separate step, covered below.

1. Set up Workspace without touching mail yet

Sign up for Workspace with your existing domain and verify it with the TXT record Google gives you. Verification doesn't change where mail goes; your MX records still point at WorkMail, and nothing changes for your users yet.

Create a Google account for every WorkMail user, using the same addresses. Recreate WorkMail groups as Google Groups and add aliases as user aliases. If you haven't listed your groups and aliases yet, the exit checklist covers that.

2. Gather what Google needs to reach WorkMail

Google's data migration logs in to each WorkMail mailbox over IMAP, so it needs:

• The IMAP server for your Region: imap.mail.us-east-1.awsapps.com (N. Virginia), imap.mail.us-west-2.awsapps.com (Oregon) or imap.mail.eu-west-1.awsapps.com (Ireland). Port 993, SSL.
• Each user's WorkMail email address and password. Rather than collecting everyone's passwords, reset them in the WorkMail console to temporary ones you control. Nobody should be using WorkMail by the end of this anyway.

3. Switch MX first, then copy the history

The cleanest order is to point new mail at Google before copying old mail:

1. Change your domain's MX records to the values Google shows in the Admin console. New mail starts arriving in Gmail as DNS updates.
2. Leave WorkMail running. It still holds everyone's history, and it's still reachable over IMAP.
3. Copy the history across (next step). Because WorkMail isn't receiving anything new, there's nothing to chase and no gap to fill afterward.

Do this on a quiet day. Some senders cache DNS, so a little mail may land in WorkMail for a day or so after the switch; the history copy picks it up if you start it after that window.

4. Run Google's data migration

In the Google Admin console, open Data → Data import & export → Data migration. Choose email as the data type and another IMAP server as the source, then enter the WorkMail IMAP server from step 2. Add your users, one at a time or with the CSV upload, mapping each WorkMail address and password to its Google account. Then start it and watch the progress per user.

Big mailboxes take hours. If a user fails to connect, it's almost always the password or the Region in the server name.

5. Fix sending: SPF and DKIM

WorkMail sent your mail through Amazon SES, so your SPF record probably includes amazonses.com. Add Google (include:_spf.google.com), turn on DKIM signing in the Admin console and publish its record, and remove the SES entry once nothing else on your domain sends through SES. The SPF, DKIM and DMARC explainer walks through what each one does.

6. Move calendars and contacts

Export them from a desktop client that's still connected to WorkMail: an .ics per calendar and a vCard of contacts (the export guide shows how in Outlook and Apple's apps). Then import them in Google Calendar under Settings → Import & export, and in Google Contacts with Import.

7. Archive, then delete WorkMail

Once everyone has confirmed their mail is there, run a final mailbox export to S3 for your records, keep the organization for a week or two as a safety net, then delete it so you stop paying for it.

Is Google the right landing spot?

If your team wants Gmail, yes: it's a good product. Just compare the per-seat price against what you paid for WorkMail (we did the math in Google Workspace vs. email on your own AWS). If you picked WorkMail because you wanted email inside your own AWS account, inbox.camp keeps it there, and migrating takes about ten minutes.