A cloud migration strategy is the decision, made application by application, about how each workload will move to the cloud and why. A cloud migration plan turns those decisions into a sequence with owners, dates, success measures and a way back if something goes wrong. Teams that skip the first step end up moving everything the same way, which is how migrations run over budget and carry old problems into a new environment.
This guide covers the seven migration strategies (the 7 Rs), a seven-step plan you can adapt, the ten risks that cause most failed migrations and how to reduce each one, and the security and compliance questions regulated organizations need to answer before cutover.
What is the difference between a cloud migration strategy and a migration plan?
The strategy answers "how should each application move?" It starts with an inventory of your applications and ends with one of the 7 Rs assigned to each. The plan answers "in what order, by whom, and how will we know it worked?" It covers waves, owners, timelines, testing, rollback and budget.
You need both. A strategy without a plan stays a spreadsheet. A plan without a strategy usually defaults to lifting everything as is, which moves cost and technical debt without fixing either. If your estate includes legacy applications, the strategy step is where you decide which ones deserve modernizing and which ones should simply be retired.
What are the 7 Rs of cloud migration?
AWS describes seven migration strategies, known as the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform and refactor. Many teams still talk about six Rs, which is the same list without relocate. The table shows what each means and when it fits.
| Strategy | What it means | Best when | Watch out for |
|---|---|---|---|
| Retire | Decommission the application | Nobody uses it, or another system already replaces it | Hidden users and downstream dependencies |
| Retain | Keep it where it is for now | Regulatory limits, recent investment or a high-risk migration | Revisit on a schedule so "retain" does not become "forever" |
| Rehost | Move as is ("lift and shift") | You need speed, such as a data center exit | Costs can rise if you never optimize afterwards |
| Relocate | Move to the cloud at the hypervisor or platform level, or between cloud accounts and regions | Large virtualized estates | Platform-specific tooling and limits |
| Repurchase | Replace with a different product, usually SaaS | A commodity application with a mature SaaS alternative | Data migration, retraining and licence terms |
| Replatform | Move with targeted optimizations, such as a managed database | Quick wins without changing the architecture | Scope creep into a full rewrite |
| Refactor | Re-architect for cloud-native services | The application is strategic and needs to scale or change often | The most complex and slowest option |
How do you choose the right strategy for each application?
Assign a strategy per application, not per project. Score each application on five questions:
- Business value: does it still earn its keep? If not, retire it first. Switching off an application is the cheapest migration you will ever do.
- Dependencies: what does it talk to, and what talks to it? Map this before you move anything.
- Compliance: does the data it handles carry CMMC, HIPAA, FedRAMP or other requirements that limit where and how it can run?
- Technical condition: is the platform near end of support, or tied to specific hardware or licences?
- Skills and appetite: can your team run it in the cloud on day one, or does it need new skills or a partner?
A useful rule: rehost or replatform to hit a deadline, then refactor the few applications that justify it. AWS notes that refactoring is not recommended for large migrations because it combines modernization with the move and is the hardest strategy to manage across many applications. Our legacy code modernization assessment shows how to decide which applications are worth the extra effort.
How do you build a cloud migration plan? A seven-step approach
1. Set goals and success measures
Write down why you are migrating: exit a data center, cut run costs, improve resilience, meet a compliance requirement or speed up delivery. Attach a measurable target to each, such as uptime, cost per workload or release frequency. These become your definition of done.
2. Inventory applications and map dependencies
List every application, its owner, its data, its integrations and its users. Discovery tools help, but interview application owners too, because undocumented dependencies are the main cause of surprise outages during cutover.
3. Assign a strategy to each application
Use the 7 Rs and the five questions above. Record the reason for each choice so it can be reviewed later and used in audits.
4. Build the landing zone before you move anything
The landing zone is the secured foundation your workloads land in: account structure, identity and access management, network design, logging, encryption, backup and cost guardrails. Building it first means security is a property of the environment, not something added to each workload afterwards.
5. Run a pilot
Pick a low-risk, representative workload and migrate it end to end. Use the pilot to test your tooling, your rollback procedure and your team, and to get a realistic estimate for the rest.
6. Migrate in waves with validation and rollback
Group applications into waves by dependency and risk. For each wave, validate data with checksums and test environments, agree a cutover window, and keep a tested rollback ready until the wave is signed off. For data, rehearse the transfer before the real one.
7. Cut over, then optimize
Migration is not finished at cutover. Right-size resources, remove duplicate environments, set budgets and alerts, and review each retained application on a schedule. Cost and performance reviews in the first 90 days are where most savings are found.
What are the risks of cloud migration, and how do you reduce them?
Most migration problems repeat from project to project. Google Cloud's guidance on evaluating and mitigating migration risks is a useful reference for building your own register. The ten below are the ones we see most often.
| Risk | What goes wrong | How to reduce it |
|---|---|---|
| Data loss or corruption | Incomplete or altered transfers go unnoticed | Checksums, staging copies, rehearsed transfers and rollback |
| Security misconfiguration | Open storage, weak permissions or unencrypted transfers | Landing zone guardrails, policy as code and configuration scanning |
| Identity sprawl | Too many accounts and broad permissions | Least privilege, single sign-on and multi-factor authentication |
| Downtime at cutover | Services are unavailable longer than planned | Phased waves, rehearsed cutovers and agreed rollback criteria |
| Cost overrun | Spend exceeds the business case after go-live | Budgets and alerts, right-sizing, and a post-migration cost review |
| Performance degradation | Latency or throughput worsens versus on-premises | Baselines before migration, load testing and architecture review |
| Compliance exposure | Regulated data lands in a non-compliant configuration | Map controls to the cloud environment before moving data |
| Skills gap | The team cannot operate the new environment | Training, a pilot and a partner for the first waves |
| Vendor lock-in | Heavy use of proprietary services limits later options | Decide deliberately where lock-in is acceptable and document exit routes |
| Stakeholder misalignment | Priorities shift mid-project | Named owners, a governance forum and agreed success measures |
How do security and compliance fit into a cloud migration?
Cloud security works on a shared responsibility model. The provider secures the underlying platform. You secure your data, identities, configurations and applications. AWS explains how it divides these responsibilities in its shared responsibility model, and the other major providers publish equivalents.
In practice, a secure migration does four things before data moves:
- Encrypts data in transit and at rest, with keys you control.
- Enforces least-privilege access and multi-factor authentication for every administrative account.
- Turns on logging and monitoring from day one, so you have an audit trail for the migration itself.
- Maps each regulatory control to a specific setting or service in the target environment.
If you handle controlled unclassified information, start with our CMMC 2.0 compliance guide and NIST 800-171 overview, because the cloud environment you pick has to support those controls. Federal teams should also read the federal zero trust playbook and check whether a service needs a FedRAMP authorization. Our cybersecurity consulting team works with regulated organizations on exactly these questions.
Organizations with strict data residency or sovereignty requirements may choose a private or hybrid cloud design. Public cloud offers scale and cost efficiency, but regulated teams should confirm the configuration meets their requirements before going live.
What are the benefits of cloud migration?
The benefits are real, but they depend on the strategy you choose. A rehost can reduce data center cost and improve availability quickly. Replatforming and refactoring add managed services, automatic scaling and faster delivery. The most commonly cited gains are:
- Lower capital spend: pay for what you use instead of buying hardware for peak demand.
- Scalability: add capacity when demand rises and release it when it falls.
- Resilience: built-in redundancy and easier disaster recovery.
- Speed: new environments in minutes instead of procurement cycles.
Set a target for each benefit in your plan. Benefits you do not measure are rarely captured.
How do you choose a cloud provider?
Choose on fit, not on brand. Compare the providers against your workloads and constraints:
- Compliance: the authorizations and regions you need, such as FedRAMP for federal work.
- Existing estate: how well the platform integrates with the identity, productivity and database tools you already run.
- Services: the managed services your target architecture will depend on.
- Cost model: pricing structure, discounts for committed use and data transfer charges.
- Skills: what your team can run well today.
A multi-cloud or hybrid approach can reduce dependence on one vendor, but it adds operational complexity. Choose it for a specific reason, not by default.
What are the cloud migration best practices?
- Retire what you do not need before migrating it.
- Build the landing zone first, so every workload inherits security and governance.
- Pilot with a representative, low-risk workload.
- Document every decision, from provider selection to security architecture, so it supports audits and future migrations.
- Automate with infrastructure as code and repeatable testing.
- Monitor cost and performance from the first day.
- Treat cloud adoption as an operating model, not a one-off project. Our guide to navigating digital transformations covers the wider change.
For authoritative frameworks, see NIST's cloud computing program and CISA's cloud security resources.
Frequently asked questions
What is a cloud migration strategy?
A cloud migration strategy is the approach you choose for moving each application to the cloud. It assigns every workload one of the migration strategies, such as rehost, replatform or refactor, based on its business value, dependencies, compliance needs and technical condition.
What are the 6 Rs and 7 Rs of cloud migration?
The six Rs are rehost, replatform, refactor, repurchase, retire and retain. AWS adds a seventh, relocate, which moves workloads at the hypervisor or platform level or between cloud accounts and regions. Each application in a portfolio is matched to the one that fits it best.
What should a cloud migration plan include?
A cloud migration plan should include goals and success measures, an application inventory with dependencies, a strategy for each application, a secured landing zone, a pilot, migration waves with validation and rollback, and a post-migration optimization review.
How long does a cloud migration take?
It depends on the number of applications, data volumes, legacy dependencies and compliance requirements. A small pilot can move quickly, while a full migration is usually delivered in phases. Validating each wave before the next keeps downtime and risk down.
Who is responsible for security after moving to the cloud?
Responsibility is shared. The provider secures the underlying platform. You secure your data, identities, access policies and application configuration. Organizations subject to CMMC, FedRAMP or HIPAA must confirm their own configuration meets those requirements.
What do cloud migration services include?
Cloud migration services typically include discovery and assessment, migration strategy and planning, landing zone design, data migration, security and compliance setup, and post-migration optimization. Partners can also help with rollback, backup and disaster recovery practices.
Key takeaways
- A cloud migration strategy assigns an approach to each application. A migration plan sequences the work, owners and rollback.
- Use the 7 Rs, and start by retiring what you no longer need.
- Build a secured landing zone before moving workloads, so security is part of the environment.
- Pilot first, then migrate in validated waves with a tested rollback.
- Manage the ten common risks in a register with an owner for each.
- Security is shared: you remain responsible for your data, identities and configuration.
- Choose a provider on compliance, existing estate, services, cost and skills.
- Optimize in the first 90 days, because cutover is not the finish line.
Ready to plan your migration? Contact VISIONEERIT and we will help you build a cloud migration strategy for your organization.
