A cloud migration strategy is the plan for moving workloads to the cloud, built around two decisions: which of the seven migration approaches (the "Rs") fits each workload, and how the program unfolds across the assess, mobilize, and migrate phases. The right move is to inventory every workload, assign it an R, then run the transition as a phased program rather than a single event. Start with discovery this week and schedule your first migration wave once the landing zone is ready.
TL;DR:
- Prioritize workloads by scoring them on business value and migration effort, focusing on high-value, low-effort items first to maximize efficiency.
- Conduct pilot migrations on low-risk systems to validate procedures, workflows, and rollback plans before scaling to full production environments.
- Establish guardrails such as resource tagging, budget alerts, and security defaults before migrating to avoid cost overruns and security gaps.
- Use automated discovery tools to comprehensively map dependencies, data sensitivity, and performance metrics, ensuring proper sequencing of the migration waves.
- Choose cutover methods based on the acceptable level of downtime, with near-zero downtime options requiring more complex setup but offering smoother customer experiences.
Table of Contents
- What Are the Cloud Migration Strategies (the 7 Rs)?
- How Do the Assess, Mobilize, and Migrate Phases Work?
- How Do You Prioritize Workloads Into Migration Waves?
- Choosing a Cutover Method and Planning for Rollback
- What Guardrails Should Be in Place Before You Migrate?
- How Do You Validate Success and Optimize After Cutover?
- Which Tools and Patterns Scale a Large Migration?
- Where Does Requestum Fit Into a Migration Program?
- A Practitioner's View on Migration Blind Spots
- How Requestum Supports Your Cloud Migration
- Sources
- FAQ
What Are the Cloud Migration Strategies (the 7 Rs)?
Every workload maps to one of seven approaches, and picking the wrong one is the most expensive mistake IT teams make during a cloud migration plan. Azure's Cloud Adoption Framework frames these as indicators tied to business drivers, not gut instinct, and that discipline is what separates a migration roadmap from a guess.
- Retire. Decommission apps nobody uses. Zero migration cost, and it shrinks the scope of everything downstream.
- Retain. Leave a workload on premises, usually because of compliance, recent investment, or a dependency that isn't ready to move.
- Rehost. Also called "lift and shift." Move the workload as is, typically onto virtual machines. Fast and low risk, but it carries technical debt straight into the cloud.
- Replatform. Make targeted changes, such as swapping a self-managed database for a managed service, without touching the core architecture.
- Refactor/Rearchitect. Redesign the application to use cloud-native services like serverless functions or containers. Highest effort, but it unlocks the biggest long-term efficiency gains.
- Repurchase/Replace. Swap the workload for a SaaS product. Common for CRM, HR, and email systems.
- Relocate. Move virtualized workloads (often VMware-based) to the cloud with minimal changes to the hypervisor layer.
The table below shows how these trade off in practice.
| Strategy | Typical effort | Cost profile | Best fit |
|---|---|---|---|
| Retire | None | Savings only | Unused or duplicate apps |
| Retain | None | No change | Compliance-bound or recently upgraded systems |
| Rehost | Low | Low upfront, ongoing inefficiency | Time-boxed migrations, data center exits |
| Replatform | Medium | Moderate | Apps needing quick wins without a rebuild |
| Refactor/Rearchitect | High | High upfront, lower long-term run cost | Core, high-value, or scaling-constrained systems |
| Repurchase/Replace | Medium | Subscription-based | Commodity functions like HR or CRM |
| Relocate | Low | Low | VMware-heavy estates moving fast |
One caution worth flagging: Azure CAF warns against rehosting workloads with known architectural problems, since it just relocates technical debt. If a workload will need modernization within roughly two years anyway, refactor now instead of twice.
How Do the Assess, Mobilize, and Migrate Phases Work?
A cloud migration roadmap runs on three phases, and AWS Prescriptive Guidance structures large migrations around exactly this sequence: assess, mobilize, migrate.
- Assess. Build the business case, inventory workloads, and score readiness. Output: a prioritized backlog with an R assigned to each workload.
- Mobilize. Build the landing zone, establish identity and network foundations, stand up automation pipelines, and train the teams who will execute moves. Output: a repeatable, secure environment ready to receive workloads at volume.
- Migrate and modernize. Execute waves, validate each one, then optimize post-move. Output: workloads running in production with monitoring and cost controls active.
Mobilize is where most programs quietly succeed or fail. It is not a pause between planning and doing. AWS guidance recommends running mobilize activities across multiple workstreams in parallel, including security, operations, tooling, people, and governance, because that parallel structure is what turns a one-off project into a repeatable capability. Skipping straight from assess to migrate without a real landing zone usually means rebuilding security and automation mid-flight, under pressure, with production workloads waiting.
Pilots earn their keep here. Pick two or three low-risk workloads, run them through the full mobilize-to-migrate cycle, and use what breaks to fix the runbooks before you scale. Once the pattern holds, a migration factory model, standardized squads working from a shared backlog, applies that pattern at volume.
Pro Tip: Treat your pilot wave as a rehearsal for your automation, not just your architecture. If your rollback script or monitoring dashboard doesn't work cleanly on a low-stakes app, it won't work on a critical one either.
How Do You Prioritize Workloads Into Migration Waves?
Discovery starts with an honest inventory, and most teams underestimate how much metadata they need before they can sequence anything. Automated discovery tools scan network traffic and server configurations to build a baseline; that baseline needs to capture more than just CPU and memory.
- Application dependencies (what talks to what, and how often)
- Data volume and sensitivity classification
- Current performance baselines and peak usage windows
- Licensing terms and renewal dates
- Business owner and criticality rating
Once the inventory exists, score each workload on two axes: business value and migration effort. A simple four-quadrant matrix does the job: high-value, low-effort workloads go first; high-value, high-effort ones get planned carefully with more testing time; low-value, low-effort items often turn out to be Retire candidates once someone actually looks at them.
Sequencing by dependency, not by business unit, prevents a specific and common failure. Azure CAF recommends grouping components conservatively when a dependency is unclear, because splitting a tightly coupled system across two waves creates fragile, hard-to-debug environments during cutover. Nonproduction environments are the natural first wave. Cisco's migration guidance points out that testing your process on lower-risk systems first validates the runbook before anything customer-facing is on the line.
A useful benchmark for scoping ambition: AWS migration guidance notes that 20 to 50 percent of a typical enterprise portfolio follows repeatable patterns well suited to a factory approach, meaning roughly half your workloads will move faster once your first wave establishes the template.
Choosing a Cutover Method and Planning for Rollback
Every workload needs a cutover decision, and the choice usually comes down to how much downtime the business will tolerate.
- Downtime cutover. Schedule a maintenance window, migrate, validate, and switch over. Simpler to execute and cheaper to build, but it requires a business-approved outage window.
- Near-zero downtime cutover. Use continuous data replication and a phased traffic cutover, often with a blue-green or canary pattern. More complex to build, but it avoids visible disruption for customer-facing systems.
- Data transfer method. For large datasets, decide between online transfer over a dedicated network link and offline transfer using physical appliances, depending on data volume and available bandwidth.
- Rollback planning. Define rollback criteria before you migrate, not after something breaks. Azure CAF's guidance on migration planning specifically calls for predefined rollback criteria and stakeholder approval as part of the plan, not as an improvised response.
- Dry-run testing. Run a full rehearsal of the cutover, including the rollback path, against a nonproduction copy before touching the production system.
The workloads that most often get this wrong are the ones treated as simple rehosts. A lift-and-shift database migration can look low risk right up until the near-zero-downtime replication lag turns out to be higher than the application's tolerance for stale reads. Test that assumption in the dry run, not in the maintenance window.
What Guardrails Should Be in Place Before You Migrate?
Cost overruns and security gaps rarely start during migration. They start because nobody set the guardrails before migration began.
- Apply consistent resource tags (owner, environment, cost center, project) to every resource before the first workload lands, not after fifty resources exist untagged.
- Set automated budget alerts tied to expected spend per workload, so a runaway process gets flagged in hours, not at the end of the billing cycle.
- Rightsize on assumptions from the discovery data, then rightsize again two weeks after cutover using real usage.
- Establish an identity and access baseline, encryption defaults, and centralized logging before any workload moves, as part of the landing zone build.
- Get documented stakeholder signoff on rollback criteria and success metrics before executing a wave.
AWS Well-Architected's Migration Lens guidance is direct about this: tagging and automated budget alerts need to exist before migration starts, because consumption-based pricing punishes teams that discover a cost problem after the fact rather than before it.
Pro Tip: Set your budget alert threshold somewhat below the expected spend to allow investigation before the bill actually surprises anyone. That gives your team a window to investigate before the bill actually surprises anyone.
How Do You Validate Success and Optimize After Cutover?
Define your success criteria before you migrate, not after. Baseline performance, error rates, and cost figures for each workload while it still runs in its old environment, so you have something real to compare against post-move.
- Functional testing confirms the application behaves the same way for end users.
- Performance testing checks latency and throughput against the pre-migration baseline.
- Failover testing verifies the system recovers as designed when a component fails.
- Security testing confirms access controls and encryption match the baseline you set during mobilize.
- Data integrity testing verifies nothing was corrupted or lost in transfer.
AWS's Migration Lens recommends running this full test suite against a nonproduction migration first, using the results to set acceptance criteria before production cutover. Once a workload is live, the work isn't done: rightsize based on real usage, clean up tags left over from the migration itself, review costs weekly for the first month, and update your operational runbooks to reflect what actually happened, not what the plan assumed would happen.
Which Tools and Patterns Scale a Large Migration?
Four tool categories cover most of what a migration program needs: discovery and application dependency mapping tools to build the inventory, replication tools to move data with minimal downtime, orchestration tools to sequence and automate the cutover steps, and infrastructure-as-code plus CI/CD pipelines to make every environment build repeatable.
- Discovery and ADM tools surface the dependency graph you need for wave planning.
- Replication tools handle continuous data sync for near-zero downtime cutovers.
- Orchestration platforms automate the mechanical steps of a migration run, cutting human error.
- Infrastructure-as-code templates turn "build a landing zone" into a repeatable, version-controlled process instead of a one-off manual effort.
A migration factory takes these tools and wraps them in a team structure: standing squads work off a shared sprint backlog, reusing templates for common migration patterns instead of solving the same problem repeatedly.
| Element | What it does |
|---|---|
| Blueprints | Predefined architecture templates for common workload types |
| Automated pipelines | Scripted build and deployment steps for each wave |
| Standing squads | Dedicated teams executing repeatable migration patterns |
| Shared backlog | Central tracking of workload status and blockers |
Where Does Requestum Fit Into a Migration Program?
Requestum's business analysis work covers the discovery and dependency-mapping groundwork that a solid migration roadmap depends on, and the team's engineering background extends into rearchitecting workloads once they're ready for cloud-native design, as documented in the xScale logistics platform work.
A practical starter checklist for your own assess-to-mobilize sprint:
- Complete workload discovery and assign an R to each item.
- Run one pilot migration end to end, including rollback.
- Stand up a minimal landing zone with tagging and budget alerts active.
- Set pilot acceptance criteria before you start, not during.
If your internal team has the bandwidth for discovery but not for building a secure landing zone or executing a rearchitect project, that's the point to bring in outside engineering help. A short pilot with an experienced partner typically surfaces the gaps in your plan faster than a solo attempt does.
A Practitioner's View on Migration Blind Spots
Dependency mapping and cost controls get skipped most often, and both come back to bite programs in week three, not week one.
— Dmitry
How Requestum Supports Your Cloud Migration
Requestum runs migration work the way this guide describes it: discovery and dependency mapping first, a pilot wave to prove the plan, then a scaled program built on the patterns that pilot validates. That structure means you get an engineering partner who has already built the landing zone automation and rearchitecting playbooks, rather than one learning your environment from a blank page.
Whether your next workload needs a straightforward rehost or a full rearchitect into cloud-native services, Requestum's web development team can scope a pilot migration around your highest-priority workload. For AI or data pipelines moving into the cloud, the AI development group handles the modernization side directly. If you're weighing tooling options for a CMS-heavy migration, guides like this Strapi migration plugin roundup are worth a look before you commit to a stack.
Ready to see what a pilot migration would look like for your environment? Get in touch and Requestum will scope the first wave with you.
Sources
- About the migration strategies - AWS Prescriptive Guidance
- Plan your migration - Cloud Adoption Framework | Microsoft Learn
FAQ
What Are the 7 Rs of Cloud Migration?
The seven strategies are Retire, Retain, Rehost, Replatform, Refactor/Rearchitect, Repurchase/Replace, and Relocate, each matched to a workload based on business value and technical readiness.
What Are the 5 Rs of Cloud Migration?
Earlier frameworks used five categories: Rehost, Replatform, Repurchase, Refactor, and Retain, before later guidance split out Retire and Relocate as distinct strategies.
What Are the Phases of a Cloud Migration Strategy?
Most programs follow three phases: assess (inventory and plan), mobilize (build the landing zone and operational foundations), and migrate (execute and optimize), a structure AWS Prescriptive Guidance uses for large-scale migrations.
How Many Steps Are in a Cloud Migration Plan?
There's no fixed universal count, but a practical migration checklist typically covers discovery, workload scoring, R assignment, landing zone setup, pilot migration, wave execution, testing, and post-move optimization.
Should You Rehost or Refactor a Legacy Application?
Rehost if the app works fine and won't need modernization for roughly two years; refactor if it has known architectural problems, since Azure CAF warns that rehosting broken workloads just moves the technical debt into the cloud.