How to Manage AWS Service Discontinuations: A Step-by-Step Migration Guide

Introduction

AWS recently announced the discontinuation of WorkMail and the move of App Runner into maintenance mode, with several other less popular services also entering sunset phases. These changes have sparked debate and concern across the AWS community. If you rely on any of these services, you need a clear plan to transition smoothly. This guide walks you through the process of assessing your dependencies, planning migration, and executing a seamless move to alternative solutions.

What You Need

• An AWS account with access to the services you're migrating from (e.g., WorkMail, App Runner)
• A list of all resources and workloads currently using the affected services
• Backup of critical data (emails, application code, configurations)
• Alternative service options (e.g., Amazon SES for email, AWS Fargate for containerized apps)
• Access to AWS documentation and migration tools (e.g., AWS Migration Hub, CloudFormation templates)
• Communication channels to inform stakeholders about the changes
• A timeline aligned with AWS's sunset deadlines

Step 1: Identify All Affected Services

Start by reviewing AWS announcements and your account dashboard to confirm which services are discontinued or in maintenance. The original announcement specifically mentions WorkMail (discontinued) and App Runner (stopping new customers, moving to maintenance). Check for any other services you use that may be similarly affected. Create a spreadsheet listing each service, its current status, and the sunset timeline.

Use AWS Config or Resource Groups to scan for resources tied to these services. For WorkMail, look for email domains, users, and mailboxes. For App Runner, list all running services and any associated CI/CD pipelines. This step ensures you don't miss any dependencies.

Step 2: Evaluate Impact and Alternatives

For each affected service, assess the business impact. For example:

• WorkMail: Who uses it? What email workflows rely on it? Consider alternatives like Amazon SES, Microsoft 365, or Google Workspace.
• App Runner: What applications are hosted? Can you migrate to AWS Fargate, Amazon ECS, or AWS Lambda? Evaluate migration complexity, cost, and downtime tolerance.

Document the features you need in a replacement. For instance, if you require email archiving and compliance, ensure the alternative supports those. For app runners, check if your current container images and environment variables are compatible with the new platform.

Step 3: Create a Migration Plan

Develop a step-by-step timeline that aligns with AWS's end-of-support dates. Include:

• Data export and backup tasks (e.g., download WorkMail mailboxes using backup tools)
• Testing phase in a staging environment
• Cutover window with minimal downtime
• Rollback plan in case of issues

Prioritize services based on criticality. If App Runner hosts production applications, migrate those first. For WorkMail, schedule migration during low-email periods. Use AWS Migration Hub to track progress.

Step 4: Execute Data Migration

For WorkMail:

1. Export mailboxes using AWS WorkMail API or third-party tools. Save as PST or MBOX files.
2. Import into your new email system. If moving to Amazon SES, configure domain identity and send test emails.
3. Update DNS records (MX, SPF, DKIM) to point to the new provider.

For App Runner:

1. Retrieve container images from Amazon ECR or source repositories.
2. Deploy to AWS Fargate or ECS using the same environment variables and IAM roles.
3. Update application endpoints, load balancers, and any configuration tied to App Runner URLs.

Step 5: Update CI/CD Pipelines and Configurations

Revise any GitHub Actions, CodePipeline, or Jenkins jobs that deploy to App Runner. Replace the deployment target with your new compute service. Also update any infrastructure-as-code (Terraform, CloudFormation) to reflect the new resources. Test the pipeline in a non-production environment to ensure it works.

Step 6: Communicate Changes to Stakeholders

Notify your team, users, and any external parties about the migration. Provide new contact emails or application URLs well in advance. Update documentation and runbooks. Consider setting up email forwarding for WorkMail to the new service for a transition period.

Step 7: Monitor and Validate

After migration, monitor the new services for errors, latency, or missing data. Check email delivery (for mail) and application health endpoints (for apps). Run a full regression test. Use AWS CloudWatch to set up alerts. If issues arise, refer to your rollback plan.

Tips for a Smooth Transition

• Backup early and often: Download data from WorkMail before the service becomes read-only. For App Runner, snapshot your environment variables and logs.
• Test in a sandbox: Try the new service with a small subset of users or applications before full cutover.
• Watch for hidden dependencies: Other AWS services (like Lambda functions) might reference App Runner URLs or WorkMail APIs. Update those references.
• Consider cost differences: Some alternatives may have different pricing models. Estimate and budget accordingly.
• Stay informed: AWS may extend deadlines or offer special migration support. Check the AWS Health Dashboard and community forums.
• Use AWS Support: If you have a support plan, engage them for migration assistance, especially for complex environments.

Migrating away from discontinued services is never easy, but with careful planning and step-by-step execution, you can minimize disruption. Focus on thorough testing, communication, and contingency plans. The AWS community is also sharing experiences – leverage those to avoid common pitfalls.