Cloud migration strategy: the 7 Rs explained

A cloud migration strategy is more than “we are moving to AWS” or “we are moving to Azure”. Behind that decision sit dozens of applications, each with its own age, dependencies, data and value to the business. The 7 Rs exist precisely to deal with those applications one by one, using a vocabulary shared by IT leadership, finance and technical teams.

This article explains how to use them in practice: when to migrate, how to map your existing estate, what each of the 7 Rs covers, how to build the migration plan and what to budget for. For an overview of what we do, see our AWS and Azure cloud consulting page.

Why migrate to the cloud (and why not straight away)

The triggers

In practice, a migration rarely starts from abstract conviction. It is triggered by an event:

• A hosting deadline: the end of a managed services or data centre contract, hardware due for renewal, a server room that needs upgrading to current standards.
• Rising virtualisation costs: since Broadcom acquired VMware, many companies have been reviewing their virtualisation platform and licensing.
• Obsolescence: operating systems or databases reaching end of support, ageing hardware, scarce skills to maintain the existing estate.
• New needs: elasticity for traffic peaks, managed services, or access to the generative AI services offered by cloud providers.

The wrong reasons

The most common one: “the cloud is cheaper”. It is not, by default. An application moved as is, sized as it was on premises and running around the clock, can cost more in the cloud than before. Savings come from architecture (managed services, elasticity, switching off unused environments) and from cost governance from day one. Another wrong reason is migrating because “everyone is doing it”, without having identified what you want to gain. Without an explicit objective, it is impossible to choose between the 7 Rs.

Step 1: map your IT estate before choosing

Application inventory and dependencies

You cannot choose a strategy for an application you do not know well. For each application, the inventory should record: the associated servers and databases, inbound and outbound flows, dependencies on other applications, data volumes, actual usage (CPU, memory, traffic) and the business and technical owners.

Tools help collect this data. On the Microsoft side, Azure Migrate provides discovery (agent-based or agentless), compatibility assessment and target cost estimates. On the AWS side, note a recent change: AWS Migration Hub and Application Discovery Service have been closed to new customers since 7 November 2025, and AWS now points customers to AWS Transform for planning and executing migrations. If you are reading older guides, check which tooling is currently recommended.

Classify your applications

Once the inventory is done, each application is classified along three axes:

• Business criticality: what happens if it is unavailable for an hour, or for a day?
• Nature of the data: personal data (GDPR), health data (in France, hosting must be HDS certified: Hébergement de Données de Santé, the French certification for hosting health data), data subject to residency requirements.
• Technical complexity: dependencies, legacy technologies, specific hardware, mainframe or non-x86 Unix.

This classification already brings obvious candidates to the surface: simple, low-criticality applications for the first waves, and sensitive applications that will need a dedicated study.

The 7 Rs of cloud migration

AWS documentation (Prescriptive Guidance) describes seven strategies, which Microsoft covers under other names.

Rehost (lift and shift)

The application is moved to the cloud without modification. This is the fastest option, suited to high-volume migrations, especially when a hosting deadline is approaching. It brings no optimisation in itself, but an application already in the cloud is easier to modernise afterwards.

Relocate

Servers, often in large numbers, are transferred from an on-premises platform to the cloud version of the same platform, or resources are moved to another account, Region or virtual network. No new hardware, no rewriting, no change to operations: it is the fastest way to start operating in the cloud, with no impact on the architecture.

Replatform

Nicknamed “lift, tinker and shift”: the application is moved with targeted optimisations. Examples given by AWS include moving a SQL Server database to Amazon RDS, containerising an application without touching the code, switching from Windows to Linux, or adopting Graviton processors. It is often the best balance between effort and benefit.

Refactor / re-architect

The architecture is changed to take full advantage of cloud-native services (serverless, containers, managed services). This choice is justified by a strong business need: a monolith that slows down change, an application that can no longer evolve, scaling requirements. AWS describes it as the most complex and most expensive strategy, and recommends avoiding it during large-scale migrations and modernising once the migration is complete instead.

Repurchase (move to SaaS)

Also called “drop and shop”: the application is replaced by an off-the-shelf product, often SaaS. This is relevant for standard functions (email, HR, CRM). The work does not disappear: data migration, integration with the corporate directory, user training, and checking the vendor’s security and compliance.

Retire

The application is decommissioned or archived. An inventory almost always reveals applications with no users or no business value. AWS cites signals such as no inbound connections over the last 90 days or very low CPU and memory usage. Every application retired means less cost and less security risk.

Retain

The application stays where it is, for now: a data residency requirement, a dependency on specific hardware (shop-floor machines), a recent upgrade, a mainframe that needs in-depth study, or waiting for a SaaS version from the vendor. Retain is not a failure: it is a documented decision, to be revisited later.

Comparison table: effort, timescale, benefit, risk

Strategy	Effort	Timescale	Short-term benefit	Main risk
Retire	Low	Short	Removes cost and risk	Removing an application that is still in use
Retain	None in the short term	Not applicable	None	Postponing a decision indefinitely
Rehost	Low to medium	Short	Fast data centre exit	Reproducing costly oversizing in the cloud
Relocate	Low	Short	Operational continuity	Remaining dependent on the virtualisation platform
Repurchase	Medium	Medium	Less infrastructure to manage	Data migration, vendor lock-in
Replatform	Medium	Medium	Managed services, lower operating costs	Drifting into an unplanned refactor
Refactor	High	Long	Agility, scalability, optimised costs over time	Budget and schedule overruns

6 Rs or 7 Rs: where does the difference come from?

In 2011, Gartner described five migration strategies (the “5 Rs”). In 2016, Stephen Orban, then at AWS, published “6 Strategies for Migrating Applications to the Cloud”, which built on those 5 Rs and extended them to six. Relocate was added later, giving the 7 Rs used in AWS documentation today. Both frameworks describe the same logic; the 7 Rs simply single out the specific case of moving a virtualised platform.

Build the migration plan

Migration waves and pilot applications

You do not migrate everything at once. The plan groups applications into waves that respect their dependencies (an application and its database migrate together). The first wave is a pilot: a few low-criticality but representative applications, used to bed in the tools, the cutover and rollback procedures, and coordination with business teams. Each subsequent wave benefits from the lessons of the previous one.

Foundation first: identity, networking, security

Before the first application, you need a foundation (often called a landing zone): how accounts or subscriptions are organised, identity and access management, networking and connectivity with on-premises sites, centralised logging, security and compliance rules. This foundation is what stops every team from creating its own rules. We cover these topics in our approach to cloud security and governance.

Infrastructure as Code from day one

The foundation and target environments should be described as code (Terraform, OpenTofu, or native tools). The direct benefits: reproducible environments, changes that are reviewed and traced, living documentation and easier reversibility. Retrofitting Infrastructure as Code after the migration costs far more. See our Terraform and Infrastructure as Code services.

How much a migration costs and how to fund it

Cost items

There is no reliable average cost: everything depends on your inventory and the strategies chosen. The items to estimate are always the same:

• Running both environments in parallel: during the migration you pay for the old and the new environment. How long this lasts depends directly on the pace of the waves.
• Licensing: some licences cannot be transferred to the cloud, others can under certain conditions. This item is often underestimated.
• Migration work: preparation, testing, cutovers, fixes.
• Upskilling: your teams will be running a different environment. Training and knowledge transfer need to be budgeted.
• Target costs: the monthly bill after migration, projected from the actual usage measured during the inventory.

Cloud provider programmes

AWS and Microsoft offer support programmes that can reduce the upfront cost:

• The AWS Migration Acceleration Program (MAP), structured in three phases (Assess, Mobilize, Migrate & Modernize), combines methodology, tools, partners and financial investment. AWS does not publish detailed amounts or eligibility criteria.
• On the Microsoft side, the former Azure Migrate & Modernize programme is now presented as part of the Azure Accelerate offering, which combines partner support and Microsoft funding.

The names, terms and amounts of these programmes change regularly: check them when your project starts (information checked in October 2026).

After the migration: FinOps and operations

A successful migration is measured several months after cutover. Two workstreams take over:

• Cost control: allocating spend by application and team, rightsizing, usage commitments, switching off non-production environments. This is what FinOps is about, as we explain in our article FinOps: definition and AWS cost optimisation levers and in our cloud cost optimisation services.
• Operations: monitoring, incident management, tested backups, updates, documented procedures. Rehosted applications are also the first candidates for modernisation, now that they are in the cloud.

Checklist before you start your migration

• Migration objectives written down and shared (cost, deadline, agility, security)
• Complete application inventory, with dependencies and actual usage
• Classification by criticality, data sensitivity and complexity
• A 7 Rs strategy decided and justified for each application
• Target foundation designed (identities, networking, security, logging) and described as code
• Wave plan with a pilot wave and rollback criteria
• Estimate of parallel running, licensing and training costs
• Cost governance in place before the first cutover

Next step

If you are preparing a migration and would like an outside view of your choices, we can help you map your IT estate and build a realistic plan, from our base in Villeneuve-d’Ascq in the Lille metropolitan area (northern France) or remotely. Find out more about our migration to AWS and Azure services.

[ YOUR QUESTIONS ]

Frequently asked questions

Why migrate to the cloud?

The good reasons are concrete: a hosting contract coming to an end, hardware or software reaching end of support, a need for elasticity, access to managed services or AI. The cloud is not cheaper by default: it becomes cheaper when the architecture and cost governance are right.

What is the difference between lift and shift, replatform and refactor?

Lift and shift (rehost) moves the application without changing it. Replatforming adds a few targeted optimisations, such as moving to a managed database. Refactoring changes the architecture to take advantage of cloud-native services: it is the most expensive and the slowest option.

6 Rs or 7 Rs: what is the difference?

The 6 Rs were popularised by AWS in 2016, building on the 5 Rs described by Gartner in 2011. AWS later added Relocate, which means moving a virtualised platform to its cloud version without changing the application. The 7 Rs are the version used in AWS documentation today.

How much does a cloud migration cost?

There is no reliable average price: the cost depends on the number of applications, the strategies chosen, how long you run both environments in parallel, licensing and the training effort. A serious estimate starts from the application inventory and a projection of target costs, then factors in any funding programmes offered by the cloud providers.

Should I migrate to AWS or Azure?

Both platforms cover the 7 Rs and offer discovery and migration tools. The choice depends mainly on your existing estate (Microsoft environment, in-house skills, contracts), the services you will need and your compliance requirements. We remain neutral and document that choice with you.

Sources

• AWS Prescriptive Guidance: About the migration strategies (7 Rs)
• AWS Enterprise Strategy Blog: 6 Strategies for Migrating Applications to the Cloud (Stephen Orban, 2016)
• AWS Migration Hub: availability change (closed to new customers)
• AWS Migration Acceleration Program (MAP)
• Microsoft Learn: About Azure Migrate
• Microsoft Partner: Azure Accelerate and migration offerings