AWS migration: a practical guide to getting it right

Most disappointing AWS migrations share a shape. The workloads arrive running the same oversized instances they had on-premise, the bill goes up rather than down, and the promised agility never materialises because the operating model never changed. The technology moved; nothing else did.

This is the arc of a migration that avoids that, in the order the work actually happens.

Phase 1: assess before you plan

Start with discovery, not with a target architecture. You need an inventory of what runs, what it talks to, and how heavily it is used. Tooling can build most of this — AWS Application Discovery Service, or an agent-based scan — but the dependency map always needs human correction, because the connections nobody documented are the ones that break cutovers.

Every workload then gets one of six dispositions, commonly called the 6 Rs:

• Rehost — move as-is. Fastest, and the right call for workloads you intend to retire or rewrite later anyway.
• Replatform — move with a targeted change, such as putting a self-managed database onto RDS. Modest effort, large operational payoff.
• Refactor — rebuild for cloud-native services. Expensive; justify it per workload, never as a blanket policy.
• Repurchase — replace with SaaS. Often the cheapest answer for commodity systems.
• Retire — switch it off. In most estates a meaningful share of servers are running for nobody.
• Retain — leave it where it is. Latency, licensing or regulation sometimes make staying correct.

Attach a cost and effort estimate to each. The output is a wave plan, not a big-bang date.

Phase 2: build the landing zone

Before anything moves, build the foundation it will land on. Retrofitting this later is one of the most expensive mistakes available, because every workload already deployed has to be rewired.

A landing zone covers:

• Account structure under AWS Organizations — separate accounts per environment and per business unit, so blast radius and billing are bounded by design.
• Networking — VPC topology, Transit Gateway for inter-VPC and hybrid routing, and whatever connectivity back to on-premise the cutover needs.
• Identity — IAM Identity Center federated to your existing directory. Nobody should be creating IAM users by hand.
• Guardrails — service control policies that block non-compliant deployments outright, rather than reporting on them afterwards.
• Logging — CloudTrail, Config and centralised log destinations, configured on day one so you have evidence from the first workload rather than the fiftieth.
• Tagging — enforced from the start. Cost attribution is impossible to add retrospectively with any accuracy.

Build all of it as Terraform or CloudFormation that you keep. A landing zone assembled by clicking is a landing zone nobody can reproduce.

Phase 3: migrate in waves

Sequence by dependency, and start with something low-risk. The first wave exists to prove the runbooks, the cutover process and — most importantly — the rollback. If the pilot cannot be rolled back cleanly, the process is not ready for anything that matters.

For each wave:

1. Replicate data continuously ahead of the window, so cutover is a switch rather than a copy.
2. Validate in the target before switching traffic — application health, integration points, batch jobs.
3. Cut over, with the rollback path still live.
4. Hold a validation gate before starting the next wave.

Stateless applications can usually move with no downtime using replication and DNS-based cutover. Stateful databases generally need a short planned window, typically well under an hour with AWS DMS and continuous replication. Establish which of your workloads is which during assessment, not during the weekend.

And do not cut over on a Friday.

Phase 4: optimise, or the bill goes up

This is the phase that gets cut when the programme runs late, and it is the phase that determines whether the migration pays for itself.

Once workloads have run in AWS for a few weeks you have something you never had on-premise: real utilisation data. Use it to right-size compute against measured peaks rather than against the specification someone chose years ago. Move storage to appropriate tiers. Retire the resources that discovery flagged but nobody switched off. Only then buy Savings Plans or Reserved Instances, because committing before right-sizing locks in the waste for one to three years.

Set up budgets and anomaly detection at the same time, so the next surprise is caught in a day rather than at month end.

What tends to go wrong

Underestimating the integration surface. The application is rarely the hard part; the twelve things it talks to usually are.

Treating the landing zone as overhead. Teams under time pressure move the first workloads into a hastily created account and inherit a structural problem that takes years to unpick.

No rollback. A cutover plan without a tested reverse path is a hope, not a plan.

Stopping at cutover. The migration is not finished when the workload runs in AWS. It is finished when it runs at the right size, with monitoring, runbooks and an owner.