Cloud Migration to Azure & AWS: A Practical Guide

A cloud migration succeeds or fails long before the first workload moves. Readiness assessment, landing zone design, and a realistic wave plan account for most of the outcome.

The migrations that go badly rarely go badly during the cutover. They go badly six months later, when the bill is double the business case, half the estate is running on instance types chosen by copying whatever the on-premises server had, and the operations team is supporting two environments instead of one because the last twelve workloads never moved. The technical work was fine. The decisions that preceded it were not made carefully enough.

Assess the estate honestly before deciding anything

Most organizations do not have a reliable inventory of what they run. They have a CMDB that is partly accurate, a virtualisation console that shows what exists but not what it does, and a set of assumptions about dependencies that turn out to be incomplete the first time something is moved.

Discovery has to cover more than hostnames and specs. It needs actual utilization over a meaningful period — a server sized for a peak that occurred in 2019 does not need that capacity in the cloud. It needs dependency mapping, because the application nobody thought was connected to anything invariably calls a database on a host scheduled for a different wave. And it needs an owner for every workload, since the workloads with no identifiable owner are the ones that block a wave for three weeks while someone works out whether they can be switched off.

Licensing deserves its own look. Oracle, SQL Server, and Windows licensing behave differently in cloud environments than on-premises, and the differences can change the economics of a workload substantially. Finding that out during the migration is expensive; finding it out during assessment is just planning.

The 6 Rs, applied with discipline

The 6 Rs — rehost, replatform, refactor, repurchase, retire, retain — remain the cleanest framework for deciding what to do with each workload. Not everything belongs in the cloud, and being honest about that up front saves budget.

In practice the framework gets misused in two directions. Some programmes rehost everything to hit a date, producing a cloud estate with on-premises economics and none of the operational benefits. Others refactor too much, turning a migration into a multi-year application modernisation programme that never finishes and never delivers the datacentre exit that justified it.

Retire and retain are the two options that get skipped, and they are often the highest-value. Every estate contains servers running for no current business reason; switching them off is the cheapest migration available. Equally, a workload with a hard latency dependency on factory equipment, or one whose licensing makes cloud hosting uneconomic, can legitimately stay where it is. A migration plan with zero retained workloads has usually not been examined properly.

The landing zone determines what you can do later

Landing zone design is the least visible and most consequential part of the programme. Account and subscription structure, network topology, identity integration, logging, and policy boundaries are all difficult to change once workloads are running on top of them.

Get the separation model right first. Production, non-production, and shared services should be isolated in a way that makes a mistake in one unable to affect another. Network addressing should account for the growth you expect and the on-premises ranges you will need to connect to — address space collisions discovered mid-programme are painful and entirely predictable.

Identity is where most estates accumulate long-term risk. Federated access with role assumption, no standing administrative credentials, and centralized logging that the account owners cannot alter are worth insisting on from the start. Retrofitting that after two hundred workloads have landed is an order of magnitude harder.

Waves, and the sequencing that makes them work

Group workloads by dependency, not by convenience. Applications that talk to each other should move together or be explicitly designed to work across the boundary during the transition, because the alternative — chatty traffic traversing a site link that was sized for something else — produces performance problems that look like application faults.

Start with something real but not critical. A pure pilot with a test workload teaches you little, because nobody exercises it under load or complains when it is slow. The first wave should be a genuine production workload with a forgiving user base, and the lessons from it should change the plan for the waves that follow. If wave two looks identical to wave one, nobody learned anything.

Every wave needs a rollback position and a defined point at which you stop and use it. Cutover windows create pressure to press on through problems, and a pre-agreed abort criterion is what prevents a difficult night from becoming a multi-day incident.

Day two is where the money is made or lost

Day-two operations are where value is captured or lost: cost governance, security baselines, and platform automation are what turn a migration into a durable capability.

Cost discipline has to start immediately, because the habits set in the first quarter persist. Tagging that is enforced rather than requested, so spend can be attributed to a team or product. Rightsizing based on observed utilization once workloads have run for a few weeks in their new home. Commitment purchases only after usage patterns are stable — buying reserved capacity early against a guess locks in the wrong shape. And a routine for finding orphaned resources, because unattached volumes and forgotten test environments accumulate in every estate.

• Is every resource tagged with an owner and a cost centre, enforced by policy?
• Has anything been rightsized since it landed?
• Are non-production environments shut down outside working hours?
• Do commitments match observed steady-state usage rather than initial estimates?
• Is there a scheduled sweep for unused volumes, IPs, and snapshots?
• Does someone review the bill monthly with authority to act on it?

Security baselines need the same continuous treatment. A policy set applied at landing-zone creation drifts as exceptions are granted, and periodic re-assessment against the baseline is the only way to know where you stand. The same is true of backup and recovery: cloud infrastructure is resilient, which is not the same as backed up, and the distinction matters most on the day someone deletes something they should not have.

If you are sizing up the economics, our cloud cost calculator is a reasonable starting point. You can also read how we handle cloud migration and administration and ongoing Azure and AWS operations.