On-Prem to AWS: A Practical Migration Checklist

Phase 1 — Inventory (know what you actually have)

You cannot migrate what you haven't catalogued. Before touching AWS, write down:

• Every server / VM, its role, CPU, RAM, disk, and real utilization (not the spec — the actual usage).
• Every application and service, its runtime and version, and who owns it.
• Data stores — databases, file shares, object storage — with sizes and growth rate.
• Inbound and outbound network dependencies: what talks to what, on which ports, and what must reach the public internet.
• Certificates, DNS records, scheduled jobs, and anything with a hard-coded IP address.
• Compliance and data-residency constraints (this decides your AWS region).

Phase 2 — Choose a migration strategy per workload

Not everything moves the same way. For each application, pick one of the "6 Rs":

• Rehost (lift-and-shift) — move the VM as-is to EC2. Fastest, least optimized.
• Replatform — small improvements on the way, e.g. containerize onto ECS/Fargate or move a self-managed database to RDS. Our usual default — most of the benefit, contained risk.
• Repurchase — drop the workload for a managed/SaaS equivalent.
• Refactor — re-architect for cloud-native (serverless, managed services). Highest payoff, highest effort — reserve for the workloads that justify it.
• Retire — a surprising amount of on-prem is servers nobody needs anymore. Find them.
• Retain — some things legitimately stay put, at least for now.

Phase 3 — Design the target architecture

Decide the landing zone before you move a byte:

• Account structure, VPC layout, public vs private subnets across at least two Availability Zones.
• Compute target: EC2 for lift-and-shift, ECS/Fargate for containers, Lambda for event-driven work.
• Managed data services: RDS/Aurora for relational, ElastiCache for cache, S3 for objects and backups.
• Networking: load balancer, VPC endpoints (to avoid NAT and public-IPv4 costs), and how on-prem connects during the transition (VPN or Direct Connect).
• Security posture from day one: IAM least-privilege, security groups, secrets in Secrets Manager, encryption at rest and in transit.
• Observability: CloudWatch metrics, logs, and alarms — set up before cutover, not after.

Phase 4 — Migrate data (usually the long pole)

Data takes longer than compute, always. Plan it first: use AWS Database Migration Service (DMS) for live database replication with minimal downtime, DataSync or Snowball for large file transfers, and set up continuous replication so the final cutover only has to move the last few minutes of changes. Test a full restore in AWS before you trust it.

Phase 5 — Cutover (the part everyone fears — make it boring)

• Run the AWS environment in parallel and validate it thoroughly under real-ish load.
• Write a runbook with an explicit rollback path at every step.
• Lower DNS TTLs a day ahead so the switch propagates fast.
• Do the final data sync, flip DNS, and watch the dashboards you set up in Phase 3.
• Keep the old environment alive (read-only) for a short grace period before decommissioning.

Phase 6 — Optimize (don't skip this)

The lift-and-shift bill is never the final bill. Once stable, right-size instances, add auto-scaling, apply a Compute Savings Plan on the baseline, and close the cost traps (NAT routing, public IPv4, orphaned storage). This is where a migration stops being a cost and starts being a saving — see our companion post on cutting an AWS bill.

The one thing that de-risks all of it

Every failed migration we've seen started with an open-ended quote and a fuzzy scope. The fix is to separate assessment from execution: do the inventory, dependency map, and target design first, as a fixed-price piece of work, and only then commit to the move — with a fixed number in hand. You should know the full cost before spending a rupee on execution.

← Back to the blog