Migrating to AWS: Steps, Strategies and Pitfalls to Avoid

The usual motivations are the end of life of a host or hardware, the need for elasticity in the face of traffic peaks, access to managed services (databases, queues, object storage) and the desire to reduce manual operations. These are good reasons, provided you write them down.

A migration is not an end in itself. A server moved as-is to the cloud often costs more than before if it is neither right-sized nor automated. The gain comes from using managed services, from automation and from shutting down unnecessary resources, not from a simple change of address.

Set measurable objectives from the start: expected availability, target monthly budget, recovery time in case of incident, regulatory requirements on data location. They will guide every technical decision that follows and allow you to judge the result.

An exhaustive inventory is essential: servers, applications, databases, scheduled jobs, network dependencies, certificates, DNS, third-party integrations. Failed migrations almost always forget a component nobody had documented, such as a script on a backup server or an IP address whitelisted at a partner.

For each application, record its criticality, acceptable maintenance windows, data volume, rate of change and the state of the code. This information determines the migration strategy and the order of migration, and it prevents you from treating every system the same way.

This work leads to an estimate of target costs, using the AWS pricing calculator, and a documented decision per component. AWS provides assessment and tracking tools such as Migration Hub, but the quality of the inventory depends above all on the involvement of the teams that operate the systems.

AWS popularised the "6 Rs" grid to classify migration strategies, now extended to seven with relocate, which moves a virtualisation platform without modifying it. Each application can fall under a different strategy; that is normal and even desirable.

The following table summarises these strategies. In practice, a first pass with rehost or replatform, followed by gradual modernisation once the infrastructure is stable, is the most common path for companies that cannot freeze their activity during the project.

Before migrating anything, set up a clean foundation: a multi-account organisation with at least production and non-production separated, identity management with IAM Identity Center, a VPC network with public and private subnets, centralised logging with CloudTrail, and naming and tagging policies for resources.

This foundation must be described as infrastructure as code (Terraform, OpenTofu or CloudFormation). That is what makes the environment reproducible, auditable and scalable. A foundation built by hand in the console quickly becomes impossible to understand and to evolve safely.

Also define the backup strategy, encryption (KMS) and budget alerts at this stage. It is much harder to add them afterwards to dozens of resources already in production, and that is often where unpleasant surprises come from.

Start with a pilot application, non-critical but representative, to validate the tools and the procedure. Then organise migrations in coherent waves, grouping applications that share dependencies, so that you never cut a link between two systems that talk to each other.

For servers, AWS Application Migration Service replicates disks continuously and allows a cutover with minimal interruption. For databases, AWS Database Migration Service provides continuous replication while the old database stays active, so you can switch once everything has been verified.

Each wave must include functional tests, load tests, a cutover rehearsal and a written rollback plan with a clear trigger criterion. The DNS switch itself must be prepared by lowering the TTL of the records several days in advance.

The first pitfall is cost. Oversized instances, orphaned volumes, test environments never shut down and unanticipated outbound traffic drive the bill up. Systematic tagging, budget alerts and a monthly cost review are essential from the first month.

The second is security: overly broad IAM permissions, exposed S3 buckets, security groups opened to the Internet "temporarily". Adopt least privilege from the start and enable detection services such as GuardDuty, which flag abnormal behaviour.

The third is human. A team used to physical servers must learn new tools, new practices and a new cost logic. Plan for training and support; the success of the migration is also measured by the team's autonomy after the project.

Once applications are stable, right-size resources based on real metrics, use reserved instances or Savings Plans for stable workloads, and automate shutting down non-production environments outside working hours.

This is also the time to start modernising: containerisation, CI/CD, managed databases, observability. The migration created the foundation; the value comes from what you build on top of it in the following months.