Migrating to AWS
Many architect scenarios start with "a company is moving its on-premises application to AWS". You need to choose a migration strategy and the right tools for servers, databases and data.
The 7 Rs of migration
| Strategy | What it means | Example |
|---|---|---|
| Retire | Turn it off | Unused legacy app |
| Retain | Keep on-premises for now | Recently upgraded or not ready |
| Rehost ("lift and shift") | Move servers as-is to EC2 | Quick data-centre exit |
| Relocate | Move a whole hypervisor environment without changes | VMware → VMware Cloud on AWS |
| Repurchase ("drop and shop") | Switch to a SaaS product | On-prem CRM → SaaS CRM |
| Replatform ("lift, tinker and shift") | Small optimisations without changing the core architecture | Self-managed MySQL → RDS; app server → Elastic Beanstalk |
| Refactor / re-architect | Redesign as cloud-native | Monolith → microservices on Lambda/ECS + DynamoDB |
"As quickly as possible, minimal changes" → rehost. "Reduce operational overhead without major code changes" → replatform. "Maximise scalability and agility, willing to invest" → refactor.
Discover and plan
| Service | Purpose |
|---|---|
| AWS Application Discovery Service | Collects inventory, configuration, utilisation and dependency data from on-premises servers (agent or agentless) |
| AWS Migration Hub | Single place to track migration progress across tools; strategy recommendations |
Move servers: AWS Application Migration Service (MGN)
The recommended lift-and-shift service: continuously replicates source servers (physical, virtual or other clouds) at block level into AWS, lets you launch test instances, then cut over with minimal downtime.
Move databases: AWS DMS and schema conversion
- DMS — migrate with the source online; full load + change data capture for near-zero-downtime cutovers.
- AWS SCT / DMS Schema Conversion — convert schemas and code for heterogeneous migrations (e.g. Oracle → PostgreSQL).
- See choosing a database for details.
Move VMware workloads
VMware Cloud on AWS runs your vSphere environment on AWS infrastructure — migrate VMs with familiar VMware tools (relocate strategy).
Move data
| Situation | Tool |
|---|---|
| File data over the network | DataSync |
| Ongoing hybrid file/volume/tape access | Storage Gateway |
| Huge datasets, limited bandwidth | Snow Family (offline) |
| SFTP-based partner flows | Transfer Family |
| Dedicated bandwidth for large ongoing transfer | Direct Connect |
See hybrid storage and data transfer.
A typical migration plan
- Assess — inventory with Application Discovery Service; group by dependencies; pick an R for each app.
- Prepare the landing zone — accounts (Control Tower), networking (Transit Gateway, Direct Connect/VPN), identity, logging.
- Migrate in waves — start with low-risk apps; MGN for servers, DMS for databases, DataSync for files.
- Test and cut over — validate, switch DNS (Route 53 weighted for gradual shifts), keep rollback options.
- Optimise — right-size, move to managed services, adopt Savings Plans.
Making legacy apps more reliable without changing them
The exam guide asks how to improve "applications not built for the cloud" when code changes aren't possible:
- Put them behind a load balancer in an Auto Scaling group across AZs (even min=max=1 gives automatic replacement).
- Use RDS Multi-AZ instead of a single database server.
- EC2 auto recovery with CloudWatch alarms.
- RDS Proxy for connection resilience during failover.
- Route 53 health checks and failover.
- Storage Gateway to put legacy file/backup workflows on cloud storage.
Exam patterns
- "Migrate 200 VMs quickly with minimal downtime and no code changes" → Application Migration Service.
- "Migrate an on-prem SQL Server database to RDS with minimal downtime" → DMS with CDC.
- "Understand server dependencies before migrating" → Application Discovery Service.
- "Move the whole vSphere estate without re-platforming" → VMware Cloud on AWS.
Senior Full-Stack Engineer · AI & AWS. I design and run production systems on AWS — serverless, data and AI.