What Are the Steps in Cloud Migration?

Cloud migration steps start with a full inventory. That means every application, dataset, piece of infrastructure, and dependency gets documented, along with performance needs, compliance obligations, and how critical each workload is to the business. Skipping this step tends to catch teams off guard later, usually right around the point where a simple migration turns into a multi-week troubleshooting exercise.
Google Cloud recommends that assessment include workload inventory, dependency cataloging, total cost of ownership analysis, strategy selection, timeline development, and plan validation. Microsoft frames this stage as the point where teams gain visibility into architecture, performance, security, code, and databases. AWS adds that portfolio assessment should be data-backed, combining discovery, analysis, planning, and continuous reassessment as the migration moves forward.
Not every workload should move the same way. Some can rehost with minimal changes. Others need refactoring, or a hybrid setup that keeps certain systems on-premises. For organizations running VMware, this is also where backup methods, RPO and RTO targets, existing DR plans, and the date of the last DR test should be documented before anything else moves forward.
OTAVA’s Cloud Readiness Assessment is built for exactly this starting point.

Once the assessment is done, the next step in cloud migration is designing where everything will live. This covers cloud landing zones, identity and access management, network connectivity, security controls, compliance requirements, data residency, monitoring, and disaster recovery design.
A poor foundation here causes delays, confusion, downtime, and added risk once the migration is underway. Target architecture should be built around scalability, resilience, security, cost control, backup, and disaster recovery, not just where the servers sit. The plan itself should define workload order, sequencing, rollback criteria, and success criteria, with dependent systems grouped and lower-risk workloads scheduled first.
For regulated industries and VMware-heavy environments, this step turns into a business continuity conversation. It stops being purely an infrastructure exercise once recovery and compliance requirements are part of the design.

This is usually the step people picture when they think about migration, but it works best broken into waves rather than one large cutover. Low-risk, low-complexity workloads make good candidates for early pilots, while wave planning groups related systems together instead of forcing a rigid, all-at-once move.

A few common approaches show up repeatedly in this cloud migration step: rehost, replatform, refactor, retain, and retire. Each fits a different workload depending on age, complexity, and business value.

For VMware environments specifically, VMware HCX supports bulk VM migration, workload grouping, and zero-downtime live migration across environments. That said, it’s worth flagging that HCX DR was deprecated as of HCX 4.11 and isn’t recommended for large-scale disaster recovery. Organizations leaning on HCX for migration should look to VMware Site Recovery Manager or VMware’s broader business continuity and disaster recovery tools for anything beyond basic recovery needs.
Execution itself includes provisioning target resources, replicating data, and deploying and configuring applications in the new environment.

Automated or configuration-managed deployments tend to be more repeatable and auditable than manual cutover, which leaves more room for human error.

A workload isn’t migrated once it’s running. It’s migrated once it’s tested, monitored, and recoverable. This validation stage covers functional testing, performance and load testing, security testing, user acceptance testing, and remediation retesting where issues surface.
Teams should also check inventory freshness, downtime exposure, redundancy, and failure modes, and it helps to validate failures in non-critical environments before rolling changes out further. Rollback criteria need to be defined and tested before the final cutover happens, not figured out on the fly if something breaks halfway through a production move.
For VMware workloads, this is where VMware disaster recovery gets validated directly: RPO and RTO targets, backup integrity, failover workflows, recovery site readiness, and failback procedures all need to be confirmed before the environment becomes production-critical.

Migration doesn’t end at cutover. The final step in cloud migration is ongoing: right-sizing resources, strengthening governance, monitoring costs, closing security gaps, and continuing to test recovery processes on a regular schedule.

Optimization works as a loop rather than a one-time task. Assess the environment, set measurable goals, optimize, and repeat. That includes ongoing performance tuning, monitoring, alerting, and cost governance. 

According to Flexera, 73% of organizations now run hybrid cloud estates, and estimated wasted cloud spend rose to 29%, which says a lot about why this step gets skipped less often than it used to.

Many organizations migrate first and only realize afterward that they need managed monitoring, backup, cost control, and ongoing DR testing. Building that into the plan from the start saves a second scramble later.

Recovery planning should start with migration planning, not follow behind it. VMware workloads carry dependencies, storage requirements, and RPO and RTO targets that need to be mapped before anything moves, and disaster recovery should be validated before final cutover rather than treated as a task for later.

VMware HCX supports workload mobility well, but as mentioned earlier, HCX DR is deprecated as of version 4.11 and isn’t built for large DR deployments. VMware Live Recovery, also known as Live Cyber Recovery, is a better fit for VM protection and ransomware recovery, using pilot-light recovery SDDCs to support RTO and RPO planning.

For VMware-heavy environments, migration plans should treat workload mobility and recoverability as one connected effort instead of two separate projects. Handling them separately tends to leave gaps that only show up during an actual outage.

What are the main cloud migration strategies? 

The most common approaches are rehost, replatform, refactor, retain, and retire. Each one fits different workloads depending on complexity, age, and long-term value to the business.

How long does a cloud migration typically take?

Timelines vary widely based on workload count, dependencies, and compliance needs, which is exactly why the assessment and architecture planning steps matter so much before a date gets set.

What’s the difference between cloud migration and disaster recovery? 

Cloud migration moves workloads into a new environment. Disaster recovery protects those workloads once they’re there, with tested plans for restoring operations if something fails.

Is VMware HCX a disaster recovery solution? 

Not fully. HCX supports workload mobility and live migration, but HCX DR was deprecated as of version 4.11 and isn’t recommended for large-scale disaster recovery needs.

OTAVA guides clients through assessment, replication, cutover, and optimization as one connected process, not four disconnected projects. We hold VMware Validated Partner status for Disaster Recovery, and we pair Zerto and Veeam to deliver fast RTO and RPO for VMware environments. Throughout, we maintain HIPAA, HITRUST, SOC 1, 2, 3, PCI-DSS, and ISO 27001 certifications, so compliance stays built in rather than bolted on.

If you’re weighing your next cloud migration step, talk to an OTAVA cloud migration expert about what a phased, recovery-ready migration plan looks like for your environment, including the VMware disaster recovery details you may not have accounted for yet.