How to Migrate from Amazon WorkMail to PolarisMail
Amazon Web Services is shutting down Amazon WorkMail. Whether you’re a reseller preparing a client’s WorkMail organization for migration, or you’re moving your own mailbox, WorkMail migrates like most IMAP-based providers, with a few extra pieces that need separate handling since IMAP alone doesn’t carry calendars, contacts, or WorkMail’s enterprise features.
This applies whether you’re a reseller preparing a client’s migration or migrating your own mailbox. WorkMail runs on the standard two-step migration model, one pass before your MX records change and one after, so the migration guide covers how to actually submit and run it. The sections below cover what’s specific to WorkMail.
Amazon WorkMail is shutting down
AWS stopped accepting new WorkMail customers on April 30, 2026. If your organization was already set up before that date, WorkMail keeps working for now, but AWS ends support entirely on March 31, 2027. After that date, the WorkMail console, web app, and every mailbox in it become inaccessible.
That gives existing WorkMail organizations a fixed runway to migrate. Build in time for a pilot batch, a staged cutover, and validation before committing to a final date close to the deadline.
Which tier matches your WorkMail usage?
WorkMail is one product, but the people using it don’t all work the same way. Some only need Outlook or Webmail for email. Others depend on WorkMail’s native Outlook calendar and contact sync all day. Here’s how those patterns line up against our tiers:
✗ Not available
Italics = partial support
| If you use… | The equivalent is… | Basic | Enhanced | OEX |
|---|---|---|---|---|
| Outlook (email) | IMAP or native connectivity | ✓ | ✓ | ✓ |
| Outlook calendar & contacts sync | CalDAV/CardDAV or native sync | ✗ | Via free plugin | ✓ native, no plugin |
| Outlook task sync | Native Outlook sync | ✗ | ✗ | ✓ native, no plugin |
| Apple Mail (email) | Email access via IMAP | ✓ | ✓ | ✓ |
| Apple Calendar & Contacts sync | CalDAV/CardDAV sync | ✗ | ✓ | ✓ |
| Mobile email | Mobile email sync | ✓ | ✓ | ✓ |
| Mobile calendar & contacts sync | ActiveSync | ✗ | ✓ | ✓ |
| Shared calendars & team collaboration | Advanced groupware | Webmail sharing only | ✓ | ✓ |
| Chat & video calls | Live Chat & video in Webmail | ✓ | ✓ | ✗ |
| Real-time document collaboration | Office Docs | Limited file tools | ✓ | ✗ |
If people mostly need reliable email in Webmail, Outlook, or on their phone, Basic covers that. If they need calendars and contacts synced across mobile devices and Apple apps, plus shared calendars and real-time document collaboration, Enhanced is the closer match, and Enhanced users on Outlook desktop can add calendar and contact sync through our free CalDAV/CardDAV Synchronizer plugin. If native Outlook calendar, contact, and task sync without a plugin is the priority, and chat, video, or document collaboration aren’t, OEX is built for exactly that trade-off. Basic, Enhanced, and OEX mailboxes mix under the same domain, so a WorkMail organization with different types of users can land on all three depending on how each person actually works.
Worth flagging for larger organizations: WorkMail caps every mailbox at 50 GB, a hard limit AWS won’t raise. Enhanced and OEX mailboxes scale up to 200 GB, so anyone who’s been trimming their inbox to stay under WorkMail’s ceiling gets real room to grow after the move.
What you need before migrating
WorkMail supports IMAP out of the box, so in most cases the account’s regular password works for the migration without any extra setup on WorkMail’s side.
The exception is organizations using AWS IAM Identity Center for single sign-on. Enabling IAM Identity Center replaces users’ regular WorkMail credentials with personal access tokens, and only those tokens work for email-client access from that point on, IMAP included.
Using IAM Identity Center? Each user needs to generate a personal access token from the WorkMail web app and use that instead of a password. Test it on one pilot mailbox before setting up the rest of the migration.
You’ll also need the IMAP server for the mailbox’s AWS region:
| AWS region | IMAP server |
|---|---|
| US East (N. Virginia) | imap.mail.us-east-1.awsapps.com |
| US West (Oregon) | imap.mail.us-west-2.awsapps.com |
| Europe (Ireland) | imap.mail.eu-west-1.awsapps.com |
Not sure which region an organization is on? Check with whoever set up WorkMail, or look at the region selector in the WorkMail console.
Set temporary passwords before you start
Reset each mailbox’s password, or generate its personal access token, ahead of time, and use that as the temporary credential for the migration window rather than the account’s real password. Let users know what to use in the meantime, so they’re not locked out of their own mailbox while it’s in progress.
Watch for credential changes mid-migration. If a user changes their password, or a personal access token gets regenerated, after you’ve set it up for the migration, that account’s import will fail. We retry failed accounts once you confirm it’s safe to, so keeping your migration batches small makes those retries faster.
Calendars, contacts, and anything else IMAP won’t carry
IMAP only moves email messages and folders. Everything else in a WorkMail mailbox needs to travel separately:
- Calendars: export each user’s calendar as an .ics file and attach it when you open the migration ticket.
- Contacts: export as a .vcf file and attach it the same way.
- Aliases, forwards, and distribution lists: the migration guide has CSV templates for each of these.
- Tasks and notes: there’s no automated import path for these. Plan to recreate them manually for anyone who relies on them.
If your organization relies on WorkMail’s enterprise features
A chunk of WorkMail’s feature set is built around AWS-specific enterprise tooling: Active Directory integration, IAM Identity Center, customer-managed AWS KMS encryption keys, email journaling, CloudWatch and CloudTrail logging, mobile device policies and remote wipe, room and equipment resource mailboxes, and Lambda-based mail flow rules.
None of these have a confirmed one-to-one replacement in PolarisMail. That doesn’t mean there’s no path forward. Workflows like these are usually solved by recreating them differently on PolarisMail, adding a third-party tool, or keeping a separate compliance system in place. But it does mean they need a real conversation before you commit to a migration date.
If a mailbox needs a full point-in-time export for compliance reasons before it’s decommissioned, WorkMail’s own export tool (the StartMailboxExportJob API) can pull messages and calendar items into an S3 bucket. It requires AWS CLI or API access plus an existing S3 bucket and KMS key, and it doesn’t include contacts or tasks, so treat it as an archival fallback rather than a migration path.
Open a ticket through the Support Portal to talk through any of these before you finalize a plan.
What happens next
Once you know which tier fits, and IMAP access or a personal access token is ready, you’re set to start the migration itself. The full process, whether you’re moving one mailbox or a thousand, is covered in the migration guide:
One last thing: don’t disable WorkMail users the moment your DNS changes. AWS deletes a disabled user’s inbox after 30 days, which is plenty of time to validate the migration first, but there’s no undo once that window closes.
Start your 30-day trial. Migration included.