One thing I have learned from years of moving workloads into Azure and AWS is that migration is rarely just a server-move exercise. Getting a virtual machine to boot in the cloud is the easy part, and it is also the part that fools people into thinking the job is done. The difficult part is understanding what breaks when an on-premises workload moves into a different network, a different identity model, a different security posture and a different operational reality. A successful migration is not measured by whether the VM started. It is measured by whether the application is secure, connected, performant, observable, recoverable and cost-effective once it is there.
This is the playbook I work through before moving anything, written to be provider-neutral because the shape of the problem is the same on Azure and on AWS even though the service names differ. At the end there is a checklist you can download and use on your own migrations.
The full migration checklist, every consideration below as a tickable list you can take into your own assessment and cutover planning. Provider-neutral, print-ready.
The whole thing follows one arc, and it is the same six phases whichever cloud you are moving to: assess, design, secure, migrate, validate, optimise. Skip any of them and you do not save time, you just move the work to after the incident.
Discovery and dependency mapping
Everything starts with knowing what you actually have, and it is almost always more than the spreadsheet says. Inventory the servers, the applications, the databases, the storage, the scheduled jobs, the APIs, the DNS records, the authentication paths and every external integration. The part people miss is the dependency mapping: what talks to what. A server that looks self-contained is often quietly reliant on a database elsewhere, a directory for authentication, a file share, or a third-party endpoint that no one documented. Both clouds have tooling to help here, Azure Migrate's dependency analysis and, on AWS, the Application Discovery Service feeding Migration Hub, and they surface communication flows that a server inventory will never show you. Move one thing before you understand what it depends on and you will find the dependency the hard way, in production.
Network and connectivity
This is where more migrations break than anywhere else, and usually for unglamorous reasons. Review the IP addressing, the subnet design, the security groups and network ACLs, the route tables, DNS resolution, firewall rules and the connection back to on-premises over VPN or a dedicated link (ExpressRoute on Azure, Direct Connect on AWS). The classic failure is IP address overlap: your on-premises range and your new cloud range collide, and traffic that should route cleanly does not. Incorrect routing and DNS that resolves to the wrong place are the next two. None of these are exotic, and all of them will stop a workload that otherwise booted perfectly. The address plan and the routing design deserve more of your attention than the VM sizing.
Application dependencies, in detail
Before moving a single server, understand precisely what it depends on: database servers, the directory it authenticates against, the APIs it calls, the file shares it mounts, the third-party services it reaches, and the other applications that reach it. This is the same idea as discovery, taken to the level of the individual workload you are about to move. A migration wave that moves an application but leaves a dependency behind, or moves them in the wrong order, produces an app that starts and then fails the first time it tries to do real work.
Choose the right migration strategy
Not every workload should be lifted and shifted, and treating them all the same is how you carry your on-premises problems into the cloud and pay more for the privilege. Evaluate each workload against the recognised strategies, often called the Rs. Rehost is lift and shift, the fastest and the least benefit. Replatform makes small changes on the way, for example moving a database onto a managed service. Refactor re-architects the workload to suit the cloud model properly. Repurchase replaces it with a SaaS equivalent. Retire switches off what is no longer used, which is often the highest-value move nobody makes. And Retain leaves a workload where it is, for now, because not everything should move on this pass. The right answer is per workload and driven by the business requirement, not a blanket policy applied to the whole estate.
Identity and security, before production not after
The identity and trust model is the thing that changes most, and the thing most often left until last. On-premises, a great deal of trust is implicit and granted by being inside the network. In the cloud that assumption is gone, and it has to be rebuilt deliberately. Plan the directory integration (Entra ID on Azure, IAM and an identity source on AWS), the role-based access control, the workload identities (managed identities on Azure, IAM roles on AWS) so that services authenticate without stored credentials, the privileged access model, the secrets and key management (Key Vault, or Secrets Manager and KMS), private connectivity to services (private endpoints, or PrivateLink) so traffic does not traverse the public internet, encryption in transit and at rest, and least privilege throughout. All of this belongs in the design and has to be in place before the production migration, not bolted on after go-live when it is far harder to retrofit.
Data and database migration
Data is where the real risk to the business lives, because it is the part you cannot simply rebuild. For each data store, evaluate compatibility with the target, the volume you have to move and how long that takes, whether you can replicate or synchronise ahead of cutover to shrink the downtime window, the backup and restore approach, and the recovery objectives, how much data you can afford to lose (RPO) and how long you can afford to be down (RTO). Both clouds have database migration services to help, but the tool is the easy choice. For a critical database, the migration approach has to be designed around the application's business requirements and its acceptable downtime, not around what the technology finds convenient.
Performance and right-sizing
Do not blindly replicate your on-premises VM sizes in the cloud. On-premises hardware was often bought years ago, over-provisioned for headroom, and sized for a procurement cycle rather than actual load. Copy those sizes across and you inherit that waste as a monthly bill forever. Instead, measure: CPU, memory, disk IOPS, network utilisation and the application's real behaviour over a representative period, then select cloud resources to match, with room to scale rather than a fixed over-allocation. Both providers have sizing guidance and advisors to inform this. Right-sizing at migration time is the cheapest cost optimisation you will ever do, because after go-live inertia sets in and the over-sized instances stay.
Cutover and rollback
The cutover is the moment of maximum risk, so it is planned, not improvised. Define the migration waves and their order, the maintenance windows, the validation checkpoints that must pass before you proceed, the DNS changes and when they take effect, the data synchronisation right up to the switch, and, critically, a documented rollback plan for when a wave fails validation. The rollback plan is the one people skip and the one that saves the weekend. If you cannot describe, in advance, exactly how you would put a workload back the way it was, you are not ready to cut it over.
Observability after migration
Observability is part of the migration plan, not something added after the first incident. Before the workload is live, the monitoring, logging, alerting, dashboards and backup validation should already be in place: Azure Monitor, Log Analytics and Application Insights, or CloudWatch and its tracing on AWS. The test of a good migration is not that nothing went wrong, it is that when something does, you can see it, understand it, and recover from a backup you have already proven works. A migrated workload with no observability is a workload you have lost sight of the moment it moves.
Cost and governance, from the beginning
Governance applied from day one is cheap; governance applied to a sprawling, untagged environment months later is a project in itself. From the start, apply consistent tagging so you can attribute cost and ownership, policy guardrails (Azure Policy, or a combination of Service Control Policies and Config on AWS), sensible resource organisation, budgets and alerts, the role-based access model, and active cost monitoring. The goal is simple and often missed: do not migrate off one environment that became hard to manage only to build another one exactly like it in the cloud.
The honest summary
Successful cloud migration is not measured by whether the VM started in Azure or AWS. It is measured by whether the application is secure, connected, performant, observable, recoverable and cost-effective after the move. Everything in this playbook exists to close the gap between those two definitions of done, the easy one that fools you and the real one that holds up. Assess what you have and how it connects, design the network and identity properly, secure it before production, migrate in careful waves with a way back, validate that it truly works, and optimise the cost and governance from the start.
If you take one habit from this, make it dependency mapping before movement and validation after it. Almost every migration that goes badly went wrong because something moved before its dependencies were understood, or was declared done because it booted rather than because it worked.
The full checklist covers every phase above as a tickable list for your own assessment, cutover and post-migration validation, provider-neutral so it works for Azure or AWS.
If you are planning an on-premises to cloud migration and want the assessment, the landing-zone design and the cutover planning done so it holds up afterwards, that is the kind of work I do through Cyber Spartans.