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

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

Gartner named five options in May 2011: rehost, refactor, revise, rebuild and replace. In November 2016 AWS built on those five with six: rehost, replatform, repurchase, refactor or re-architect, retire and retain. AWS later said 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 and the addition is relocate.

Microsoft's Cloud Adoption Framework (updated July 2025) lists eight options and Google Cloud lists six migration types, with different words for the same decisions (the match is approximate):

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 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 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.

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

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, not a migration task, and the case study on legacy Java, from Struts to Spring Boot shows the assessment that comes first. For a serverless target, see how serverless computing works and what it costs.

When is lift and shift the right first move?

Rehost, also called lift and shift, moves an application to the cloud without changing it. 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 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, 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: 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.

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: they closed to new customers from 7 November 2025, and existing customers can keep using them. 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 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 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 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.

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 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 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 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.

Data gravity and transfer costs finish the assessment. AWS charges nothing for inbound data transfer, 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 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 an Azure landing zone as an architecture for governing, securing and scaling a multi-subscription environment, and AWS Control Tower 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. 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 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, 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.

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. 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 for each cutover, and Google's checklist starts with a rollback strategy for each step. 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.

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

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.

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 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: full-load, cdc and full-load-and-cdc. Azure Database Migration Service 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:

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: lag can reach several minutes or longer. Watch the CDCLatencySource and CDCLatencyTarget metrics: 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 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 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.

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 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 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, Azure VMware Solution and Google Cloud VMware Engine. 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 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.
• Retire the source. Google's checklist says to define criteria to safely retire the source environment. 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.

Microsoft says 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 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 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.