Cloud Migration Strategy: The 7 R’s, Phases & Checklist

Cloud migrations rarely fail on technology. They fail on sequencing, when the wrong workload moves first and the program spends the next eight months recovering from a decision made in week two.

A cloud migration strategy is the decision framework that determines which workloads move to the cloud, in what order, using which migration approach, and what completion looks like for each one. It covers seven standard migration paths, a phased execution sequence, and the cost and risk model behind every decision.

This guide covers the complete cloud migration process: the seven approaches and the conditions that make each one appropriate, the four phases of execution, how to construct the plan, and the areas that most often break during data and analytics migrations.

What is a cloud migration strategy?

A cloud migration strategy is distinct from a cloud migration plan, and the difference matters more than it first appears. The strategy establishes why the organization is migrating and which workloads are in scope. The plan defines how and when each one moves.

Strategy work comes first. It begins with a complete inventory of the current estate, followed by scoring each workload against business value and technical complexity, then assigning every workload a migration path. Some applications move without modification. Others are rebuilt. A meaningful proportion are decommissioned entirely, and that group is consistently larger than initial estimates suggest.

The plan follows. It covers wave sequencing, cutover windows, rollback triggers, and the operational detail of who owns the decision at each gate.

Organizations that skip the strategy layer tend to encounter the same pattern. The easiest workload migrates first because it was easy rather than because it mattered, and momentum stalls at roughly a third of the estate when the first genuinely complex dependency surfaces. Treating migration as a foundational shift rather than a relocation exercise produces materially better outcomes, a pattern visible across most successful cloud-based data management programs.

What are the 7 types of cloud migration?

The seven cloud migration strategies, commonly referred to as the 7 R’s, provide a shared vocabulary for classifying every workload in an estate. Each approach trades implementation speed against long-term cloud value, and selecting the right cloud migration approach per workload is the single highest-leverage decision in the assessment phase.

1. Rehost (lift and shift)

Rehosting moves a workload onto cloud infrastructure with no changes to application code. It is the fastest and lowest-risk path, and most large-scale migrations rely on it for the bulk of their estate.

Use it when: a data center lease is expiring, the workload is commodity infrastructure, or speed of exit outweighs optimization.

Trade-off: every inefficiency present on-premise transfers with the workload, and the cloud bill will reflect it. A rehosted estate typically requires a deliberate optimization pass within twelve months to realize any cost benefit.

Example: a manufacturing firm with 18 months remaining on a data center lease rehosts 60 internal applications to meet the exit date, then schedules a replatform review for the 15 highest-cost workloads in year two.

2. Relocate

Relocation moves workloads at the hypervisor level without altering the operating system, the application, or day-to-day operations. In practice this usually means shifting a virtualized estate onto a managed equivalent in the cloud, where existing tooling and operational runbooks continue to function unchanged.

Use it when: the estate is already virtualized, the team’s operational model is mature, and the deadline does not permit per-application work.

Trade-off: the existing architecture transfers intact, and licensing models can erode the savings case significantly. Relocation buys time rather than efficiency, and is best treated as a staging step toward replatforming rather than an end state.

Example: a healthcare provider relocates 200 virtual machines ahead of a hardware refresh, then replatforms the database tier over the following two quarters once the immediate deadline has passed.

3. Replatform (lift, tinker, and shift)

Replatforming moves the workload while substituting selected components for managed cloud services. A self-managed database becomes a managed database instance; a self-hosted message queue becomes a managed queue. Application code changes minimally, while operational overhead drops substantially.

Use it when: the workload will remain in service for several years and the operational burden of self-management is measurable.

Trade-off: it requires more upfront engineering than rehosting, and scope has a tendency to expand toward full refactoring once engineers are inside the codebase. This is the most common path for enterprise workloads, and where our AWS cloud services team concentrates the majority of migration effort.

Example: a financial services firm replatforms its reporting database to a managed service, eliminating patching and backup administration while leaving the reporting application itself untouched.

4. Refactor (re-architect)

Refactoring rebuilds the application to operate as a cloud-native system, typically using microservices, serverless components, and event-driven patterns.

Use it when: the application is strategically important and its current architecture is actively constraining the business, whether through scaling limits, release velocity, or an inability to support new requirements.

Trade-off: the highest cost and longest timeline of any approach. Refactoring is justified for a small number of applications and rarely more.

Example: a retailer refactors its order management system to handle seasonal traffic peaks that its monolithic architecture could not absorb without substantial over-provisioning.

5. Repurchase (drop and shop)

Repurchasing retires a custom application and replaces it with a commercial SaaS product.

Use it when: the application supports a commodity business function where custom logic provides no competitive advantage. Legacy CRM, HR, and service desk systems are frequent candidates.

Trade-off: technically straightforward, organizationally difficult. Data migration and user change management carry more risk than the platform switch itself.

Example: a professional services firm replaces a fifteen-year-old internal ticketing system with a SaaS platform, and spends more effort on data mapping and user training than on the migration itself.

6. Retire

Retirement decommissions the workload entirely.

Use it when: the application has no active users, no identifiable business owner, or a successor system already in production.

Trade-off: none, provided the analysis is thorough. Every retired workload is one the organization never pays to migrate, operate, secure, or support again.

Example: an estate assessment covering 140 applications identifies 31 with no recorded access in 90 days. Retiring them reduces migration scope by more than a fifth before any work begins.

7. Retain (revisit)

Retention leaves the workload in its current environment for a defined period.

Use it when: regulatory constraints, hardware dependencies, or vendor contracts prevent movement in the current cycle.

Trade-off: retention is a legitimate decision, but it requires a documented review date. Without one, temporary retention becomes permanent by default and the organization ends up operating two environments indefinitely.

Example: a logistics operator retains a warehouse control system tied to on-site hardware, with a review scheduled to coincide with the equipment replacement cycle.

Comparing the seven approaches

Reference frameworks published by AWS and other major providers use the same taxonomy, which makes the vocabulary portable across vendors and useful for internal alignment.

What are the phases of cloud migration?

The steps for cloud migration group into four phases. The sequence is more important than the terminology, and compressing any phase tends to surface as cost or incident volume later in the program.

Phase 1: Assess (4 to 8 weeks)

Build a complete application inventory and map dependencies against observed network behavior rather than existing documentation. Score each workload on business criticality, technical debt, compliance exposure, and current operating cost, then assign a migration path to every item.

The output is a scored estate with 7 R’s classifications and an initial cost model. Undocumented dependencies discovered at this stage are inexpensive. Discovered during cutover, they are not.

Phase 2: Plan (4 to 6 weeks)

Group workloads into migration waves and define the target architecture. Establish the cloud landing zone with identity, network, and security baselines in place before any workload moves.

Wave one should be low-risk but substantive, a workload real enough to validate the landing zone and contained enough that a delay carries no revenue impact. Governance applied at this stage is considerably cheaper than governance retrofitted later, and this is particularly true in Azure cloud services, where policy structure shapes everything built on top of it.

Phase 3: Migrate (3 to 18 months)

Execute wave by wave. Each wave follows a consistent loop: replicate, test in the target environment, validate against the source, cut over, monitor, and formally close out.

A wave is complete when its validation criteria have been signed off, not when the last server responds. Beginning a subsequent wave against an unclosed one compounds risk across both.

Phase 4: Optimize (ongoing)

This phase is frequently reduced when budgets tighten, and it is where the financial return actually materializes. Right-size compute against observed demand rather than legacy specifications, apply storage tiering by access pattern, and shut down non-production environments outside working hours.

Most estates remain measurably over-provisioned for the first six months following migration, because instances are initially sized to match on-premise hardware rather than actual utilization.

Microsoft’s Cloud Adoption Framework follows a comparable phase structure and is useful as a vendor-aligned reference when socializing the approach internally.

How do you build a cloud migration plan?

A cloud migration plan converts strategy into an executable roadmap. Cloud migration planning rests on five components.

Wave design. Group applications by dependency cluster rather than by business unit. Systems with high-frequency interdependencies migrate together, or the program builds a temporary integration bridge that tends to remain in place far longer than intended.

Cutover windows. Select these from the business calendar rather than the engineering calendar. Retail order systems do not migrate in November, and financial reporting platforms do not migrate at period close.

Rollback triggers. Define the specific, measurable conditions that abort a cutover, and define them before the cutover begins. A threshold such as transaction latency exceeding 400ms for ten consecutive minutes is actionable. A subjective assessment made under pressure at 3am is not.

Validation criteria. Document what successful migration means for each workload in quantitative terms: row counts, reconciliation outputs, and performance baselines measured against pre-migration figures.

Ownership. Assign one named individual per wave with authority to proceed or halt. Distributed decision-making does not function under cutover conditions.

Data-intensive workloads require a parallel planning track alongside the application plan, which we examine in detail in our strategic guide to mapping a modern data migration process.

Cloud migration checklist

Before migration

• Complete application inventory with named business owners for every entry
• Dependency map validated against 30 days of live network traffic
• 7 R’s classification assigned to every workload in scope
• Landing zone operational with identity, network, and logging baselines
• Cost model with per-wave budgets and defined variance thresholds
• Backup and restore tested end to end within the target environment
• Rollback procedure documented and rehearsed
• Data residency, retention, and compliance requirements confirmed in writing

During migration

• Source and target systems running in parallel throughout the validation window
• Reconciliation reports executed and formally signed off per workload
• Performance baselines compared against pre-migration measurements
• Cutover checklist executed by the named wave owner
• Monitoring and alerting operational before cutover, not after

After migration

• Source system decommissioned on a committed date
• Compute right-sized against 30 days of observed usage
• Storage tiering applied to cold and archival data
• Tagging and cost allocation verified by business unit
• Lessons documented before the wave team is reassigned

Recovery testing warrants particular attention, since a restore procedure that has never been executed in the target environment is an assumption rather than a control. Our breakdown of the essential components of a data backup and recovery strategy outlines what to verify before cutover.

How do you migrate applications to the cloud?

Application migration to the cloud is where estimates most often prove optimistic, because the application itself is rarely the difficult component. The integrations surrounding it are.

Classify by architecture first. A stateless web application with a clean API boundary can be rehosted within days. A monolithic system with a shared database, hard-coded file paths, and scheduled processes that have not been reviewed in years presents a substantially different problem.

Map dependencies against observed behavior. Run network flow analysis across a minimum of 30 days. Monthly batch processes and quarterly reporting jobs will not appear in a two-week capture, and these are precisely the integrations that fail silently after cutover.

Address state before migration, not after. Session state held in application memory, files written to local disk, and hard-coded server references are the three most common causes of failed lift-and-shift attempts. All three are inexpensive to resolve before the move and considerably more expensive afterward.

Select a cutover pattern deliberately. Big-bang cutover is fastest and carries the highest risk. Parallel operation doubles infrastructure cost for a defined window but permits validation against production traffic. Phased user migration provides a genuine rollback path where the application architecture supports it. For revenue-critical enterprise applications, parallel operation almost always justifies the additional expenditure.

Test integrations, not only the application. A common post-migration failure pattern involves an application that starts correctly while a downstream file transfer to a partner system fails, because the source address changed and the partner was never notified. Integration failures dominate post-cutover incident volume.

Google’s migration architecture guidance provides a useful cross-check on cutover patterns, and teams operating on Google Cloud services can map workloads directly against it.

How do you migrate data and analytics workloads?

Cloud data migration operates under different rules from application migration, and this is the area most migration plans under-resource. An application either functions or it does not. A data platform can migrate apparently successfully and remain quietly incorrect for months.

Schema translation is not replication. Data types do not map cleanly between platforms. Decimal precision, date and timestamp handling, string collation, and NULL semantics all differ. A numeric column that loses precision during translation raises no error. It simply produces financial reporting that is incorrect by a margin that compounds over time.

Determine the load pattern early. Bulk cutover requires a freeze window, and for a large warehouse that window may exceed what the business will accept. Incremental replication using change data capture keeps the source system live while the target synchronizes, at the cost of significantly greater engineering effort. Data volume and tolerable downtime govern this decision, and the decision reshapes the entire program timeline.

Validate at three levels. Row counts detect gross failures. Checksums on key columns detect corruption. Business-logic reconciliation, in which identical reports are executed against both platforms and their outputs compared, detects the subtle errors the first two methods miss. Only the third method identifies a join that has silently changed behavior.

Inventory every downstream consumer. Each dashboard, scheduled extract, spreadsheet connection, and departmental report reading from the source requires identification and repointing. Business intelligence layers are typically the last components verified and the first that users notice. A report that renders successfully while returning stale figures is more damaging than one that fails outright, because failure prompts investigation and stale data does not.

Platform selection shapes each of these decisions. The differences in how each warehouse handles concurrency, storage separation, and pricing are examined in our comparison of cloud data warehouses across Amazon, Azure, Google, and Snowflake.

How do you migrate infrastructure to the cloud?

Cloud infrastructure migration addresses the layer beneath the applications: networking, identity, storage, and the security controls governing them.

Establish the landing zone before any workload moves. Network topology, subnet design, and connectivity to remaining on-premise systems should be operational and tested first. Identity federation follows, since access management retrofitted onto a partially migrated estate represents a material security exposure.

Storage is where unanticipated costs concentrate. On-premise capacity is a sunk cost; in the cloud, each tier carries distinct pricing and retrieval charges. Classify data by access pattern before migration rather than after the first invoice.

Organizations building this foundation typically pair it with a data platform design, which is where our data engineering services most often engage first.

What does cloud migration cost?

Migration cost divides into three categories, and organizations reliably budget for only one of them.

One-time migration cost. This covers assessment, tooling, engineering effort, parallel-run overhead, and testing. For a mid-size estate of 100 to 300 applications, this typically ranges from several hundred thousand to low seven figures, depending on the proportion of refactoring in scope. Rehost-weighted programs occupy the lower end; refactor-weighted programs exceed the upper end.

Year-one run cost. Almost always higher than the on-premise cost it replaces, because workloads are initially provisioned to match legacy specifications rather than observed demand. This is expected and temporary, but it must appear in the business case or the program will be characterized as a failure by the fourth month.

Optimization savings from year two. Right-sizing, committed-use pricing, storage tiering, and decommissioning idle environments. This is where the return on investment actually closes.

How to frame this internally. The business case that survives a finance review is rarely built on infrastructure savings alone, because year one usually costs more than what it replaced. The stronger version stacks four elements: the avoided cost of a hardware refresh or lease renewal, the engineering hours currently consumed by patching and capacity management, the revenue exposure of operating critical systems on hardware beyond its support window, and the delivery speed gained when provisioning moves from weeks to minutes. Quantify each one. Three of those four are easier to defend in a budget review than the raw compute line, and together they generally carry the approval.

[VERIFY: insert a current cloud spend or waste statistic from the latest Flexera State of the Cloud report, or remove this sentence.]

The budgeting error to avoid is treating optimization as an optional fourth phase. Priced into the program from the outset, it funds a meaningful portion of the migration itself.

Common cloud migration challenges and how to overcome them

Undocumented dependencies. The most frequent cause of failed cutovers. Resolve through 30-day network flow analysis, validated against application owner interviews rather than substituted for them.

Scope expansion from replatform into refactor. Engineers working inside a codebase identify architectural improvements, and a six-week engagement becomes a six-month one. Resolve by locking the migration path per workload at assessment and requiring formal change control to alter it.

Security controls that do not translate. Perimeter-based security assumptions break in a cloud model where identity functions as the perimeter. Resolve by designing identity and access controls into the landing zone, and reviewing them against the specific exposures covered in our guide to cloud database security best practices.

Cost overruns in month two. Data egress charges, over-provisioned compute, and non-production environments running continuously. Resolve through tagging and cost allocation enforced from day one, with budget alerts configured per wave.

Absent decommission dates. Source systems remain online as a precaution and the organization funds both environments indefinitely. Resolve by agreeing a fixed decommission date, signed by the business owner, before the wave begins.

Compliance requirements surfaced late. Data residency, retention, and audit obligations discovered mid-migration force architectural rework. Resolve through legal and compliance sign-off on the target architecture during phase one.

Analyst coverage from Gartner consistently identifies governance gaps rather than technology selection as the dominant cause of cloud program overrun. [VERIFY: replace with a specific current Gartner finding or remove this sentence.]

Cloud migration strategy example

The following is a composite scenario constructed from patterns common to mid-market insurance carriers. It is illustrative rather than an account of a single engagement.

Starting position. A regional insurance carrier operating 140 applications across two data centers, with one lease expiring in 14 months. A 12TB on-premise data warehouse supported approximately 400 reports, and no one could confirm how many were actively used.

Assessment findings. Of the 140 applications, 31 showed no user access within 90 days and were classified retire. A further 12 were contractually locked and classified retain. That reduced the in-scope estate to 97 and reset the entire scope conversation before any workload was touched.

Path allocation. 62 rehost, 28 replatform, 4 refactor, 3 repurchase. The four refactor candidates were the customer-facing quote and policy systems, where architectural constraints were directly limiting product changes. Everything else moved unchanged or with a managed-service substitution.

Sequencing. Six waves. Wave one comprised internal tooling, selected because it was substantive enough to validate the landing zone and low-impact enough that a delay carried no revenue consequence. The data warehouse migrated in wave four, deliberately positioned late, once the applications feeding it were already stable in the target environment.

What went wrong. Report validation. Of the 400 reports, 310 proved to be actively used, and 40 of those returned different figures after migration. The root cause was timestamp handling: the source and target platforms treated timezone-naive timestamps differently, shifting period boundaries on month-end reporting by several hours. Every report rendered without error. The figures were quietly incorrect.

The lesson. Row counts passed. Checksums passed. Only executing identical reports against both platforms and comparing outputs identified the discrepancy. Business-logic reconciliation is not an optional third validation layer. On any data platform migration, it is the only layer that detects the failures users will eventually notice.

Frequently asked questions

What is cloud migration?

Cloud migration is the process of moving applications, data, and infrastructure from on-premise environments into the cloud, or between cloud providers. A cloud migration follows one of seven standard paths per workload and typically runs in waves across 12 to 24 months for a mid-size estate.

What is the difference between cloud migration and cloud adoption?

Cloud migration is the act of moving existing workloads from one environment to the cloud. Cloud adoption is the broader organizational shift covering operating model, skills, governance, and cost management. Migration is a project with a defined end date. Adoption is a capability change that continues well after the final workload moves.

How long does a cloud migration take?

For a mid-size estate of 100 to 300 applications, expect 12 to 24 months from assessment through final decommission. Assessment requires 4 to 8 weeks, planning a further 4 to 6, and execution runs in waves across the remaining period. Refactor-weighted programs extend beyond that range.

Which cloud migration strategy is cheapest?

Retire is cheapest, because a decommissioned workload costs nothing to move, operate, or support. Among workloads that must migrate, rehost carries the lowest upfront cost and the highest ongoing run cost. Replatform costs more initially and typically wins on total cost of ownership within 18 months.

What are the 7 R’s of cloud migration?

Rehost, relocate, replatform, refactor, repurchase, retire, and retain. Each represents a different migration path for a given workload, trading implementation effort against long-term cloud value. Every application in the estate should be assigned one during the assessment phase.

Can you migrate to the cloud without downtime?

For most workloads, yes, using parallel operation or incremental replication with change data capture. Both keep the source system live while the target synchronizes. Zero-downtime migration costs more in engineering effort and duplicate infrastructure during transition, so it is normally reserved for revenue-critical systems.

What is a cloud migration assessment?

A structured evaluation of the existing estate producing an application inventory, a validated dependency map, a 7 R’s classification per workload, and a cost model. It is the first phase of any migration program and typically runs 4 to 8 weeks.

What is the biggest risk in cloud migration?

Undocumented dependencies. A workload that appears self-contained often supports a scheduled process, a partner integration, or a report that executes only monthly. These fail after cutover rather than during it, which makes them harder to trace and more costly to resolve.

Planning a migration?

Most of the risk in a cloud migration is determined within the first eight weeks, before any workload moves. If you are scoping a program and want a second read on workload classification, dependency mapping, or data platform sequencing, our cloud engineering team can work through the assessment with you. Tell us what you are running today and where the deadline sits.