Amazon WorkMail Is Ending: Migration Options and Timing

If you run mailboxes on Amazon WorkMail, migrating is no longer a preference you can defer — AWS has set a date, and it published that date on its own admin guide, not through a press release or a third-party blog.

That distinction matters because most of the WorkMail migration content online is written by third-party migration-tool vendors summarizing AWS's notice secondhand, sometimes with dates that drifted from the source page. This post traces every deadline back to the AWS documentation itself.

This post is built directly from that AWS documentation and the mailbox export API it describes, not from a summary of a summary. It covers what actually moves in a migration, what doesn't, the checklist to run first, the steps themselves, what tends to break, and how to roll back if something goes wrong before you commit.

Every date below is verified against docs.aws.amazon.com as of August 2, 2026. AWS can update deprecation notices, so recheck the source page linked at the end of this post before you lock in a cut-over date.

When does Amazon WorkMail actually shut down?#

AWS's admin guide states plainly: Amazon WorkMail end of support is March 31, 2027. After that date you can no longer access the WorkMail console or WorkMail resources — mailboxes, data, and API access all stop at once, not gradually.

There's an earlier date that matters just as much if you're evaluating WorkMail today: AWS stopped accepting new WorkMail customers on April 30, 2026. If your organization signed up before that date, you keep full access until end of support. If you were considering WorkMail as a new deployment, that option is already closed.

What actually moves and what doesn't#

AWS's mailbox export tool moves messages and calendar items. It does not move everything else that lives inside a mailbox, and planning around that gap early avoids a scramble during cut-over week.

• Email messages and calendar items — exported in MIME format via the StartMailboxExportJob API, per AWS's own mailbox export guide.
• Contacts and tasks — AWS's export job output explicitly lists these as non-exportable (the totalNonExportableItems field). Move them separately through IMAP contact sync or a manual export from your client.
• Mail flow rules, distribution lists, and mobile device policies — these live in WorkMail's organization configuration, not in mailbox content. Nothing copies them automatically; rebuild them on the new platform.
• DNS records — your domain's MX, SPF, and DKIM records point at WorkMail today and have to be repointed at the new provider as part of cut-over, not left running indefinitely in parallel.

Pre-migration checklist#

Do this before you run a single export job.

• Inventory every mailbox and shared mailbox in the WorkMail organization directory so nothing gets missed on cut-over day.
• Confirm the destination — Microsoft 365, Google Workspace, or another provider — and provision the tenant and licenses before exporting anything.
• Set up the AWS side: an S3 bucket with public access blocked, a symmetric KMS key, and an IAM role scoped to write to that bucket and use that key. All four resources must sit in the same AWS Region as your WorkMail organization.
• Record your WorkMail organization ID and each user's entity ID from the console or API — StartMailboxExportJob requires both.
• Warn users about IMAP reconfiguration. Any client pointed at WorkMail's IMAP endpoint needs new server settings once you cut over.
• Set a cut-over date with real margin before March 31, 2027. Migrating on the deadline itself leaves no room to fix problems, since console and API access end that same day.

Migration steps#

1. 1

   Create the export IAM role and KMS key

   Set up an S3 bucket with block-public-access on, a symmetric KMS customer master key, and an IAM role with a policy granting write access to the bucket and encrypt permission via that key.

2. 2

   Start a mailbox export job per user

   Run aws workmail start-mailbox-export-job with your organization ID, the user's entity ID, the KMS key ARN, the IAM role ARN, and the target S3 bucket. This exports messages and calendar items to a .zip file in MIME format.

3. 3

   Monitor the job

   Use describe-mailbox-export-job or list-mailbox-export-jobs to track status. AWS allows up to 10 concurrent export jobs per organization and one export per mailbox every 24 hours, so plan bulk migrations in batches.

4. 4

   Download and decrypt the export

   The completed .zip is KMS-encrypted. Anyone with access to the CMK can download and decrypt it — restrict that access to the people actually running the migration.

5. 5

   Import into the destination

   For Microsoft 365, use Exchange's mailbox migration tooling (see Microsoft Learn's migration overview). For Google Workspace, use its dedicated data migration service. For another IMAP host, most migration tools accept the exported MIME files directly.

6. 6

   Repoint DNS

   Lower TTLs ahead of time, then switch MX, SPF, and DKIM records to the new provider once every user's export has landed and been verified.

7. 7

   Reconfigure clients and recreate what didn't export

   Point desktop and mobile mail apps at the new host's IMAP/SMTP settings, and manually recreate contacts, tasks, distribution lists, and mail flow rules that the export left behind.

What breaks during migration#

A mailbox export is not a like-for-like copy of a WorkMail organization — it's a copy of messages and calendar items only. Everything in this table either doesn't export at all or needs a manual step to survive the move.

Rollback plan#

Rollback is straightforward as long as you don't decommission anything early. Running StartMailboxExportJob copies data — it doesn't move or delete it — so WorkMail keeps working exactly as before, during and after every export you run.

Keep MX records pointed at WorkMail until every migrated mailbox has sent and received mail successfully on the new platform. Switching DNS is the point where rollback gets harder for that user, since incoming mail then routes to the new host.

If problems surface after cut-over, revert DNS back to WorkMail and mail resumes flowing there. Nothing in the export step touched WorkMail's live configuration.

The one hard limit: this only works before March 31, 2027. AWS's notice states that after that date you lose console and API access to WorkMail entirely — rollback stops being an option regardless of how far along the migration is.

Doing it without downtime#

A full-organization cutover in one step is where most of the breakage in the table above shows up. Staggering it reduces the blast radius of any single mistake.

• Lower MX, SPF, and DKIM TTLs to a few minutes at least 48 hours before cut-over so the eventual DNS switch propagates fast.
• Migrate mailboxes in small waves — start with a low-risk group, not the whole organization at once.
• Pilot the whole sequence on one non-critical mailbox first: export, import, DNS test, client reconnect. Fixing a broken step on one mailbox is a lot cheaper than discovering it mid-cutover for two hundred.
• Treat each mailbox as having one source of truth at a time. Running WorkMail and the destination inbound in parallel for longer than an export-and-import cycle invites duplicate or missed mail.
• Use the destination's own migration tooling for larger mailbox counts — Exchange mailbox migration for Microsoft 365 (per Microsoft Learn), or Google Workspace's data migration service — rather than manually re-importing exported files one by one.

Where AI Emaily fits#

The WorkMail deadline forces one decision: where your mail lives next — Microsoft 365, Google Workspace, or another IMAP host. It doesn't have to force a second decision about which app you read that mail in.

We build AI Emaily, an AI-native email client that connects to Gmail, Outlook, and any IMAP mailbox — including Microsoft 365 and Google Workspace once your export lands there. Switching hosts doesn't mean re-learning an inbox on top of everything else on this checklist. AI Emaily doesn't touch the mailbox migration above — you still have to move the mail itself before March 31, 2027 — but once it's moved, connecting AI Emaily to the new host is a standard IMAP or OAuth setup, not a second migration project.