Cloud Migration Best Practices: A Technical Guide for Moving Workloads to AWS or Azure

The "6 Rs" framework for cloud migration remains the best starting point for any migration planning: Rehost (lift and shift), Replatform (lift and optimise), Repurchase (move to SaaS), Refactor (re-architect), Retire, and Retain. Most enterprise migrations use a mix of all six for different workloads — and the choice for each workload should be intentional, not defaulted.

Lift-and-shift (rehost) is the fastest migration strategy and the one most often chosen under time pressure. It moves an on-premises virtual machine directly to a cloud instance without modification. The advantages are speed and familiarity — your applications run in the same configuration they did on-premises. The disadvantages are that you carry forward all the technical debt and architectural limitations of the original system, and you miss the opportunity to improve reliability, security, and cost efficiency that cloud-native architectures enable.

No migration should begin without a thorough discovery phase. The goal is a complete, accurate inventory of: every server and workload (including shadow IT that may not be in the CMDB), all application dependencies and communication patterns, all data flows and data residency requirements, and the performance and availability requirements for each workload.

AWS Migration Hub, Azure Migrate, and third-party tools like Cloudamize and MovePilot can automate much of the discovery work, deploying lightweight agents on existing servers to capture real-time dependency mapping and performance data over a 2–4-week assessment period. The output is a migration wave plan — workloads grouped into logical migration sequences where dependencies are respected.

The discovery phase also surfaces surprises: undocumented dependencies between applications, legacy integrations that connect to systems nobody remembered, data stored in unexpected locations. Better to find these in discovery than mid-migration.

Before migrating any production workloads, establish your cloud landing zone — the foundational account structure, network architecture, identity configuration, and security baseline that everything else will run within. Attempting to migrate workloads and define the landing zone simultaneously creates chaos.

The landing zone should establish: account vending (how new cloud accounts are created and configured), network design (VPC structure, subnets, transit gateway or hub-spoke peering), identity (SSO with your on-premises Active Directory or Azure AD, role-based access control), and security guardrails (AWS Control Tower SCPs or Azure Policy assignments that enforce your security baseline across all accounts).

Security in the cloud is a shared responsibility model, but many organisations do not fully understand what they are responsible for. The cloud provider secures the infrastructure — the physical data centres, the hypervisor, the managed service plumbing. You are responsible for everything on top: operating system configuration and patching, application security, identity and access management, data encryption, network security groups, and logging and monitoring. A secure migration means designing these controls into the architecture from day one, not retrofitting them later.

Cloud cost overruns are one of the most common post-migration complaints. The flexibility that makes cloud powerful — the ability to provision resources in seconds — also makes it easy to accumulate costs that nobody notices until the invoice arrives. Establishing cost governance from the first day of cloud usage is essential.

Tag every resource with mandatory tags: environment (production, staging, dev), application, owner, and cost centre. Without tagging, cost attribution becomes impossible as the estate grows. Configure AWS Cost Explorer or Azure Cost Management with budget alerts that notify the responsible team when spending exceeds expected thresholds.

Right-sizing is the most impactful cost optimisation action post-migration. Lift-and-shift migrations typically overprovision cloud instances to match on-premises server sizing — which was itself often over-provisioned. After running in the cloud for 4–8 weeks, the actual CPU and memory utilisation data is available; right-sizing to instances that match actual utilisation typically reduces compute costs by 30–50% without any performance impact.