# Cloud migration strategy: choose a path per application, then plan the waves

> A cloud migration strategy gives each application one of seven treatments (the 7 Rs), then orders them into waves. How to choose, plan and avoid stalls.

- URL: https://computese.com/cloud-migration-strategy/
- Author: Duong Quan Nguyen, CEO, Computese
- Published: 2026-09-27
- Updated: 2026-10-09
- Topics: Cloud

## In short
- A cloud migration strategy is a decision for each application from the 7 Rs (retire, retain, rehost, relocate, repurchase, replatform, refactor), followed by a plan that groups applications into waves.
- AWS names rehost, replatform, relocate and retire as the common choices for large migrations and advises modernizing after the move, because refactoring is the most complex and costly option.
- Assessment sets the plan: map dependencies (including rare batch jobs), check licence terms before assuming BYOL, and model data transfer costs before any wave is given a date.
- Waves move dependent applications together, start with a low-risk pilot, and are gated by entry and exit criteria, a rehearsed rollback and a short hypercare period.
- Databases move online (full load plus change data capture) or offline (a write freeze). AWS says DMS change capture has no latency SLA, so measure lag well before the cutover window.

A cloud migration strategy is a decision for each application, not one rule for the whole estate. Pick one of the seven Rs (retire, retain, rehost, relocate, repurchase, replatform, refactor), then order those decisions into waves, each with entry criteria, a cutover runbook, a rollback and a short period of hypercare.

## Where the 7 Rs came from, and what each cloud calls them

Gartner [named five options in May 2011](https://web.archive.org/web/20130123224850/http://www.gartner.com/newsroom/id/1684114): rehost, refactor, revise, rebuild and replace. In November 2016 AWS [built on those five](https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/) with six: rehost, replatform, repurchase, refactor or re-architect, retire and retain. AWS later [said](https://aws.amazon.com/blogs/enterprise-strategy/new-possibilities-seven-strategies-to-accelerate-your-application-migration-to-aws/) the model grew to seven when VMware's cloud service for AWS launched in late 2017. Compare the 2016 six with [AWS's current seven](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html) and the addition is relocate.

[Microsoft's Cloud Adoption Framework](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/select-cloud-migration-strategy) (updated July 2025) lists eight options and [Google Cloud](https://docs.cloud.google.com/architecture/migration-to-gcp-getting-started) lists six migration types, with different words for the same decisions (the match is approximate):

| AWS (7 Rs)               | Microsoft                         | Google Cloud                                                                                 |
| ------------------------ | --------------------------------- | -------------------------------------------------------------------------------------------- |
| Retire                   | Retire                            | Not on its list                                                                              |
| Retain                   | Retain                            | Not on its list                                                                              |
| Rehost                   | Rehost (like-for-like)            | Rehost: lift and shift                                                                       |
| Relocate                 | No separate entry                 | No separate entry                                                                            |
| Repurchase               | Replace (a SaaS alternative)      | Repurchase                                                                                   |
| Replatform               | Replatform                        | Replatform: lift and optimize                                                                |
| Refactor or re-architect | Refactor, Rearchitect and Rebuild | Refactor: move and improve; Re-architect: continue to modernize; Rebuild: remove and replace |

The word to watch is refactor. Microsoft uses it for improving the internal structure of code, Google for changing a workload to use cloud capabilities, and Gartner meant running the application on a platform as a service (PaaS). When someone proposes a refactor, ask what changes: the code, the architecture or only the runtime.

## How to choose the right R for each application

[AWS names](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html) rehost, replatform, relocate and retire as the common strategies for large migrations. It does not recommend refactor there: it modernizes the application during the migration, which AWS calls the most complex and costly strategy. Move first, then modernize.

Start with the two treatments that move nothing. For retire, AWS gives example screens: an average CPU and memory use below 5 percent (a "zombie" application), 5 to 20 percent over 90 days (idle), or no inbound connection for 90 days. In 2016 it wrote that [as much as 10 percent of an enterprise IT portfolio (its author had seen 20 percent) is no longer useful](https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/) and can simply be turned off. Retain is a dated decision, not a verdict. AWS's reasons include data residency, an application that must wait for others to move first, a recent upgrade, hardware with no cloud equivalent, and mainframe, mid-range or non-x86 Unix systems that need careful assessment.

![A row of application boxes reaches a sorting gate: three tracks lead on to a cloud, one track stops at a padlock beside a server rack, and one ends in an archive drum drawn in orange.](https://computese.com/images/blog/cloud-migration-strategy/portfolio-sorting.9d6f945c6d-1536.webp)

*The cheapest migration is the one you skip: retired applications are archived and retained ones stay put, so neither costs a cutover.*

Match what is left to the table below. Effort is relative within one portfolio, not a benchmark.

| R          | Fits when                                                                      | Effort | What changes                                          | Typical pitfall                                                   |
| ---------- | ------------------------------------------------------------------------------ | ------ | ----------------------------------------------------- | ----------------------------------------------------------------- |
| Retire     | Nobody uses it, or another system does the job                                 | Low    | Switched off, data archived                           | Retention rules ignored; a hidden dependent breaks                |
| Retain     | Compliance, a dependency, special hardware or a recent upgrade blocks the move | None   | Nothing until a review date                           | Latency to what moved; a review date that never comes             |
| Rehost     | A deadline matters more than change and the application is stable              | Low    | The same server or VM runs in the cloud               | Old sizing and patching habits carried over                       |
| Relocate   | A VMware estate must leave its hardware quickly                                | Low    | The same platform runs in a cloud version of itself   | Licence cost, and a second move later                             |
| Repurchase | A SaaS product does the job better than the custom system                      | Medium | Data moves to the product; the old system is retired  | Data migration, integrations and user training                    |
| Replatform | A small change buys a real gain, such as a managed database or container       | Medium | Code stays; runtime and operations change             | The new runtime needs testing like new code                       |
| Refactor   | The application must scale, release often or be split apart                    | High   | The architecture changes to use cloud-native services | Cost and time; inside a large wave it stalls everything behind it |

A practical order of questions: is it used (retire), is anything stopping it (retain), does a SaaS product replace it (repurchase), is it a VMware estate on a deadline (relocate), does a small change buy a real gain (replatform), and otherwise rehost. Keep refactor for applications with a business case of their own: it is a [software development project](https://computese.com/software-and-development/), not a migration task, and the case study on [legacy Java, from Struts to Spring Boot](https://computese.com/work/legacy-java-modernization/) shows the assessment that comes first. For a serverless target, see [how serverless computing works and what it costs](https://computese.com/the-future-of-serverless-computing-streamlining/).

## When is lift and shift the right first move?

Rehost, also called lift and shift, [moves an application to the cloud without changing it](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html). It is the right first move when something other than engineering sets the date. AWS's wave planning guide lists [fixed data center exit dates, colocation contract end dates and refresh cycles](https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/wave-planning.html) among the inputs to a plan, and a licence or support renewal can work the same way. Rehost also builds skills: Microsoft recommends [using it to build foundational cloud operations](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/select-cloud-migration-strategy), so the team learns operations, governance and cost management early.

The limits are as real. Google notes that after a rehost the [workloads are not optimized for the cloud](https://docs.cloud.google.com/architecture/migration-to-gcp-getting-started): they do not take full advantage of horizontal scalability, fine-grained pricing or highly managed services. Microsoft adds that rehosting does not fix existing performance, reliability or architecture problems, and that it suits only a workload you are confident will stay as it is for at least two years. The offsetting benefit, in AWS's words, is that applications are [easier to optimize or re-architect when they are already running in the cloud](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html).

> [!TIP]
> Treat a rehost as a loan, not a destination. Put the optimization work in the plan with an owner and a date (rightsizing, a managed database, retiring the old image), or it will not happen.

## What to assess before you promise a date

Assessment turns the portfolio into data: what exists, what talks to what, what it costs to run and what the licences allow. Each cloud has a first-party discovery tool, and some are changing. Check a tool's status before you plan around it (as of October 2026):

- **AWS.** Application Discovery Service and Migration Hub were [moved to maintenance](https://aws.amazon.com/about-aws/whats-new/2025/10/aws-service-availability/): they closed to new customers from 7 November 2025, and existing customers can keep using them. The [AWS Transform discovery tool](https://aws.amazon.com/blogs/migration-and-modernization/introducing-the-aws-transform-discovery-tool/), a VMware appliance, replaces the Application Discovery Service Agentless Collector. It collects performance and network connection data so related virtual machines migrate together, and its export can feed total cost of ownership (TCO) analysis.
- **Azure.** Azure Migrate's [agentless dependency analysis](https://learn.microsoft.com/en-us/azure/migrate/concepts-dependency-visualization?view=migrate) polls TCP connection data from servers every five minutes. The agent-based option exists only in the classic view, which is scheduled for deprecation by the end of 2026.
- **Google Cloud.** [Migration Center](https://docs.cloud.google.com/migration-center/docs/migration-center-overview) scans your assets, identifies application and network dependencies and generates TCO reports. Its rapid cost estimate is marked Preview.

No single data source holds every dependency. AWS's wave planning guide says to [filter shared services](https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/wave-planning.html) such as Active Directory, backup and monitoring traffic out of the data, because they "glue the entire scope", and warns that batch processes can run sporadically and be missing from it. So collect across a month-end, then confirm with application owners. Separate soft dependencies, which do not depend on location, from hard ones: AWS's example is an application server and its low-latency database, where moving only one causes problems that cannot be resolved.

![Two clusters of application boxes joined by grey lines, the first inside a dashed frame for the first wave. One orange line runs from a box in the frame to a database outside it.](https://computese.com/images/blog/cloud-migration-strategy/hidden-dependency.46abc26396-1536.webp)

*A rare batch job that discovery never recorded can reach across a wave boundary and break on cutover day.*

Licences can change the cost of a move, and the rules differ by vendor (as of October 2026):

- **SQL Server on AWS.** [Bringing a licence to shared-tenancy EC2](https://docs.aws.amazon.com/sql-server-ec2/latest/userguide/sql-server-on-ec2-licensing.html) needs active Software Assurance (License Mobility) and a Microsoft verification form. Without Software Assurance, AWS allows Dedicated Hosts for licences bought before 1 October 2019, or added as a true-up under an Enterprise Enrollment in effect before then.
- **Windows Server on Azure.** [Azure Hybrid Benefit](https://learn.microsoft.com/en-us/windows-server/get-started/azure-hybrid-benefit) needs active Software Assurance or a qualifying subscription, and a minimum of 8 core licences per VM, even for a 4-core VM. A Standard edition licence runs on premises or in Azure, not both at once, except once for up to 180 days to migrate.
- **Oracle.** [Oracle's cloud policy](https://www.oracle.com/a/ocom/docs/cloud-licensing-070579.pdf) counts two vCPUs as one Processor licence when multithreading is on and does not apply the Core Factor Table, so its own example needs two licences for one four-vCPU instance.

> [!WARNING]
> These pages describe vendor policy, not your contract: Oracle's own document says it is for educational purposes only. Confirm each licence position with the vendor or reseller in writing before you size anything.

Data gravity and transfer costs finish the assessment. [AWS charges nothing for inbound data transfer](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/), but does charge for data going out to the internet and between Regions, and Direct Connect bills data flowing out of AWS while data flowing in costs nothing. The Well-Architected Framework says [data transfer fees are usually neglected](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_data_transfer_modeling.html) when teams design as they did for on-premises data centers. In a migration the charge can appear in the hybrid period: move a database in wave 1, leave its reporting jobs on premises, and every result set flows out of AWS.

## Build the landing zone before the first wave

A landing zone is the governed foundation the first workload lands on. [Microsoft defines](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/) an Azure landing zone as an architecture for governing, securing and scaling a multi-subscription environment, and [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) offers one that is set up automatically and enforces controls across multiple accounts. Plan for accounts or subscriptions, identity with least-privilege roles, network, policy guardrails, tagging, central logging and budgets, all defined as code so the foundation can be rebuilt. Keep production workloads out until the pilot proves that identity, network and logging work.

## Plan the waves: a pilot first, then dependency groups

A migration wave is a group of applications that cut over together. Microsoft says [dividing a large migration into waves reduces risk and complexity](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/migration-wave-planning). It also says to define only the next wave in detail and keep later waves high level until you know more.

Start with a pilot wave. Google describes [first-wave applications](https://docs.cloud.google.com/migration-center/docs/plan-migration-waves) as typically not business critical, with fewer system and network dependencies, less data gravity, no specific compliance challenges and room for a cutover window. Microsoft adds two rules: migrate non-production environments before production, and add one or two complex workloads to each early wave to expose the challenges mission-critical applications bring.

Then group by dependency, and size by calendar. Microsoft says to group workloads that share databases, APIs, authentication services or network connections, and to group components together when you are unsure how critical a dependency is. AWS recommends keeping a wave [within 6 to 10 weeks](https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/wave-planning.html), prefers smaller waves because they limit the damage from delays, and lists dates to avoid: release and maintenance cycles, year end, holidays and month-end processing. The plan below is illustrative.

| Wave               | What moves                                                      | Likely treatments          | Entry criteria                                                             | Exit criteria                                                           |
| ------------------ | --------------------------------------------------------------- | -------------------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| 0, pilot           | Two internal tools and a non-production copy of one app         | Rehost, replatform         | Landing zone tested; an owner per application; a backup restored once      | Runbook run twice; rollback rehearsed; alerts live; owners sign off     |
| 1, departmental    | One dependency group of mid-risk applications and their data    | Rehost, replatform, retire | Group confirmed with owners; replication running with lag measured         | Source stopped but kept through the rollback window; hypercare closed   |
| 2, customer-facing | Production applications with strict availability, big databases | Replatform, repurchase     | Lessons from waves 0 and 1 applied; freeze windows agreed; rollback tested | Success criteria met; source retirement criteria met; licences released |

Run every wave through the same phases. AWS's example is design, cutover planning, pre-migration, cutover, hypercare and wave closure. During cutover, [applications are stopped in the current location, data is synchronized one last time, business testing is performed and the migration is finalized](https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/wave-planning.html). Hypercare keeps migration and operations teams on hand to fix issues and apply optimizations; AWS's example is three days.

Write the rollback before the cutover. Microsoft says to [document rollback procedures and success criteria](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/migration-wave-planning) for each cutover, and Google's checklist starts with [a rollback strategy for each step](https://docs.cloud.google.com/migration-center/docs/plan-migration-waves). We agree three things in writing before a wave starts: what triggers a rollback, how long the rollback window stays open, and which way data syncs if traffic goes back. The pilot rehearses all three, so the first real rollback is never the first attempt.

![Three trains of boxes on parallel tracks run from a server rack on the left to a cloud on the right: one has arrived, one is half way, one waits. An orange arrow runs back from the cloud to the rack.](https://computese.com/images/blog/cloud-migration-strategy/wave-rollback.200c75a265-1536.webp)

*A rollback that is written down and rehearsed before the wave starts is what makes a cutover safe to attempt.*

One plain file in version control can hold a wave and its rollback. This layout is illustrative, not a vendor schema:

```yaml
wave: 1
window: "Saturday 22:00 to Sunday 04:00, not a month-end weekend"
applications: [hr-portal, hr-reports, timesheets-db]
rollback:
  trigger: "smoke tests fail, or an exit check is still open at 02:00"
  window: "source kept read-only for 14 days"
  data: "writes made in the cloud are copied back to the source"
```

If the application is a public website, plan the redirects and the DNS change with [website migration without losing SEO](https://computese.com/website-migration-seo/).

## Move databases: online or offline, and when to cut over

Databases need their own plan because the data must be identical at cutover. An offline (one-time) migration copies a snapshot, and [Google's Database Migration Service](https://docs.cloud.google.com/database-migration/docs/overview) notes that there can be no new writes to the source while it runs, so applications that depend on it can be down for the copy. An online (continuous) migration does an initial full load, then streams changes until the target is in sync, and you finalize at a short cutover.

AWS Database Migration Service (DMS) has three [migration types](https://docs.aws.amazon.com/cli/latest/reference/dms/create-replication-task.html): `full-load`, `cdc` and `full-load-and-cdc`. [Azure Database Migration Service](https://learn.microsoft.com/en-us/azure/dms/dms-overview) offers online and offline modes, depending on the target (as of its February 2026 update). An AWS task is one CLI call, with the tables to move chosen by selection rules in a JSON file:

```bash
aws dms create-replication-task \
  --replication-task-identifier orders-db-wave2 \
  --source-endpoint-arn "$SOURCE_ENDPOINT_ARN" \
  --target-endpoint-arn "$TARGET_ENDPOINT_ARN" \
  --replication-instance-arn "$REPLICATION_INSTANCE_ARN" \
  --migration-type full-load-and-cdc \
  --table-mappings file://table-mappings.json
```

Three limits shape the plan. First, AWS says DMS change capture [does not provide real-time replication and has no latency SLA](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Task.CDC.html): lag can reach several minutes or longer. Watch the `CDCLatencySource` and `CDCLatencyTarget` [metrics](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html): if they are nearly equal, check the source side first; if the target value is higher, check the target. Second, source engines need setup: Oracle needs supplemental logging and MySQL needs row-level binary logging. Third, views move only in `full-load` tasks; a task that includes CDC carries tables only.

A cutover then runs in a fixed order:

1. Run full load plus CDC for days before the window, and watch the lag.
2. At the start of the window, stop writes at the source: read-only mode or an application stop.
3. Wait for the lag to drain, then compare row counts or checksums on the tables that matter.
4. Switch connection strings, run smoke tests, and keep the old database read-only.
5. Decide which side is authoritative if you roll back. AWS DMS can [replicate in both directions](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Task.CDC.html) between two systems on some engines, but AWS says it is not a multi-master solution: a data element changed on one node must never be changed on the other. Allow one writer at a time.

Take a restore-tested backup before every cutover: a [backup strategy that survives ransomware](https://computese.com/how-to-create-a-secure-backup-strategy-for-your-data/) is also the rollback of last resort. A bank's move from OpenShift 3 to 4 used the same pattern for storage volumes, a pre-sync and checksum-verified delta syncs, so that only the final changes were left for [one short change window](https://computese.com/work/banking-platform-migration/).

## Where do containers and a VMware exit fit?

Replatforming to containers is a common middle path: the code stays and the runtime changes. Containerizing is easier when the application already follows [Twelve-Factor App](https://12factor.net/) habits: configuration stored in the environment, stateless processes, fast start-up with graceful shutdown, and logs treated as event streams. An application that keeps sessions in memory or settings in files on the server usually needs code changes first, which moves it from replatform toward refactor. [OpenShift vs Kubernetes](https://computese.com/openshift-vs-kubernetes/) covers which platform to land on.

When a VMware renewal or a hardware refresh sets the deadline, relocate is the shortest path: AWS calls it the quickest way to migrate because it does not touch the application's architecture. The managed VMware services, each running VMware on bare metal, are [Amazon Elastic VMware Service](https://docs.aws.amazon.com/evs/latest/userguide/what-is-evs.html), [Azure VMware Solution](https://learn.microsoft.com/en-us/azure/azure-vmware/introduction) and [Google Cloud VMware Engine](https://docs.cloud.google.com/vmware-engine/docs/overview). The trade-off is a second move: relocate keeps the VMware stack, so plan the replatform or the exit in the same strategy, and compare licence terms in the TCO. [VMware alternatives](https://computese.com/vmware-alternatives/) compares the routes off VMware.

## Keep cost and governance in check after cutover

A migration that ends at cutover starts a bill nobody owns. Set up four habits in the landing zone before the first wave:

- **Tag at creation.** Owner, application, environment and wave on every resource, enforced by policy rather than a spreadsheet.
- **Budgets and alerts** per account or subscription, in place before the first workload lands.
- **Rightsize from measured use**, not the old server's specification. AWS's discovery tool collects performance data so that AWS Transform can [recommend the most cost-effective instance type](https://aws.amazon.com/blogs/migration-and-modernization/introducing-the-aws-transform-discovery-tool/).
- **Retire the source.** Google's checklist says to [define criteria to safely retire the source environment](https://docs.cloud.google.com/migration-center/docs/plan-migration-waves). Until old hosts are off and their licences and support contracts are released, you pay twice.

## Why migrations stall, and what prevents each cause

Each row pairs a failure mode with an early symptom and the control above that prevents it.

| Cause                       | What you see                                                        | What prevents it                                                      |
| --------------------------- | ------------------------------------------------------------------- | --------------------------------------------------------------------- |
| Unknown dependencies        | A cutover breaks something nobody listed, such as a batch job       | Collect across a month-end, filter shared services, interview owners  |
| No agreed rollback          | The cutover fails and the team fixes forward under pressure         | Trigger, window and data direction in writing, rehearsed in the pilot |
| Skills on the critical path | Early waves slip while the team learns the platform                 | Rehost or pilot first; modernize only with the skills and time        |
| Licence surprises           | BYOL is not allowed, or the licence count differs in the cloud      | Check terms per product during assessment; confirm in writing         |
| Egress and transfer costs   | The first bill shows data leaving the cloud for on-premises systems | Model transfer per dependency; move chatty pairs together             |
| Scope drift                 | Applications change while the plan stands still                     | One source of truth for scope, with change control                    |

[Microsoft says](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/select-cloud-migration-strategy) to modernize when the team has the required skills and time, and AWS says a [scope change control mechanism requires a single source of truth](https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/wave-planning.html) for the scope.

## A migration plan you can start this month

1. Name an owner for every application and export the inventory from your configuration database or discovery tool.
2. Start dependency collection now. It has to cover a month-end.
3. Give each application one R and a one-line reason. Settle retire and retain first.
4. Check licences and data transfer for the most expensive workloads before dating any wave.
5. Build and test the landing zone: identity, network, logging, tags and budgets.
6. Pick the pilot: low risk, few dependencies, room for a cutover window, plus one representative complex workload.
7. Write the pilot's runbook and rollback, and rehearse both on a copy.
8. Plan only the next wave in detail, set review points, and run it.

If you want an outside review of the plan, our [cloud readiness assessment](https://computese.com/services/cloud-transformation/) ends in an application inventory and dependency map, a disposition per workload with reasoning, a target architecture and landing zone outline, and a wave plan with a risk register and cost model.

## Key terms
- **Seven Rs**: The seven treatments AWS lists for a workload: retire, retain, rehost, relocate, repurchase, replatform and refactor or re-architect. Gartner started the idea in 2011 with five options.
- **Rehost (lift and shift)**: Moving an application to the cloud with no changes to the application. It tends to be the quickest route, but the workload is not optimized for the cloud afterwards.
- **Replatform**: Moving an application with a few optimizations, such as a managed database or a container, without changing its core architecture. AWS also calls it lift, tinker and shift.
- **Refactor (re-architect)**: Changing an application's architecture to use cloud-native features. AWS calls it the most complex and costly strategy. Microsoft, Google and Gartner each use the word for a different depth of change.
- **Relocate**: AWS's seventh R: moving many servers at once from an on-premises platform to a cloud version of the same platform, or to another VPC, Region or account, with no need to rewrite the application.
- **Migration wave**: A group of applications, chosen by dependency and risk, that cut over together. AWS recommends keeping a wave within 6 to 10 weeks.
- **Landing zone**: The governed cloud foundation that workloads move into: accounts or subscriptions, identity, network, policy guardrails and logging, ideally defined as code.
- **Change data capture (CDC)**: Reading a database's transaction log to copy ongoing changes to a target while the source stays in use, so a database can move with minimal downtime.
- **Hypercare**: A short period after cutover when migration and operations teams are both on hand to fix issues and tune the application. AWS gives three days as an example.
- **BYOL (bring your own licence)**: Running vendor software in the cloud under a licence you already own, where the vendor's terms allow it, instead of paying a licence-included price.

## Common questions

### What are the 7 Rs of cloud migration?

AWS lists seven strategies for moving an application: retire, retain, rehost, relocate, repurchase, replatform and refactor (or re-architect). The list grew from Gartner's five options in 2011 and AWS's own six in 2016, which did not include relocate. Microsoft and Google use similar words, but their lists differ.

### What is the difference between rehost, replatform and refactor?

Rehost moves an application with no changes. Replatform adds a few optimizations, such as a managed database or a container, without changing the core architecture. Refactor changes the architecture to use cloud-native features, and AWS calls it the most complex and costly of the seven.

### Is lift and shift a bad cloud migration strategy?

No. It is a sound first move when a date forces the decision, such as a data center exit or a licence renewal, and the application is stable. Its limit is that the workload is not optimized for the cloud, so the plan needs an optimization step with an owner and a date. Microsoft suggests rehosting only workloads you expect to stay as they are for at least two years.

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

The strategy is the treatment chosen for each application and the reason for it. The plan sequences those decisions: which applications move together in which wave, who owns each step, the entry and exit criteria, the cutover runbook, the rollback and the dates.

### How do you migrate a database to the cloud with minimal downtime?

Use an online migration: a full load of the existing data, then change data capture so the target stays in sync while the source is in use. In the cutover window you stop writes, wait for the lag to drain, check the data and switch the application over. AWS says its DMS change capture has no latency SLA, so measure the lag well before the window.

### In what order should applications move to the cloud?

Start with a low-risk pilot with few dependencies, move non-production before production, and put applications that depend on each other in the same wave. Microsoft advises adding one or two complex workloads to each early wave, to expose the challenges mission-critical applications bring, and defining only the next wave in detail.

### Should every application move to the cloud?

No, which is why retire and retain are on the list. In 2016 AWS wrote that as much as 10 percent of an enterprise IT portfolio (its author had seen 20 percent) is no longer useful. Common reasons to retain include data residency rules, hardware with no cloud equivalent and a recent upgrade.

## Sources
1. [About the migration strategies](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html), AWS Prescriptive Guidance
2. [6 Strategies for Migrating Applications to the Cloud](https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/), AWS Enterprise Strategy Blog
3. [New possibilities: seven strategies to accelerate your application migration to AWS](https://aws.amazon.com/blogs/enterprise-strategy/new-possibilities-seven-strategies-to-accelerate-your-application-migration-to-aws/), AWS Enterprise Strategy Blog
4. [Gartner Identifies Five Ways to Migrate Applications to the Cloud (press release, 16 May 2011, archived copy)](https://web.archive.org/web/20130123224850/http://www.gartner.com/newsroom/id/1684114), Gartner, via the Internet Archive
5. [Select your cloud migration strategies](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/select-cloud-migration-strategy), Microsoft Cloud Adoption Framework
6. [Migrate to Google Cloud: Get started](https://docs.cloud.google.com/architecture/migration-to-gcp-getting-started), Google Cloud Architecture Center
7. [AWS Service Availability Updates](https://aws.amazon.com/about-aws/whats-new/2025/10/aws-service-availability/), AWS What's New
8. [Introducing the AWS Transform discovery tool](https://aws.amazon.com/blogs/migration-and-modernization/introducing-the-aws-transform-discovery-tool/), AWS Migration and Modernization Blog
9. [Dependency analysis in Azure Migrate](https://learn.microsoft.com/en-us/azure/migrate/concepts-dependency-visualization?view=migrate), Microsoft Learn
10. [Migration Center overview](https://docs.cloud.google.com/migration-center/docs/migration-center-overview), Google Cloud Documentation
11. [Migration wave planning](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/migration-wave-planning), Microsoft Cloud Adoption Framework
12. [Wave planning](https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/wave-planning.html), AWS Prescriptive Guidance
13. [Plan your migration waves](https://docs.cloud.google.com/migration-center/docs/plan-migration-waves), Google Cloud Migration Center
14. [Understand licensing for SQL Server on Amazon EC2](https://docs.aws.amazon.com/sql-server-ec2/latest/userguide/sql-server-on-ec2-licensing.html), Amazon Web Services
15. [Azure Hybrid Benefit for Windows Server](https://learn.microsoft.com/en-us/windows-server/get-started/azure-hybrid-benefit), Microsoft Learn
16. [Licensing Oracle Software in the Cloud Computing Environment](https://www.oracle.com/a/ocom/docs/cloud-licensing-070579.pdf), Oracle
17. [Overview of data transfer costs for common architectures](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/), AWS Architecture Blog
18. [COST08-BP01 Perform data transfer modeling](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_data_transfer_modeling.html), AWS Well-Architected Framework
19. [What is an Azure landing zone?](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/), Microsoft Cloud Adoption Framework
20. [AWS multi-account strategy for your AWS Control Tower landing zone](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html), AWS Control Tower User Guide
21. [Database Migration Service overview](https://docs.cloud.google.com/database-migration/docs/overview), Google Cloud Documentation
22. [Creating tasks for ongoing replication using AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Task.CDC.html), AWS Database Migration Service User Guide
23. [create-replication-task](https://docs.aws.amazon.com/cli/latest/reference/dms/create-replication-task.html), AWS CLI Command Reference
24. [Monitoring AWS DMS tasks](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html), AWS Database Migration Service User Guide
25. [What is Azure Database Migration Service?](https://learn.microsoft.com/en-us/azure/dms/dms-overview), Microsoft Learn
26. [The Twelve-Factor App](https://12factor.net/), Heroku (Adam Wiggins)
27. [What is Amazon Elastic VMware Service?](https://docs.aws.amazon.com/evs/latest/userguide/what-is-evs.html), Amazon Web Services
28. [Introduction to Azure VMware Solution](https://learn.microsoft.com/en-us/azure/azure-vmware/introduction), Microsoft Learn
29. [Google Cloud VMware Engine overview](https://docs.cloud.google.com/vmware-engine/docs/overview), Google Cloud Documentation