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

Cloud migrations rarely fail on technology. They fail on sequencing, when you move the wrong workload first and spend the next eight months undoing 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.

What is a cloud migration strategy?

A cloud migration strategy is not the same thing as a cloud migration plan, and the difference matters more than it first appears. Your strategy answers why you are migrating and which workloads are in scope. Your plan answers how and when each one moves.

Strategy comes first. Start with a full inventory of your current estate. Score each workload on business value and technical complexity. Then give every workload a migration path. Some applications move untouched. Others get rebuilt. A good share get switched off entirely, and that group is always bigger than your first estimate.

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

Skip the strategy layer and you get the pattern everyone else gets. The easiest workload moves first because it was easy, not because it mattered. Momentum stalls at about a third of the estate. That is when the first hard dependency shows up.

What are the 7 types of cloud migration?

The seven cloud migration strategies, commonly called the 7 Rs, give you a shared vocabulary for classifying every workload in your estate. Each approach trades speed against long-term cloud value, and picking the right one per workload is the most consequential call you make during assessment.

1. Rehost (lift and shift)

Rehosting moves a workload onto cloud infrastructure with no changes to application code. It is the lowest-risk path for most estates, and large migrations lean on it for the bulk of the workload count.

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

Trade-off: every inefficiency you had on-premise transfers with the workload, and your cloud bill will show it. A rehosted estate usually needs a deliberate optimization pass within twelve months before any saving shows up.

Success metric: all in-scope workloads live in the target environment by the exit date, with no SLA degradation.

Example: a manufacturing firm has 18 months left on a data center lease. It rehosts 60 internal apps to meet the exit date, then books a replatform review for the 15 costliest workloads in year two.

2. Relocate

Relocation moves workloads at the hypervisor level without changing the operating system, the app, or how your team runs it day to day. Usually this means shifting a virtualized estate onto a managed equivalent in the cloud, where your existing tooling and runbooks keep working.

Use it when: your estate is already virtualized, your operational model is mature, and the deadline leaves no room for per-application work.

Trade-off: you inherit the same architecture, and licensing can eat into the savings case. Relocation buys you time rather than efficiency. Treat it as a staging step toward replatforming, not an end state.

Success metric: the full estate moved inside the deadline window, with no change to operational runbooks.

3. Replatform (lift, tinker, and shift)

Replatforming moves the workload while swapping selected components for managed cloud services. A self-managed database becomes a managed database instance; a self-hosted message queue becomes a managed queue. App code barely changes. Operational overhead drops sharply.

Use it when: the workload will run for several more years and you can measure the hours your team spends self-managing it.

Trade-off: it needs more upfront engineering than rehosting, and scope tends to creep toward full refactoring once your engineers are inside the code. This is the most common path for enterprise workloads, and where our AWS cloud services team spends most of its migration effort.

Success metric: hours spent on patching, backup, and capacity work down by a set percentage within two quarters.

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

4. Refactor (re-architect)

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

Use it when: the app matters strategically and its current design is holding your business back. Scaling limits, slow releases, or an inability to support what you need next.

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

Success metric: deployment frequency and peak-load headroom, both measured against your pre-migration baseline.

Example: a retailer refactors its order management system to handle seasonal traffic peaks its monolith could not absorb without heavy 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 your custom logic gives you no advantage. Legacy CRM, HR, and service desk systems are the usual candidates.

Trade-off: technically simple, hard on the organization. Data mapping and user change management carry more risk than the platform switch itself.

Success metric: every user on the new platform and the legacy system decommissioned by a committed date.

6. Retire

Retirement switches the workload off for good.

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

Trade-off: none, as long as your analysis is thorough. Every workload you retire is one you never pay to migrate, run, secure, or support again.

Success metric: applications decommissioned, and annual run cost removed from the budget.

Example: the insurance carrier example later in this guide found 31 of its 140 apps had no recorded access in 90 days. Retiring them cut the migration scope by more than a fifth before any work started.

7. Retain (revisit)

Retention leaves the workload where it is for a defined period.

Use it when: regulatory constraints, hardware dependencies, or vendor contracts block movement in this cycle.

Trade-off: retain is a legitimate decision, but it needs a documented review date. Without one, temporary retention turns permanent by default and you end up running two environments for years.

Success metric: a review date on the calendar with a named owner, revisited every cycle.

Comparing the seven approaches

AWS and most major providers use this same taxonomy, so the vocabulary travels across vendors. Google is the exception: it uses six categories, splits refactor from re-architect, adds rebuild, and drops relocate, retire and retain. Comparing vendor docs side by side, expect the mapping to be close but not one to one.

What are the phases of cloud migration?

The steps for cloud migration group into four phases. The labels vary by vendor. The sequence does not, and every week you shave off the front end comes back as an incident or an invoice at the back end.

Phase 1: Assess (4 to 8 weeks)

Build a full application inventory. Map dependencies against real network behavior, not old docs. Score each workload on business criticality, technical debt, compliance exposure, and current run cost, then assign a migration path to every item.

You end with a scored estate carrying 7 Rs classifications and an initial cost model. Undocumented dependencies you find at this stage are cheap. Find them during cutover and they are not.

Phase 2: Plan (4 to 6 weeks)

Group workloads into migration waves and define your target architecture. Set up the cloud landing zone first, with identity, network, and security baselines in place before anything moves.

Wave one should be low-risk but real. Substantial enough to test the landing zone, contained enough that a delay costs you no revenue. Governance applied now is far cheaper than governance bolted on later, and that goes double in Azure cloud services, where policy structure shapes everything built on top of it.

Phase 3: Migrate (9 to 20 months for a mid-size estate)

Run it wave by wave. Each wave follows the same loop: replicate, test in the target environment, validate against the source, cut over, monitor, then close out.

A wave is done when its validation criteria are signed off, not when the last server responds. Start the next wave on top of an unclosed one and you stack risk across both.

Phase 4: Optimize (ongoing)

This is the phase that gets cut when budgets tighten. It is also where your money comes back. Right-size compute against real demand, not old specs. Apply storage tiering by access pattern. Shut down non-production environments outside working hours.

Most estates stay over-provisioned for six months after migration, because instances get sized to match old hardware rather than real use, and it does not resolve itself. The FinOps Foundation’s State of FinOps 2026 report still ranks workload optimization and waste reduction as the top priority for practitioners, years after the migrations that created the waste. Microsoft’s Cloud Adoption Framework splits the same work into five phases rather than four and treats decommissioning the source as a phase of its own. That is the phase most programs quietly skip.

How do you build a cloud migration plan?

Strategy tells you what moves. The plan tells someone what to do on Tuesday. Five components separate a plan that holds from a Gantt chart abandoned in month three.

Wave design. Group applications by dependency cluster, not by business unit. Systems that talk to each other constantly move together. Otherwise you build a temporary bridge, and those tend to outlive everyone’s plans for them.

Cutover windows. Pick these from the business calendar, not the engineering calendar. You do not migrate a retail order system in November, and you do not touch financial reporting at period close.

Rollback triggers. Define the measurable conditions that abort a cutover, and define them before the cutover starts. A threshold like transaction latency above 400ms for ten straight minutes is actionable. A judgement call made under pressure at 3am is not.

Validation criteria. Write down what a successful migration means for each workload, in numbers: row counts, reconciliation outputs, and performance baselines measured against your pre-migration figures.

Ownership. Give every wave one named person with authority to proceed or stop. Committees do not cut over.

Data-intensive workloads need a parallel planning track alongside your application plan, which we cover in our strategic guide to mapping a modern data migration process.

Cloud migration checklist

Print this one. Every item below has cost somebody a weekend.

Before migration

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

During migration

• Source and target running in parallel through the validation window
• Reconciliation reports run and signed off per workload
• Performance baselines compared against pre-migration measurements
• Cutover checklist executed by the named wave owner
• Monitoring and alerting live 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 captured before the wave team is reassigned

Pay particular attention to recovery testing. A restore you have never run in the target environment is an assumption, not a control. Our breakdown of the essential components of a data backup and recovery strategy covers 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 hard part. The integrations around it are.

Classify by architecture first. A stateless web application with a clean API boundary rehosts in days. A monolith with a shared database, hard-coded file paths, and scheduled jobs nobody has looked at in years is a different animal.

Map dependencies against observed behavior. Run network flow analysis across at least 30 days. Monthly batch processes and quarterly reporting jobs will not show up in a two-week capture, and those are exactly the integrations that fail quietly after cutover.

Deal with state before you move. Session state held in app memory. Files written to local disk. Hard-coded server names. Those three break more lift-and-shift attempts than anything else, and all three are cheap to fix beforehand and costly to fix afterward.

Choose a cutover pattern deliberately. Big-bang cutover is fastest and riskiest. Parallel operation doubles infrastructure cost for a set window but lets you validate against real traffic. Phased user migration gives you a genuine rollback path where the architecture supports it. For revenue-critical applications, parallel operation is almost always worth the extra spend.

Test the integrations as hard as the app. The classic post-migration failure: your app starts fine, but the nightly file drop to a partner system fails because the source address changed and nobody told the partner. In our experience, integration failures cause more post-cutover incidents than the application itself.

Where you land shapes your cutover options. Managed replication tooling differs across AWS, Azure, and Google Cloud services, and that difference often decides whether a cutover takes minutes or a weekend.

How do you migrate data and analytics workloads?

Cloud data migration plays by different rules from application migration, and this is the part most plans under-resource. An application either works or it does not. A data platform can migrate apparently successfully and stay quietly wrong for months.

Schema translation is not replication. Data types do not map cleanly between platforms. Decimal precision, date handling, string collation, and NULL semantics all differ. A numeric column that loses precision raises no error. It just makes your financial reports wrong by a margin that compounds.

Decide your load pattern early. Bulk cutover needs a freeze window, and for a large warehouse that window may be longer than your business will accept. Incremental replication using change data capture keeps the source live while the target catches up, at the cost of more engineering. Platform choice shapes this too, and the differences are covered in our comparison of cloud data warehouses across Amazon, Azure, Google, and Snowflake.

Validate at three levels. Row counts catch gross failures. Checksums on key columns catch corruption. Business-logic reconciliation, where you run identical reports against both platforms and compare the outputs, catches the subtle errors the first two miss. Only the third one catches a join that has silently changed behavior.

Inventory every downstream consumer. Every dashboard, scheduled extract, spreadsheet link, and team report reading from the source has to be traced and repointed. BI layers are usually the last thing anyone checks and the first thing your users notice. A report that renders fine while returning stale numbers is worse than one that fails outright, because a failure gets investigated and stale data does not.

How do you migrate infrastructure to the cloud?

Cloud infrastructure migration covers the layer beneath your applications: networking, identity, storage, and the security controls wrapped around them.

Build the landing zone before anything moves. Your network topology, subnet design, and links back to on-premise systems should be live and tested first. Identity federation comes next, because access management bolted onto a half-migrated estate is a security incident waiting for a date. NIST formalized this shift in SP 800-207: no implicit trust based on physical or network location, with defenses moved onto users, assets, and resources.

Storage is where unexpected costs pile up. On-premise capacity is a sunk cost. In the cloud, every tier has its own price and every retrieval has a charge. Sort your data by access pattern before you move it, not after the first bill arrives.

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

Cloud migration tools

Tooling will not fix a weak strategy, but the right tools remove weeks of manual work from each phase. Four categories cover most of what you need.

Discovery and assessment. These build your inventory and dependency map. AWS Application Discovery Service, Azure Migrate, and Google Cloud Migration Center all run agent-based or agentless discovery against your estate. Whichever you pick, run it for at least 30 days so monthly and quarterly jobs appear in the capture.

Server and application replication. AWS Application Migration Service, Azure Migrate’s server migration, and Google’s Migrate to Virtual Machines handle continuous block-level replication, so you cut over with minutes of downtime instead of a weekend.

Database and data movement. AWS Database Migration Service, Azure Database Migration Service, and Google Database Migration Service handle both homogeneous and cross-engine moves, with change data capture for incremental loads. For analytics pipelines, ingestion tools that support CDC natively keep the warehouse in sync during a long cutover window.

Cost visibility and FinOps. Native cost tooling from each provider gives you tagging and budget alerts. Dedicated platforms add cross-cloud allocation and commitment management. Turn this on before wave one, because cost data you did not collect is cost data you cannot analyze.

What does cloud migration cost?

Migration cost splits into three categories, and most teams budget for one of them. Gartner puts 2026 infrastructure-as-a-service spending at $287 billion, growing 29.3%, one of the two fastest-growing segments in all of IT.

One-time migration cost. Assessment, tooling, engineering hours, parallel-run overhead, and testing. For a mid-size estate of 100 to 300 applications, this usually runs from a few hundred thousand to low seven figures, depending on how much refactoring is in scope. Rehost-weighted programs sit at the bottom of that range. Refactor-weighted programs blow past the top of it.

Year-one run cost. Almost always higher than the on-premise cost it replaced, because workloads get sized to match old specs rather than real demand. This is normal and temporary, but it has to be in your business case or the program gets labelled a failure by month four.

Optimization savings from year two. Right-sizing, committed-use pricing, storage tiering, and shutting down idle environments. This is where your ROI actually closes.

That third bucket is not optional. Flexera’s 2026 State of the Cloud Report puts estimated wasted cloud spend at 29%, the first increase in five years, driven largely by AI workloads. Most of that waste gets provisioned during migration and never revisited.

How to frame this internally. A business case built on infrastructure savings alone rarely survives a finance review, because year one costs more than what it replaced. Stack four things instead: the avoided cost of a hardware refresh or lease renewal, the engineering hours your team spends on patching and capacity work, the revenue at risk from running critical systems past their support window, and the delivery speed you gain when provisioning drops from weeks to minutes. Put a number against each. Three of those four defend better in a budget review than the raw compute line.

When cloud migration is the wrong call

Almost every guide on this topic assumes the answer is yes. It is not always. Four situations where staying put is the better decision.

Your hardware has years left and the load is flat. Cloud pricing rewards elastic demand. A workload with steady, predictable demand on hardware you bought two years ago has already had its capital spent, and you would be paying a premium for elasticity you never use.

Latency to on-site equipment is your constraint. Manufacturing lines, warehouse control systems, medical imaging, and lab instruments often need single-digit millisecond response to hardware in the same building. No region is close enough. Edge deployments help, but they add a second environment rather than removing one.

Your regulator has not approved an equivalent. Some jurisdictions and some contracts still name specific hosting arrangements. Where no cloud equivalent has been signed off, migration is a legal project before it is a technical one, and the legal work has to finish first.

Nobody on your team can run it afterward. A migrated estate needs cloud operations skills the day it lands. With no budget to hire, no time to train, and no managed-service partner lined up, the migration succeeds and the operation fails. That is a worse outcome than not moving.

None of these are permanent. Each has a trigger that changes the answer: a hardware refresh, an equipment replacement, a regulatory update, a hiring round. Name the trigger, set a review date, and file it under retain.

Common cloud migration challenges and how to overcome them

You are not guessing at what goes wrong. Flexera’s 2026 State of the Cloud Report ranks the biggest migration barriers as understanding application dependencies (54%), assessing technical feasibility (44%), and comparing on-premises versus cloud costs (43%). All three are assessment-phase problems, which is why compressing that phase is the most expensive shortcut available to you.

Undocumented dependencies. The most common cause of failed cutovers, and the number one barrier in the survey above. Fix: 30-day network flow analysis, checked against what the app owner tells you rather than used instead of it.

Scope creep from replatform into refactor. Your engineers get inside a codebase, spot improvements, and a six-week job becomes a six-month one. Fix: lock the migration path per workload at assessment, and require a change request to move it.

Security controls that do not translate. Perimeter-based security breaks in a cloud model where identity is the perimeter. Fix: design identity and access controls into the landing zone, and check them against the risks 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 around the clock. Fix: tagging and cost allocation enforced from day one, with a budget alert per wave.

No decommission date. Source systems stay online just in case, and you pay for both environments for years. Fix: agree a fixed decommission date, signed by the business owner, before the wave starts.

Compliance surfaced late. Data residency, retention, and audit rules found mid-migration force a redesign. Fix: get legal and compliance sign-off on your target architecture in phase one.

Cloud migration strategy example

The following is a composite scenario built 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 running 140 applications across two data centers, with one lease expiring in 14 months. A 12TB on-premise data warehouse fed about 400 reports, and nobody could say how many were actually used.

Assessment findings. Of the 140 apps, 31 showed no user access in 90 days and were classified retire. Another 12 were locked by contract and classified retain. That cut the in-scope estate to 97, and reset the scope conversation before a single 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 the architecture was directly blocking product changes. Everything else moved unchanged or with a managed-service swap.

Sequencing. Six waves. Wave one was internal tooling, real enough to test the landing zone and harmless enough that a slip cost nothing. The data warehouse migrated in wave four, deliberately late, once the applications feeding it were stable in the target environment.

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

The lesson. Row counts passed. Checksums passed. Only running the same reports against both platforms and comparing outputs caught it. On a data platform migration, business-logic reconciliation is the one layer that catches the failures your users will actually notice.

For a real engagement rather than a composite, our records center operational visibility case study covers the same problem from the other direction: a warehouse layer across 150+ locations that unified five fragmented operational streams without replacing the legacy sources.

Get a second read before wave one

The expensive mistakes in a cloud migration get made on a whiteboard, not at cutover. A workload filed under the wrong R. A dependency nobody mapped. A data platform scheduled three waves too early. Each one is a thirty-minute conversation now and a rebuild in month nine.

If you are mid-assessment, send us what you have: your application inventory, your draft 7 Rs classification, and the deadline you are working to. Our cloud and data engineering team comes back with a written read on where your sequencing holds, where it will cost you, and which workloads we would reclassify before wave one starts.

No pitch deck. If your assessment is solid, we will tell you that and leave you to it.