Amazon Web Services (AWS) has announced that Amazon WorkMail will reach end of support on March 31, 2027. The service stopped accepting new customers beginning April 30, 2026, while existing customers can continue using Amazon WorkMail until the end-of-support date.

For organizations still using WorkMail, the deadline creates an important migration requirement.

Moving business email involves considerably more than copying messages from one mailbox to another. Organizations may need to account for users, domains, folders, contacts, calendars, aliases, permissions, mail flow, DNS records, security requirements, applications and historical data.

Starting early gives IT teams time to inventory the existing environment, choose an appropriate destination and migration method, run pilot migrations, resolve problems and complete the final cutover without unnecessary pressure.

For organizations moving to Microsoft’s cloud environment, this guide provides a practical framework for planning an Amazon WorkMail to Microsoft 365 migration before the 2027 deadline.

Amazon WorkMail End-of-Support Timeline

According to AWS, the important dates are:

AWS documentation states that after the end-of-support date, customers will no longer be able to access the Amazon WorkMail console or WorkMail resources.

Organizations should therefore complete migration, validation and any required data export well before the deadline rather than treating March 31, 2027 as the date to begin migration.

Why Start the Migration Early?

An email migration affects a communication system employees may depend on throughout the working day.

Waiting until the final weeks before the WorkMail shutdown can increase operational risk.

Starting earlier provides time for:

• Environment discovery
• Data inventory
• Microsoft 365 preparation
• Security assessment
• Migration-tool evaluation
• Pilot testing
• User communication
• Troubleshooting
• DNS and mail-flow planning
• Data validation
• Post-migration support

A migration should be treated as a controlled IT project rather than a last-minute data-transfer exercise.

1. Inventory Your Amazon WorkMail Environment

Before choosing a migration method, understand what currently exists.

Create an inventory covering applicable:

• User mailboxes
• Mailbox sizes
• Email domains
• Email aliases
• Groups and distribution requirements
• Shared resources
• Folder structures
• Contacts
• Calendars
• Delegated access
• Permissions
• Retention requirements
• Mobile devices
• Desktop email clients
• Applications or devices that send email
• Compliance or archival requirements
• For larger organizations, document each mailbox and its intended Microsoft 365 destination.

This inventory becomes the foundation for migration planning and later validation.

2. Determine What Data Actually Needs to Move

Not every organization needs to migrate every historical item.

Before transferring data, determine which information needs to remain operationally available.

Depending on organizational requirements, this may include:

• Email messages
• Email folders
• Attachments
• Contacts
• Calendar items
• Historical mail
• Shared resources
• Relevant mailbox metadata

The supported data types depend on the migration approach.

For example, a method designed primarily around email-message migration may not automatically transfer every contact, calendar, permission or collaboration object.

Do not assume that because email has migrated successfully, every other mailbox-related item has also moved.

Document exactly which data types the selected migration method supports and create a separate plan for anything it does not.

3. Establish an Independent Export or Backup Strategy

Migration and backup serve different purposes.

Before major changes or final cutover, organizations should establish an appropriate export or backup process for data they are required to retain.

AWS provides mailbox-export capabilities for Amazon WorkMail. Its mailbox export process can export mailbox content for preservation outside the active WorkMail environment.

Organizations should:

1. Identify which data requires independent retention.
2. Select an appropriate export or backup approach.
3. Complete the export before decommissioning.
4. Verify that the exported information is accessible.
5. Retain it according to applicable organizational, legal and compliance requirements.

A backup or export should be tested rather than assumed to be usable simply because the export job completed.

4. Prepare the Microsoft 365 Environment

Before migrating user data, prepare the destination environment.

Depending on the organization’s Microsoft 365 configuration, this can include:

• Creating or synchronizing user identities
• Assigning appropriate licenses
• Creating mailboxes
• Verifying domains
• Configuring security requirements
• Preparing groups and shared resources
• Reviewing mailbox capacity
• Establishing administrator roles
• Configuring authentication
• Preparing mail-flow settings
• Reviewing retention or compliance requirements

Avoid beginning a large mailbox migration before confirming that destination accounts are properly provisioned.

5. Choose a Migration Approach

There is no single migration method appropriate for every organization.

The right approach depends on factors such as:

• Number of users
• Mailbox sizes
• Required data types
• Internal IT capability
• Migration timeline
• Security requirements
• Compliance obligations
• Budget
• Acceptable downtime

Organizations can broadly evaluate three approaches.

Native or Manual Migration

A manual or standards-based migration approach may be suitable for smaller or relatively simple environments.

Advantages can include:

• Greater internal control
• Reduced dependency on third-party migration software
• Potentially lower software costs

Potential limitations can include:

• More administrative work
• Limited automation
• More complex mailbox mapping
• Separate handling of unsupported data types
• Greater dependence on internal expertise

Organizations should verify exactly which data types a selected native or manual approach can transfer.

Third-Party Migration Software

Migration applications can automate portions of the process and may provide capabilities such as:

• Multiple-mailbox processing
• Source-to-destination mapping
• Selective migration
• Date or folder filtering
• Scheduling
• Incremental or repeat migration
• Progress monitoring
• Migration reporting

Third-party tools vary considerably.

For example, products such as Shoviv’s Amazon WorkMail migration software advertise capabilities for migrating WorkMail data to Microsoft 365, including mailbox mapping, filtering, scheduling and incremental migration.

Organizations considering Shoviv or any other migration product should independently verify:

• Current supported data types
• Microsoft 365 compatibility
• Amazon WorkMail compatibility
• Mailbox limitations
• Licensing
• Security architecture
• Authentication requirements
• Administrative permissions
• Technical support
• Reporting
• Vendor documentation

A product’s marketing description should not substitute for a pilot migration in the organization’s actual environment.

Managed Migration Services

Organizations with complex environments or limited internal migration experience may consider a managed migration provider.

This can be useful where migration involves:

• Large user populations
• Complex domains
• Compliance requirements
• Tight cutover windows
• Multiple data types
• Legacy systems
• Limited internal IT resources

Before selecting a managed provider, define responsibilities clearly and understand how the provider will access, process and protect organizational data.

6. Map Source and Destination Mailboxes

Mailbox mapping ensures that source data reaches the correct Microsoft 365 account.

Before migration, create a mapping table such as:

Check for:

• Renamed users
• Changed email addresses
• Aliases
• Disabled accounts
• Departed employees
• Shared mailboxes
• Duplicate addresses
• Special-purpose mailboxes

Resolve mapping conflicts before beginning bulk migration.

7. Run a Pilot Migration

Do not make the entire organization your test group.

Select a small but representative pilot group.

Include users with different characteristics where possible, such as:

• Small mailbox
• Large mailbox
• Multiple folders
• Calendar usage
• Contact usage
• Mobile access
• Desktop client access
• Delegated or shared access

After the pilot, verify:

• Message counts
• Folder structures
• Attachments
• Required contacts
• Required calendar items
• Dates and timestamps
• Search
• Mailbox access
• Send/receive functionality
• User experience

Record problems and adjust the migration process before expanding it to the wider organization.

8. Plan the Main Migration

Once the pilot succeeds, organize the remaining users into manageable migration batches.

Batching can make it easier to:

• Monitor progress
• Troubleshoot failures
• Communicate with users
• Control migration load
• Validate results
• Roll back or pause where technically possible

Avoid assuming that every mailbox will migrate at the same speed.

Migration duration can be influenced by mailbox size, item count, network conditions, service throttling, migration method and other technical factors.

Build sufficient contingency time into the schedule.

9. Plan DNS and Mail-Flow Cutover

Moving historical mailbox data does not automatically redirect new email to Microsoft 365.

Organizations need a separate mail-flow and DNS cutover plan.

Depending on the environment, administrators may need to review or update applicable:

• MX records
• SPF configuration
• DKIM
• DMARC
• Domain verification
• Autodiscover or client configuration
• Mail-flow connectors
• Applications or devices sending email

Use current Microsoft 365 documentation for the organization’s specific tenant and domain configuration rather than copying DNS values from unrelated migration guides.

Before cutover, determine:

• When new mail should begin arriving in Microsoft 365
• Who will make DNS changes
• How changes will be validated
• Whether a final incremental migration is required
• How mail arriving during the transition will be reconciled
• When users should switch email clients
• How long the source environment should remain operational

Mail-flow planning is one of the most important components of business continuity during migration.

10. Use Incremental or Final Synchronization Where Appropriate

Depending on the selected migration method, organizations may perform an initial migration while users continue working in Amazon WorkMail.

If supported, a subsequent incremental or delta migration can transfer eligible items created or changed after the earlier migration.

This can reduce the gap between the initial data transfer and final cutover.

However, incremental migration capabilities differ by tool and method.

Verify how the selected approach identifies:

• Previously migrated items
• New messages
• Changed items
• Deleted items
• Duplicate items

Do not assume all migration tools handle these scenarios identically.

11. Validate the Migration

Migration is not complete when the progress bar reaches 100%.

Validation should confirm that required data and functionality are actually available.

Depending on scope, check:

Mail

• Expected messages
• Folder hierarchy
• Attachments
• Sent items
• Historical messages

Other Data

Where supported and included:

• Contacts
• Calendars
• Shared resources
• Relevant permissions

Functionality

• Internal email delivery
• External email delivery
• Replies
• Forwarding
• Mobile access
• Desktop client access
• Search
• Shared mailbox access where applicable

Administration

• User licensing
• Security policies
• Groups
• Domain configuration
• Mail flow

Document discrepancies and resolve significant issues before decommissioning Amazon WorkMail.

12. Evaluate Security Before Using Third-Party Migration Tools

A migration product may require access to both the source and destination environments.

That makes security evaluation essential.

Before authorizing a third-party tool, understand:

• Authentication method
• Administrative permissions requested
• Credential handling
• Encryption in transit
• Whether data is temporarily stored
• Where temporary data is stored
• Data-retention practices
• Logging
• Vendor access
• Security documentation
• Incident-response procedures
• How access is revoked after migration

Follow the principle of least privilege wherever technically practical.

After migration, remove temporary permissions, credentials, application registrations or administrative access that are no longer required.

13. Communicate With Users

Even a technically successful migration can create disruption if users are unprepared.

Tell employees:

• When migration will occur
• Whether they need to stop using WorkMail temporarily
• When they should begin using Microsoft 365
• Whether passwords or authentication processes will change
• How to configure supported devices
• Where to report missing data
• Where to obtain technical support

Provide concise instructions rather than expecting users to understand the underlying migration technology.

14. Provide Post-Migration Support

Plan a stabilization period after cutover.

Common user issues can involve:

• Login
• Multi-factor authentication
• Outlook configuration
• Mobile devices
• Missing folders
• Search
• Contacts
• Calendars
• Shared mailboxes
• Distribution groups
• Applications sending email

Establish an escalation process so problems can be identified and resolved quickly.

15. Do Not Decommission WorkMail Immediately

Avoid shutting down the source environment simply because the first migration run has completed.

Before decommissioning, confirm:

☐ Required users have migrated
☐ Required mailbox data has been verified
☐ Required contacts/calendars have been addressed
☐ Mail flow is operating correctly
☐ DNS changes have been validated
☐ Users can access Microsoft 365
☐ Shared resources have been addressed
☐ Required exports/backups have completed
☐ Compliance/retention requirements have been reviewed
☐ Significant migration errors have been resolved
☐ Post-migration support is operational

Only then should the organization proceed with final WorkMail retirement according to its migration plan.

Suggested Migration Timeline

A structured timeline can help organizations avoid concentrating too much work near the AWS deadline.

Organizations should determine their own dates based on size and complexity, but the objective should be to leave meaningful contingency time before March 31, 2027.

Amazon WorkMail to Microsoft 365 Migration Checklist

Discovery

☐ Inventory users and mailboxes
☐ Record mailbox sizes
☐ Identify domains and aliases
☐ Identify groups/shared resources
☐ Determine required data types
☐ Review retention/compliance requirements

Microsoft 365 Preparation

☐ Create/synchronize identities
☐ Assign required licenses
☐ Provision mailboxes
☐ Verify domains
☐ Configure security requirements
☐ Prepare required groups/resources

Migration

☐ Select migration approach
☐ Verify supported data types
☐ Map source and destination users
☐ Establish export/backup process
☐ Run pilot migration
☐ Review pilot results
☐ Migrate remaining users
☐ Perform final/incremental synchronization where applicable

Cutover

☐ Prepare DNS/mail-flow changes
☐ Update applicable records
☐ Verify inbound mail
☐ Verify outbound mail
☐ Update user clients
☐ Monitor delivery

Validation

☐ Verify messages
☐ Verify folders
☐ Verify attachments
☐ Verify contacts/calendars where included
☐ Verify shared resources
☐ Verify user access
☐ Resolve migration errors

Closure

☐ Complete required data exports
☐ Remove temporary migration permissions
☐ Confirm support readiness
☐ Obtain migration sign-off
☐ Decommission WorkMail only after verification

Final Thoughts

Amazon WorkMail’s March 31, 2027 end-of-support date gives existing customers a defined migration deadline.

The most important decision is not simply which migration tool to use. Organizations first need to understand their existing WorkMail environment, determine which data and services must be preserved, prepare Microsoft 365 correctly, select an appropriate migration method and test the complete process before final cutover.

Native approaches, third-party migration tools and managed services can all be appropriate depending on organizational requirements.

Regardless of the method chosen, the principles remain the same:

Inventory. Prepare. Protect. Pilot. Migrate. Cut over. Validate.

Starting early gives IT teams time to solve unexpected problems without putting business communication at unnecessary risk.

Organizations should complete and validate their migration with sufficient contingency time before AWS ends Amazon WorkMail support on March 31, 2027.

Frequently Asked Questions

When will Amazon WorkMail shut down?

AWS has announced that Amazon WorkMail will reach end of support on March 31, 2027. Existing customers can continue using the service until that date.

When did Amazon WorkMail stop accepting new customers?

According to AWS, Amazon WorkMail stopped accepting new customers beginning April 30, 2026.

Can Amazon WorkMail be migrated to Microsoft 365?

Organizations can migrate from Amazon WorkMail to Microsoft 365 using an approach appropriate to their environment. The exact process and supported data types depend on the migration method or tool selected.

Does migrating email automatically migrate contacts and calendars?

Not necessarily. Supported data types vary by migration approach. Organizations should confirm whether their selected method supports email, contacts, calendars and any other required data before beginning migration.

Should organizations export WorkMail data before migration?

AWS provides mailbox-export capabilities for Amazon WorkMail. Organizations should determine their backup, retention and export requirements and independently preserve required information before decommissioning the source environment.

Should I use a third-party Amazon WorkMail migration tool?

Third-party migration software can be useful where an organization needs features such as mailbox mapping, batch processing, filtering, scheduling or incremental migration. Evaluate any product for compatibility, supported data types, security, licensing, administrative requirements and support before deployment.

When should Amazon WorkMail be decommissioned?

Do not decommission the source environment until required data has been migrated and verified, Microsoft 365 mail flow is functioning correctly, users can access the destination environment, required exports are complete and significant migration issues have been resolved.

Technical Note: Cloud-service capabilities, migration procedures and Microsoft 365 configuration requirements can change. Administrators should verify current AWS and Microsoft documentation before performing production migration or DNS changes.

Comments (0 Comments)