Amazon WorkMail is shutting down: a migration checklist before March 31, 2027

AWS is retiring Amazon WorkMail. If you set it up for your own company or for clients, there is a fixed date by which mail has to be running somewhere else. This checklist covers the dates, the export, the DNS changes and how to pick a replacement without regretting it a month later.

The key dates

Date	What happens
April 30, 2026	WorkMail stops accepting new customers. Existing organizations keep working.
March 31, 2027	End of support. The WorkMail console and resources are no longer accessible.

Work backwards from March 31: leave at least a few weeks between switching DNS and the deadline, so you can still export anything you missed.

1. Take inventory

For each WorkMail organization, write down:

• the domains and their DNS provider;
• the users, groups and aliases, and who actually uses each one;
• shared resources such as room and equipment calendars;
• the clients your users rely on: Outlook, mobile apps, the web client.

That last point decides which replacement will work, so don’t skip it.

2. Export the mailboxes

WorkMail exports mailboxes through the API or the AWS CLI (start-mailbox-export-job), not from a button in the console. Before you start you need:

• an S3 bucket without public access;
• a symmetric KMS key to encrypt the export;
• an IAM role that WorkMail’s export service can assume, with permission to write to the bucket and use the key;
• all three in the same AWS Region as the WorkMail organization.

Each export produces a .zip of MIME files with email and calendar items. Contacts, tasks and notes are not exported. AWS allows up to 10 concurrent export jobs per organization and one export per mailbox every 24 hours, so plan larger organizations over several days.

3. Update DNS

When the new provider is ready, update the domain’s records:

• MX: point them to the new provider. This is the moment incoming mail moves.
• SPF: keep a single SPF record and replace WorkMail’s entry with the new provider’s.
• DKIM: remove the old DKIM records and add the new provider’s.
• DMARC: keep your existing policy; if you don’t have one, start with p=none.
• Autodiscover: remove the WorkMail autodiscover record if the new provider doesn’t use one, so mail clients don’t keep looking for the old server.

Lower the TTL of the MX records a day before the switch, so the change propagates faster.

4. Choose the replacement by how people read mail

Comparing feature lists is less useful than answering a few practical questions:

1. Which clients must keep working? If your users live in Outlook, you need a provider with full Outlook support. That rules out some modern, app-only services.
2. Where must the data live? If you serve European clients, check where mailboxes and backups are stored.
3. How is it priced? Per user, per domain, or by volume. With many shared or occasional users, per-user pricing adds up quickly.
4. Do you also need a shared inbox or transactional email? If you already run separate tools for support and application email, it may be a chance to consolidate.
5. How do you migrate? Some providers import old mailboxes, others don’t. Know which before you commit.

AWS itself points to Kopano Cloud, Zoho Mail and Zoom Mail as alternatives with comparable capabilities and migration tools.

Where Nilomail fits, and where it doesn’t

Nilomail is designed for you if you set up email for your own company or for clients and want mailboxes, a shared inbox, newsletters and transactional email in one service, with a separate workspace per client and data in the EU.

It is not the right choice if your users must keep working in Outlook: Nilomail will be used through its own web app, with iOS and Android apps on the way, and it won’t connect to external mail clients. It also won’t import old mailboxes: you keep the WorkMail export as your archive.