A migration is mostly planning. The moves themselves (covered in the next post) are repeatable once you know what exists, what depends on what, and in which order workloads can safely move. This post follows a realistic case: a business application running on Azure for a few years, with web and API tiers on virtual machines and AKS, a SQL database, blob storage, and Entra ID for sign-in, moving to AWS in Mumbai (ap-south-1).
Step 1: Discover what actually runs
Start from facts, not the architecture diagram someone drew two years ago. Pull the inventory from Azure itself:
az extension add --name resource-graph
az graph query -q "resources | summarize count() by type | order by count_ desc" -o table
az vm list -d --query "[].{name:name,size:hardwareProfile.vmSize,os:storageProfile.osDisk.osType,state:powerState,rg:resourceGroup}" -o table
az sql server list -o table
az storage account list --query "[].{name:name,sku:sku.name,kind:kind}" -o tableRecord for each workload the owner, data size, peak and average CPU and memory, operating system and runtime versions, licences (Windows Server and SQL Server licences change the cost picture), and the compliance rules it falls under.
Use dependency data, not guesses. AWS Application Discovery Service (agent-based or the agentless collector) captures network connections between servers, and Azure Monitor VM insights has a dependency map. Either shows the surprises: a reporting job that reads the production database at midnight, or an API that calls an on-premises system over the VPN. Feed the results into AWS Migration Hub for grouping into applications, and into Migration Evaluator for a cost estimate against current Azure spend.
Step 2: Map services and choose a strategy per workload
| Azure | AWS equivalent | Notes |
|---|---|---|
| Virtual Machines | EC2 | Right-size from measured use, not from the Azure SKU |
| Blob Storage | S3 | Map access tiers to S3 Standard, Standard-IA and Glacier classes |
| Azure SQL Database | RDS for SQL Server, or RDS for PostgreSQL after conversion | Changing the engine adds schema and code conversion work |
| SQL Managed Instance | RDS for SQL Server | Closest match when the app uses instance-level features |
| AKS | EKS | Ingress, storage classes and identity integration all change |
| Azure Container Registry | ECR | Re-push images and update pipeline references |
| Entra ID groups and roles | IAM Identity Center and IAM roles | Keep Entra ID as the identity source if staff already use it |
| Azure Monitor / Log Analytics | CloudWatch | Alert rules and dashboards need rebuilding |
| Key Vault | Secrets Manager and KMS | Secrets are re-created, never copied around in files |
| Azure DNS, Front Door | Route 53, CloudFront with AWS WAF | Plan DNS cutover separately from application cutover |
AWS describes seven migration strategies (retire, retain, rehost, relocate, repurchase, replatform, refactor). In practice, decide per workload among three: rehost (lift and shift) for most servers, replatform where a managed service removes real operational work (databases to RDS, for instance), and refactor only when the business case is clear. Change as little as possible during the move, and modernise afterwards.
Step 3: Design the target architecture
flowchart TB
U[Users] --> CF[CloudFront with AWS WAF]
CF --> ALB[Application Load Balancer]
subgraph VPC[Production VPC in ap-south-1]
ALB --> WEB[Web tier<br/>EC2 Auto Scaling]
ALB --> API[API tier<br/>EKS or EC2]
API --> RDS[RDS Multi-AZ<br/>private subnets]
API --> S3[S3 buckets<br/>VPC endpoint]
API --> SM[Secrets Manager]
end
IDC[IAM Identity Center<br/>federated with Entra ID] --> VPC
VPC -.-> CW[CloudWatch and CloudTrail]
AZ[Azure environment<br/>source during migration] <-->|Site-to-Site VPN| VPC
| Layer | Design choice |
|---|---|
| Edge | CloudFront in front of an Application Load Balancer, with AWS WAF managed rules |
| Compute | Auto Scaling groups for stateless tiers; EKS where the workload is already containerised |
| Data | RDS in private subnets, Multi-AZ, automated backups and point-in-time recovery enabled |
| Network | Three Availability Zones, public subnets for load balancers only, VPC endpoints for S3 |
| Identity | IAM Identity Center federated with Entra ID, so staff sign in with existing accounts |
| Observability | CloudWatch metrics and logs, CloudTrail organisation trail, alarms to the on-call channel |
Step 4: Build the landing zone first
Nothing should land in an unprepared account. Use AWS Control Tower (or AWS Organizations with the same layout built by Terraform):
- Separate accounts for production, non-production, shared networking, logging and security, grouped under organisational units, with service control policies blocking risky actions such as disabling CloudTrail.
- A VPC design with CIDR ranges that do not overlap any Azure address space, because the two networks will be connected during migration. Check this before building anything.
- IAM Identity Center with permission sets per team, and no long-lived IAM user keys.
- Tagging rules (application, owner, environment, cost centre) enforced by tag policies, so cost reports work from day one.
- Baseline guardrails: CloudTrail, AWS Config, GuardDuty, and a budget with alerts.
Step 5: Plan waves, success criteria and rollback
Group applications into waves by dependency and risk: start with a low-risk internal application to prove the process, then move the larger systems. Each wave needs a written plan:
| Item | What to define |
|---|---|
| Success criteria | Response time, error rate and data-consistency checks that must pass before cutover |
| Cutover window | Date, duration, freeze period for writes, and who is on call |
| Rollback | The point after which rollback is no longer possible, and how to go back before it |
| Communication | Who is told what, and when |
| Cost check | Expected AWS spend versus Azure spend, including data transfer out of Azure |
Check Azure data transfer (egress) prices early for large data sets, and decide how long Azure will stay running as a fallback, since that overlap is paid for twice.