Cloud Migration Plan: A Step-by-Step Roadmap

Moving to the cloud is rarely the hard part. Doing it without breaking things, blowing the budget, or discovering halfway through that two "independent" applications were quietly talking to each other is the hard part. A cloud migration plan is what separates a controlled, predictable move from an expensive scramble. This guide walks through what a cloud migration plan and strategy actually are, the standard migration approaches (the 6 R's), a step-by-step roadmap you can follow, realistic timelines, and the failure patterns that derail projects. This is the hands-on, do-it-yourself how-to: it is written for the person who has to make the move work, not just approve it, and you can use it to build the plan and run the migration with your own team. If you would rather hand the whole thing to a partner, that is a different job, and our cloud migration services page covers how we plan and execute the move for you. This guide was last updated July 2026 to reflect current frameworks and cost-management practice.

What Is a Cloud Migration Plan?

A cloud migration plan is the detailed, step-by-step roadmap that turns a cloud migration strategy into action. It documents the inventory of applications and their dependencies, the sequence and timeline for moving each workload, the team and responsibilities, the testing and rollback procedures, and the success criteria. Where the strategy answers why you are moving and which approach applies to each system, the plan answers who does what, in what order, and by when.

Put simply: the strategy is the decision, the plan is the execution. Most failed migrations have neither written down. They have a destination ("we are going to the cloud") and a vendor invoice, but no inventory, no sequence, and no agreed definition of success. The rest of this guide builds both pieces, starting with the strategy frameworks and ending with a checklist you can take into your first planning meeting.

The 6 R's of Cloud Migration (Migration Strategies)

A cloud migration strategy is the high-level plan that defines why an organization is moving to the cloud and how each workload will get there. The standard way to make that decision per workload is the 6 R's. The framework started as Gartner's "5 R's" around 2010, was popularized and expanded by Amazon Web Services, and is now the model nearly every cloud provider organizes around. You assign each application in your inventory to one of these six approaches during planning. Most real migrations use a mix of all six.

Rehost (lift and shift)

Rehosting moves an application to the cloud as-is, with no code changes, typically onto cloud virtual machines. It is the fastest and lowest-risk approach. Use it when speed matters, when you are migrating at large scale on a deadline, or when an application does not justify the cost of re-architecting. Rehosting is often a first step, with optimization or refactoring planned for later. The one caution: lifting and shifting without right-sizing resources is the single most common reason cloud bills come in higher than expected.

Replatform (lift, tinker, and shift)

Replatforming moves a workload to the cloud while making a few targeted optimizations, for example swapping a self-managed database for a managed cloud database, without changing the core architecture. Use it to capture some cloud benefits (less operational overhead, better scaling) with modest effort and relatively low risk. It is the pragmatic middle ground between rehosting and a full rewrite.

Repurchase (drop and shop)

Repurchasing replaces an existing application by switching to a different product, usually a SaaS subscription, for example retiring a self-hosted CRM in favor of a cloud CRM. Use it when a commercial SaaS option meets the need better than maintaining and migrating the legacy system. The benefit is that it removes that workload from your migration project entirely.

Refactor / Re-architect

Refactoring substantially rewrites or redesigns an application to be cloud-native, often adopting microservices, containers, or serverless components. It is the most resource-intensive approach. Use it when the business needs features, scale, or performance the current architecture cannot deliver, and the long-term payoff justifies the higher cost and effort. Refactor selectively. Trying to re-architect everything at once is how budgets and timelines spiral.

Retire

Retiring means decommissioning applications that are no longer useful or that duplicate other systems. A thorough inventory almost always surfaces workloads nobody actually needs. Shutting them down reduces project scope, ongoing cost, and security exposure, which is why a careful discovery phase frequently pays for itself before a single workload moves.

Retain (revisit)

Retaining means deliberately keeping certain workloads where they are, on-premises or in their current environment, for now. Use it when an application is not ready to move, was recently upgraded, faces compliance or latency constraints, or simply is not a priority in this phase. Retained workloads get revisited in a later wave. A seventh R, Relocate, is sometimes added for moving whole virtualized estates between environments without changing the applications themselves.

How to pick the right R for each workload

There is no single best strategy, because the right choice is made per workload, not for the whole organization. Weigh three things for each application: its business value, its technical complexity, and its dependencies. High-value, well-built applications that just need to move are good rehost or replatform candidates. Aging systems with a strong SaaS alternative are repurchase candidates. Strategic applications that the business is investing in heavily may justify refactoring. Anything redundant gets retired, and anything constrained or recently invested in gets retained. If you want a second set of eyes on those calls, this is exactly the kind of decision our cloud consulting team works through with clients.

Cloud Migration Roadmap: Step by Step

A cloud migration roadmap is the sequenced timeline that shows the order in which workloads move and the phases the project passes through. The strategy decides the approach per workload. The roadmap turns those decisions into a realistic schedule with milestones, dependencies, and a low-risk starting point. Here is the step-by-step version.

Step 1: Assess your environment and map dependencies

Start with a complete inventory of every application, server, data store, and integration, including the systems nobody remembers owning. Map how applications depend on one another, because hidden connections are the number one source of mid-migration surprises. This is the same discipline as a broader IT infrastructure assessment, and skipping it is the most expensive corner you can cut. A vague inventory is the most reliable way to turn a predictable timeline into an unpredictable one.

Step 2: Define business objectives and success metrics (KPIs)

Decide what success actually looks like before touching infrastructure. Are you moving to cut data-center cost, improve scalability, increase resilience, or retire end-of-life hardware? Write down measurable targets so you can tell afterward whether the project worked. Migrating "because it is expected" with no defined outcome is one of the quiet reasons projects are judged a failure even when the technical move goes fine.

Step 3: Choose your cloud model and provider

Decide where workloads will live: public cloud, private, or a hybrid mix, and on which provider. This is also where you choose service models, since the trade-offs between PaaS, SaaS, and IaaS shape how much you manage versus how much the provider manages. If you are still weighing whether some workloads belong in the cloud at all, our guide on cloud versus on-premises covers that decision in detail.

Step 4: Assign a migration strategy to each workload

Now apply the 6 R's. Go application by application and assign each one to rehost, replatform, repurchase, refactor, retire, or retain, using the business-value and complexity criteria from the section above. The output of this step is the backbone of your plan: a workload list where every item has a deliberate decision behind it. Nothing moves by accident.

Step 5: Design the target architecture, security, and governance

Before workloads arrive, build the landing zone: identity, networking, and a security baseline configured in advance. Decide how access, configuration, and data protection will be handled, remembering that the cloud provider secures the infrastructure but identity, configuration, and your data remain your responsibility. Bake in cost governance here too, with resource tagging and budgets, so spend is visible from day one rather than discovered on the first invoice. Designing security in from the start is far cheaper than retrofitting it, which is the focus of our cloud security work.

Step 6: Migrate in phases, starting with a pilot

Do not attempt a single big-bang cutover. Move a low-risk, non-critical workload first as a pilot, validate the whole process end to end, then move the rest in planned waves. Phasing is what keeps a long timeline controllable, because each wave is tested before the next begins and the team learns from every move. Plan the data transfer carefully: large data volumes over limited bandwidth can stall a cutover window if you have not measured them.

Step 7: Test, validate, then optimize and manage costs

After each wave, test functionality, performance, and security, not just at the very end. Confirm the workload behaves as expected, then right-size resources to actual demand instead of leaving oversized instances running. Decommission the on-premises systems you chose to retire so you stop paying for both. Post-migration is not the finish line. Ongoing cost monitoring and optimization (the discipline often called FinOps) is where a well-run cloud environment earns back its business case, and it is a core part of managed cloud operations.

How Long Does a Cloud Migration Take?

There is no single answer, because the timeline is driven by scope and approach rather than the calendar. A small migration of a handful of straightforward workloads using a rehost approach can be done in a few weeks. A large estate with many interdependent applications, heavy data volumes, strict compliance requirements, and significant refactoring can run many months or longer. The honest framing is that project length scales with the work, not with a fixed schedule.

The factors that push a migration from weeks toward months include the number and complexity of workloads, how tightly applications depend on one another, the volume of data to move and the bandwidth available to move it, the approach chosen per workload (rehosting is fast, refactoring is slow by design), regulatory constraints, tolerance for downtime, and the cloud skills available in-house. The biggest single accelerator is a complete upfront inventory. The biggest single delay is discovering hidden dependencies after the work has already started.

Why Cloud Migrations Fail (and How to De-Risk Yours)

Most cloud migration failures are not exotic. They repeat the same handful of mistakes. Knowing them in advance is most of the defense.

• Skipping discovery. Starting without a complete inventory of applications, data, and dependencies, so hidden connections surface mid-migration and break workloads assumed to be standalone.
• Lifting and shifting without right-sizing. Copying on-premises capacity one-to-one into the cloud instead of matching resources to demand, which produces oversized instances and surprise monthly bills. Flexera's annual State of the Cloud research has consistently found that organizations waste a meaningful share of their cloud spend, much of it tied to idle and oversized resources.
• No clear objective or success metric. Migrating because it is expected rather than to achieve a defined outcome, which makes it impossible to judge whether the project succeeded.
• Underestimating data transfer. Failing to account for how long it takes to move large data volumes over available bandwidth, which stalls cutover windows.
• Weak cost governance. Launching without tagging, budgets, or spend monitoring, so costs drift upward with no early warning.
• Misunderstanding shared responsibility. Assuming the provider secures everything, when identity, configuration, and data protection remain the customer's job.
• No testing and no rollback plan. Cutting over workloads without validating functionality, performance, and security, and with no defined way to reverse a failed move.
• A skills gap and a big-bang cutover. Asking an inexperienced team to move everything at once concentrates risk and leaves no room to learn from a pilot.

The common thread is that almost every failure traces back to thin discovery or no plan. De-risking is mostly a matter of doing steps 1, 2, and 6 above seriously.

Cloud Migration Checklist

Use this as a practical, scannable summary of the work.

• Define business objectives and measurable success metrics before touching any infrastructure.
• Inventory every application, dependency, and data store, including the systems nobody remembers owning.
• Assess and assign each workload to a migration approach using the 6 R's.
• Right-size resources to actual demand instead of copying on-premises capacity one-to-one.
• Map data volumes and choose a transfer method that fits your bandwidth and acceptable downtime window.
• Establish a landing zone: identity, networking, and a security baseline configured before workloads arrive.
• Set up cost governance from day one with resource tagging, budgets, and spend monitoring.
• Migrate a low-risk pilot workload first, then move the rest in planned waves.
• Test functionality, performance, and security after each wave, not just at the end.
• Document a rollback procedure for every workload before you cut it over.
• Validate results, optimize the environment, and decommission the on-premises systems you chose to retire.
• Prepare the people: train staff and update runbooks so the new environment is supportable on day one.

Frequently Asked Questions

What is a cloud migration strategy?

A cloud migration strategy is the plan that defines why you are moving to the cloud and how each workload will get there. In practice it means assigning every application to a migration approach (most commonly one of the 6 R's: rehost, replatform, repurchase, refactor, retire, or retain) based on its business value, technical fit, and cost. A good strategy ties each technical decision back to a business goal such as reducing cost, improving scalability, or increasing resilience.

What is the difference between a cloud migration plan and a cloud migration strategy?

The strategy is the why and the which: it sets the business objectives and decides which approach (one of the 6 R's) applies to each workload. The plan is the who, what, when, and how: it is the detailed roadmap with the application inventory, the wave-by-wave sequence, the timeline, the responsibilities, and the testing and rollback procedures. You build the strategy first, then turn it into a plan that the team can execute.

What are the 6 R's of cloud migration?

The 6 R's are six standard approaches for moving a workload to the cloud: rehost (lift and shift with no changes), replatform (move with a few targeted optimizations), repurchase (switch to a different product, usually SaaS), refactor or re-architect (rewrite the application to be cloud-native), retire (decommission what is no longer needed), and retain (keep it where it is for now). The framework began as Gartner's "5 R's" and was popularized and expanded to six by AWS. You assign each application in your inventory to one of these approaches during planning.

Which cloud migration strategy is best?

There is no single best strategy, because the right choice is made per workload rather than for the whole organization. Rehosting is fastest and lowest-effort but captures fewer cloud benefits, while refactoring delivers the most cloud-native value but costs the most time and money. The strongest migrations mix approaches: rehost what needs to move quickly, replatform where a small change pays off, repurchase when a SaaS product is a better fit, refactor only the workloads that justify it, and retire or retain the rest.

How long does a cloud migration take?

It depends almost entirely on scope and approach rather than a fixed schedule. A small set of straightforward workloads handled with a lift-and-shift (rehost) approach can be done in a few weeks, while a large estate with many interdependencies, heavy data volumes, compliance constraints, and significant refactoring can take many months. The biggest accelerator is a complete upfront inventory, and the biggest delay is discovering hidden dependencies after the work has already started.

Why do cloud migrations fail or go over budget?

The most common causes are skipping discovery (which lets hidden dependencies break workloads mid-migration) and lifting workloads into the cloud without right-sizing them, which leads to oversized resources and surprise bills. Flexera's annual State of the Cloud research has repeatedly found that organizations waste a significant portion of their cloud spend, much of it on idle and oversized resources. Weak cost governance, no rollback plan, insufficient testing, and a cloud skills gap are the other recurring reasons projects run over.

What is a cloud migration roadmap?

A cloud migration roadmap is the sequenced timeline that shows the order in which workloads will move and the phases the project passes through, typically assess, plan and design, migrate in waves, and optimize. It turns the inventory and the per-workload approach decisions into a realistic schedule with milestones and dependencies. A good roadmap starts with a low-risk pilot workload so the team can validate the process before scaling up.