The WorkMail Exit Checklist: Everything to Do Before March 31, 2027

A practical checklist for leaving Amazon WorkMail: inventory, calendars and contacts, SES production access, DNS ownership, passwords, cutover timing, and when to delete the organization. Works whichever provider you pick.

Short on time? inbox.camp does this migration for you: your WorkMail org imported into a mail server in your own AWS account, 30 days free.

Amazon WorkMail stops working on March 31, 2027. Whatever you move to, the steps are mostly the same. Here's the list I use, built from rehearsing the move on my own organization and from the questions WorkMail admins keep asking me. Provider-neutral, except where I say otherwise.

1. Inventory what you actually have

WorkMail organizations accumulate things. Before you pick a destination, pull the list through the console or the API: users (and which are disabled), groups and their members, aliases, extra domains, resources like rooms, and any mailbox that forwards somewhere. Groups are the item people forget; the median WorkMail org uses them and most alternatives handle them differently. Do this while the WorkMail API still exists.

2. Decide what happens to calendars and contacts

Mail migrates over IMAP, which every provider supports. Calendars and contacts don't; they live behind WorkMail's Exchange interface. Options, in rough order of effort: export each user's calendar from the WorkMail web app as an .ics file and import it at the destination; use a migration tool that speaks Exchange Web Services; or accept that old events stay in WorkMail until it closes and only future ones move. Decide this early, because it determines your timeline more than mail does.

3. Sort out sending before you sort out receiving

If your new setup sends through Amazon SES (inbox.camp does), your AWS account needs SES production access in the region you'll use. New accounts start in a sandbox that can only send to verified addresses. WorkMail customers usually get approved within hours, but it's a request a human reviews, so file it in week one, not on cutover day.

4. Know who controls your DNS

If your domain's zone is in Route 53 in the same AWS account as WorkMail, cutover is one record change and can be automated. If it's at a registrar or another provider, you'll be pasting records by hand: MX, SPF, DKIM, DMARC, and autodiscover for mail clients. Find out now, and find the login.

5. Have a password plan

A mail migration needs to log in to WorkMail as each user. Either every user hands over their password (they won't, and shouldn't), or an admin resets every password to a new value at migration time and distributes the new ones. The second is cleaner and is what inbox.camp's wizard does for you, setting the same new password on WorkMail and on the new server. Either way, tell users the day before.

6. Never switch MX on faith

Before the MX change: a test message must reach the new server from the outside, a user must be able to read it, and a reply must reach an external address. After the MX change, run one more delta copy for whatever arrived at WorkMail in the meantime. Keep the old MX value written down. Sending servers retry for days, so a short overlap loses nothing; a wrong record found a week later does.

7. Set up clients last, not first

Point phones and desktops at the new server only after its TLS certificate is real, or every user gets a scary warning and a support ticket. Publish autodiscover and autoconfig records so Thunderbird, Apple Mail and Outlook set themselves up from the address alone; for iPhones, a configuration profile beats a settings walkthrough.

8. Keep WorkMail alive for a while, then delete it

After cutover, leave the organization running for a week or two as a safety net. Then delete it: you stop paying, and the old mailboxes stop being a second copy of your company's mail that nobody is watching. Delete the SES receipt rule that fed WorkMail at the same time.

The timeline that works

WhenDo
September–October 2026Inventory, pick a destination, request SES production access, decide on calendars.
November–December 2026Migrate. Cut over on a quiet day, not a Monday, not month-end.
January 2027Buffer. Things you forgot surface in the first month of real use.
March 31, 2027The deadline. Don't be migrating this week; everyone else will be.

If you want the AWS-native answer, where the new server runs in the same account WorkMail did, that's what inbox.camp is. If you want something else, the list above still applies. Either way, start in the fall.