Migration services and where workloads land
From server migration to workload migration
Section titled “From server migration to workload migration”The instinct in a migration is to move servers: take what is running on a box in the data centre and put the same thing on an EC2 instance. That works, and rehost exists precisely because it works.
The better outcome usually comes from breaking the application into components and asking where each one belongs. A single application server frequently decomposes into a container platform, a managed database, a queue and a scheduled job, and each of those has a target service that removes more operational work than an EC2 instance would.
Common patterns
Section titled “Common patterns”| Component | Lands on | Notes |
|---|---|---|
| Containerised applications | Amazon ECS or Amazon EKS, on Fargate where node management is unwanted | AWS App Runner for a single containerised web service |
| Batch and scheduled jobs | AWS Batch | Batch is a job scheduler, not a general home for containers |
| Java and Tomcat web applications | AWS Elastic Beanstalk | Removes the operational overhead of the app server; scales automatically |
| Small web applications | Amazon Lightsail | Fixed-price, simplified surface |
| Message-handling microservices | Amazon SQS, Amazon EventBridge and AWS Lambda | Event-driven and serverless; decouples the components that used to share a process |
| Relational databases | Amazon RDS or Aurora, via AWS DMS | Heterogeneous moves need schema conversion first |
| File shares | Amazon S3, EFS or FSx, via DataSync | An S3 File Gateway keeps the share interface if needed |
Rehosting: AWS Transform MGN
Section titled “Rehosting: AWS Transform MGN”AWS Transform MGN, formerly AWS Application Migration Service, is the tool for the rehost strategy.
Capabilities
- Windows and Linux server migration
- Sources on-premises, on other cloud providers, or already on AWS
- Continuous block-level replication into a staging area, so cutover is bounded by boot time
- Cross-Region moves, using the same replication mechanism
How a wave runs
- Install the MGN agent on the source servers.
- Continuous block-level replication into the staging area begins.
- Launch test instances from the replicas and validate the application.
- Cut over.
- Redirect traffic and decommission the source.
What it costs. Replication of a given source server is free for 2,160 hours — 90 days continuous — and charged hourly after that. Throughout replication, testing and cutover, normal EC2 and EBS charges apply to the staging, test and target instances. A large wave should be budgeted on that infrastructure, not on the service being free.
Discovery and tracking
Section titled “Discovery and tracking”AWS Transform is the current service for this work. It collects an inventory from multiple sources, analyses VMware and other virtual estates, maps application dependencies, groups servers into prioritised migration waves, and can design and deploy a landing zone and translate an existing network configuration into a VPC architecture. There is no additional charge for the service itself.
What the older services did, and what a reader arriving from an older runbook needs to know, is on their own pages.
Keeping AWS services in the data centre
Section titled “Keeping AWS services in the data centre”Some workloads cannot leave, because of latency to on-premises systems, data residency, or connectivity. Three options put AWS services on the customer’s own floor:
- Amazon ECS Anywhere and Amazon EKS Anywhere run container orchestration on customer hardware, including bare metal, managed with the same tooling as the cloud.
- AWS Outposts delivers AWS-managed infrastructure on-premises, in 42U racks or 2U servers, running EC2, S3 on Outposts, RDS and other services locally while connecting to the full Region. Both form factors can run disconnected for up to seven days.
- Amazon Elastic VMware Service (Amazon EVS) runs a VMware Cloud Foundation environment on EC2 bare metal inside the customer’s own VPC, which keeps the existing virtualisation stack, runbooks and IP addressing during a relocate.
Snowball Edge used to appear on this list for edge compute. It is closed to new customers; Outposts is the replacement AWS names.
What drives the choice
Section titled “What drives the choice”Operational efficiency argues for modernising into managed services during or shortly after the move. Speed to cloud argues for lift-and-shift and a decision to modernise later. Latency and residency argue for keeping some part of the estate on-premises. Most portfolios contain all three, which is why the 7 Rs are applied per application rather than per programme.