Skip to main content

What is cloud migration?

TL;DR

Cloud migration is the process of moving applications, data, and infrastructure from on-premises or another cloud environment to a target cloud platform (AWS, Azure, GCP, or a combination). The migration decision for each workload follows the 6 Rs framework: rehost (lift-and-shift), replatform, refactor, repurchase (SaaS replacement), retire, or retain. A successful cloud migration is driven by specific business outcomes — cost, scalability, compliance, modernization — not by 'move to cloud' as a goal. The best migrations are phased by application portfolio, with the highest-value and lowest-risk workloads first.

The short version

  • Cloud migration moves workloads from on-prem (or another cloud) to AWS, Azure, or GCP.
  • The 6 Rs framework classifies each workload's migration path.
  • Success is driven by specific business outcomes, not by "move to cloud" as a goal.
  • Phased by application portfolio — highest-value, lowest-risk workloads first.

The longer explanation

What drives a migration decision

Enterprises do not migrate to cloud because cloud is fashionable. They migrate when one or more specific outcomes justify the investment:

  • Cost. Data-center renewal, hardware refresh, or licensing cost hits a decision point.
  • Scalability. Workloads need elasticity the on-prem environment cannot deliver.
  • Compliance. Regulatory or customer requirements favor cloud posture (FedRAMP, HIPAA BAA-available cloud services).
  • Modernization. The application modernization roadmap requires cloud-native services.
  • Consolidation. M&A activity drives consolidation to a single cloud footprint.
  • Talent. The skill market increasingly prefers cloud-native work.
  • Disaster recovery. DR posture improves materially on cloud infrastructure.

The migration strategy should be driven by the specific outcomes — not by an abstract "cloud transformation" goal. Outcome-driven migrations make coherent portfolio decisions; goal-less migrations drift.

The 6 Rs framework

Per AWS's widely adopted framing:

Rehost (lift-and-shift). Move the application to cloud infrastructure with minimal code change. Fastest migration path. Preserves the existing operational posture. The cloud-side wins are limited until a later replatform or refactor.

Replatform. Move with modest changes — swap the database to a managed cloud database, move from self-hosted to managed Kubernetes, change from owned VMs to a managed platform. Faster than refactor, more value than rehost.

Refactor. Rewrite the application (or significant portions) for cloud-native architecture — microservices, managed services, event-driven. Highest cost, highest potential value. Appropriate for applications where the business case justifies the investment.

Repurchase. Replace the application with a SaaS alternative. Common for email, CRM, ERP, HR systems. Moves the operational burden off the enterprise entirely.

Retire. Decommission. A surprising fraction of enterprise application portfolios are applications nobody actively uses; the migration discovery surfaces them. Retirement is often the highest-ROI outcome.

Retain. Keep on-premises. Appropriate for workloads with low cloud benefit, high migration cost, regulatory constraints, or latency requirements the cloud cannot meet. Not every workload belongs in cloud.

Portfolio strategy

A good migration sequences the portfolio by a combination of business value and migration risk:

  • Wave 1. High-value, low-risk workloads. Usually new applications or applications already modern. Fast wins that build migration-team experience and executive confidence.
  • Wave 2. High-value, moderate-risk workloads. Where most of the migration effort lands.
  • Wave 3. Complex migrations — high-risk, regulated, or tightly coupled legacy systems. Done when the team has experience and the supporting infrastructure is in place.
  • Retire and retain. Parallel to the waves; retire what can be retired, leave what stays on-prem.

Most migrations underestimate Wave 3 complexity and rush Wave 1 too aggressively. The well-run migrations invest in discovery and wave planning upfront.

Common failure modes

  • No target state. Migrations without a clearly defined end state drift and never finish.
  • Over-refactoring. Trying to refactor every application during migration. Blows schedule and budget.
  • Under-refactoring. Lifting and shifting a monolith that should have been refactored — the operational issues move to cloud with it.
  • Skipping discovery. Not understanding the dependency graph before migrating. Creates cascading issues when dependencies are discovered mid-wave.
  • Not retiring. Migrating applications that should be retired because retirement feels like failure. It is not; it is the right outcome.
  • No cost controls. Cloud bills surprise enterprises who migrate without FinOps discipline.

How Thoughtwave approaches this

Our modernization and managed services practice delivers cloud migration programs end-to-end — discovery, portfolio strategy, wave planning, execution, and retirement of the legacy environment. We are cloud-neutral across AWS, Azure, and GCP, and we design the migration to serve specific business outcomes, not an abstract "cloud" goal.

For deeper context, see our Application Modernization service and IT Managed Services.

Frequently asked questions

What are the 6 Rs?
Rehost (lift-and-shift without code changes), Replatform (minor changes to take advantage of cloud services), Refactor (rewrite for cloud-native architecture), Repurchase (replace with SaaS), Retire (decommission — often the best outcome for low-value apps), and Retain (keep on-prem for compliance, latency, or cost reasons). Most enterprise portfolios end up with a mix of all six across their applications.
How long does a cloud migration take?
Depends on portfolio size and target state. A focused migration of 50-100 applications typically runs 12-24 months across discovery, wave planning, migration execution, and retirement of the legacy environment. Large enterprise migrations (1000+ apps) can take 3-5 years for full cutover. The pacing is usually driven by application portfolio complexity and internal change capacity, not cloud-side throughput.
Should we refactor during migration or after?
It depends on the application. For applications with clear modernization value (legacy monoliths blocking agility, licensing that flips economics, security posture that needs fundamental change), refactor during. For applications that work fine as-is, rehost and refactor later if justified. The rush to refactor everything during migration is the most common way migrations blow their schedule and budget.

Related resources

RT
Ramesh Thumu

Founder & President, Thoughtwave Software

Reviewed by Thoughtwave Editorial

Last updated April 22, 2026