On April 26, 2026, AWS officially announced the retirement of WorkMail and the transition of App Runner to maintenance mode. WorkMail has long been used as a managed business email service for small and medium-sized businesses, and organizations relying on AWS for their email infrastructure are now compelled to decide on a migration target.
Regarding App Runner, we previously covered it in AWS App Runner Retirement ─ ECS/Cloud Run/Lambda Migration Comparison Guide, so this article focuses specifically on WorkMail migration strategies.
Business impact caused by the retirement of WorkMail
For organizations using WorkMail, the following three business impacts will emerge first after the retirement announcement.
| Affected area | Expected impact |
|---|---|
| Email sending and receiving | Continues running until migration is complete, but will eventually be forcibly terminated |
| Calendar / Contacts | EWS / IMAP clients need to be switched |
| Email archive | Extraction of historical emails and review of retention periods required |
In particular, archiving historical emails requires careful handling due to statutory preservation and internal retention policies. Utilizing WorkMail's S3 export functionality to safeguard all email data in S3 / Glacier before service termination is the minimum baseline defense.
Comparison of three migration candidates
The three primary migration targets from WorkMail are as follows.
| Migration target | Estimated monthly cost | Learning curve | Operational overhead | Suitable use cases |
|---|---|---|---|---|
| Google Workspace | 800 to 2,500 JPY per user | Low (many Gmail users internally) | Low | General small and medium-sized enterprises |
| Microsoft 365 | 750 to 2,500 JPY per user | Medium (Outlook culture) | Low | Office usage already well established |
| Amazon SES + self-hosted IMAP/SMTP | Server costs only | High | High | Organizations with high-volume sending or specialized requirements |
As detailed in Comparison of Google Workspace and Microsoft 365, taking the retirement of WorkMail as an opportunity to re-evaluate the entire office suite rather than just email operations is the gold standard.
Key points when choosing Google Workspace
When migrating to Google Workspace, batch email migration from WorkMail can be performed using Google's official Data migration service. The outline of the procedure is as follows:
- Create Google Workspace tenant and verify domain
- Enable IMAP access on the WorkMail side and generate migration passwords
- Launch Data migration service in Google Admin and connect via IMAP protocol
- Sequentially import email data for each user
- Switch DNS MX records to Google Workspace
Combined with the Google Workspace Implementation Guide, you can proceed seamlessly from initial setup to migration completion.
Key points when choosing Microsoft 365
In Microsoft 365, IMAP migration functionality is provided in the Exchange Online admin center. For organizations where Outlook is well established, the biggest advantage is that changes to the user experience can be kept to a minimum.
However, Microsoft 365 licensing structures exhibit significant functional differences across Business Basic, Standard, and Premium; even if you "only want email," Business Basic or higher is required. If aiming for cost optimization, hybrid usage—using Google Workspace for email and M365 for Office document editing—is also a realistic option.
Key points when choosing Amazon SES + self-hosted IMAP
An option for hosting email services entirely in-house is an Amazon SES + Postfix + Dovecot configuration. While monthly costs can be kept low, operational burden increases sharply, so this is recommended only when all of the following conditions are met:
- Sending several hundred thousand emails per month or more
- Dedicated infrastructure engineers are available
- There is an unavoidable need to operate via IMAP from existing systems
If these conditions do not apply, straightforwardly choosing Google Workspace or Microsoft 365 will result in a lower TCO.
Phase design of migration projects
Regardless of project scale, standard migrations from WorkMail are structured in the following five phases.
| Phase | Timeline (50–200 users) | Main tasks |
|---|---|---|
| 1. Current state audit | 1–2 weeks | List users, mailboxes, distribution lists, and rules |
| 2. Target selection | 1–2 weeks | Cost estimation, PoC, internal approval |
| 3. Tenant construction | 1 week | Account creation, SSO, MDM, security configuration |
| 4. Data migration | 2–4 weeks | 5-person pilot → department by department → company-wide |
| 5. Cutover and decommissioning | 1 week | DNS MX cutover, WorkMail export, contract cancellation |
The estimated timeline is 6–8 weeks for an organization of 50 users and 10–14 weeks for 200 users. However, Phase 4 data migration can extend significantly depending on the number of distribution lists and shared mailboxes uncovered during the Phase 1 audit, as well as the scope of statutory retention requirements.
Areas custom development should target
Among WorkMail migration engagements, the following three areas offer the greatest opportunities to deliver value through custom development services.
- Analysis of existing email and retention policy design
- Establish rules to sort the past 5 years of email into "retain / discard"
- Consult with legal to determine retention periods by business category
- Email routing design during the hybrid period
- Architect configurations to receive emails on both old and new systems during migration
- Shorten DNS TTL to create a state where rollbacks are possible
- User training and FAQ preparation
- Prepare a "Migration Guide PDF" detailing operational changes alongside an internal FAQ
- Produce internal enablement assets in parallel, similar to the Google Workspace Benefits Pitch Deck
In particular, the second area—hybrid routing design—involves significant technical hurdles and often commands higher project billing rates. Designing to prevent accidents where emails are lost during MX record cutovers requires deep expertise, and few development vendors can execute this reliably.
Comparison table template for client explanations
Here is a comparison table template to present to clients during proposals. It is structured at a level of granularity suitable for securing internal approval.
| Comparison item | WorkMail (Current) | Google Workspace | Microsoft 365 |
|---|---|---|---|
| Monthly (per user) | From several hundred JPY | 800 to 2,500 JPY | 750 to 2,500 JPY |
| Email client | EWS / IMAP | Web / Gmail App | Outlook / Web |
| Calendar integration | EWS | Google Calendar | Outlook |
| File sharing | Separate contract required | Drive included | OneDrive included |
| AI capabilities | None | Gemini Enterprise integration available | Copilot integration available |
| DLP / Governance | Limited | Enterprise management capable | Enterprise management capable |
| Migration tool | — | Data migration service | Exchange admin center |
Conclusion
The retirement of WorkMail is the last chance to "bring email infrastructure into the 21st century." Most small and medium-sized enterprises will take this as an impetus to consolidate onto Google Workspace or Microsoft 365, allowing client engagements to expand into projects that review the entire business SaaS landscape, not just email.
Project timelines cannot be determined solely by user count across three areas: selecting a migration destination, designing routing for the hybrid period, and choosing where to offload archives. The setup varies depending on existing authentication infrastructure, the scope of retention policies, and the time remaining until WorkMail is decommissioned, requiring project schedules to be readjusted accordingly. If you find yourself in a situation where "the termination notice arrived and we can't decide where to start" or "our comparison materials lack the depth needed for internal approval," please share your current configuration and user count via our contact form. We are ready to consult starting from prioritizing your next steps.
