Cloud Migration Strategies: The 7 Rs and How to Choose

A cloud migration strategy is chosen per workload, not per company. The 7 Rs (retire, retain, rehost, relocate, repurchase, replatform and refactor) are the options, and each application gets the one that fits its business value, deadline, technical shape and the team's skills. Programs that go well retire everything they can, rehost or replatform most of the rest quickly, and save refactoring for the few systems that differentiate the business and will keep changing.

Key takeaways

• Decide per workload. A single strategy for the whole estate is either too slow (refactor everything) or too expensive afterwards (rehost everything and stop).
• Retire first. Discovery always finds applications nobody needs, and those are the cheapest migrations there are.
• Dependencies decide the waves. Applications that talk to each other heavily move together, or the hybrid network becomes the bottleneck.
• Rehosting is a step, not a destination. Plan the right-sizing and replatforming that follow it.
• Database cutovers should use change data capture, not a long freeze. Validate on the synced copy, cut over in minutes, keep a way back.
• Parity in observability, backups and access control must exist before cutover, not after.

The seven Rs at a glance

AWS's list started as six Rs and later added relocate for moving whole virtualization platforms. The categories apply on any cloud.

Lift-and-shift versus re-architecture: the real trade-off

The usual framing makes lift-and-shift sound lazy and re-architecture sound wise. In practice they optimize for different things.

Rehosting wins when a lease, a contract or a hardware refresh sets the date, and when the application is stable and rarely changes. Once it runs in the cloud, it can be right-sized against real metrics, moved to managed services piece by piece, and refactored only if it earns it. Our cloud cost optimization guide covers the right-sizing step that should follow every rehost.

Refactoring wins when the application is a core product that will keep receiving investment, when its current architecture limits the business (scaling, release speed, reliability), or when it would need changes anyway to run well in the cloud. Even then, refactor incrementally. Move first, then extract pieces using the strangler fig pattern: route one capability at a time to new code while the old system serves the rest. Our guides to microservices patterns and serverless patterns cover the target designs.

A decision flow for each workload

Run every application through the same questions, in the same order. The order matters: retiring and retaining are decided before anyone debates architecture.

Record for each workload the answers and the reasons, not just the chosen R. A one-page sheet per application is enough:

• Owner, business purpose and users.
• Change frequency (how often it is deployed) and expected lifetime.
• Dependencies: inbound and outbound connections, shared databases, file shares, identity, scheduled jobs.
• Data: size, growth, sensitivity, residency constraints.
• Constraints: licensing terms, hardware or latency ties, compliance requirements, support contracts.
• Recovery needs: acceptable downtime during cutover and in normal operation.
• Chosen strategy, the reason, and what happens after the move.

Discovery and dependency mapping

Dependency mapping is the step teams most want to skip and most regret skipping. Undocumented dependencies are what break on cutover night.

Use the discovery tooling for your target cloud to get an inventory and connection data: AWS Transform (which replaced AWS Application Discovery Service for new customers in November 2025), Azure Migrate or Google Cloud Migration Center. Agent-based collection gives you process-level connections over time, which matters, because a monthly batch job will not show up in a one-day sample.

Then verify on the hosts themselves. Which clients connect to this database, and from where?

ss -Htn state established '( sport = :5432 )' \
  | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn

Run it on a schedule for a few weeks and merge the results; a single snapshot misses periodic jobs. Look for the dependencies that tooling misses:

for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
systemctl list-timers --all
grep -rEn '([0-9]{1,3}\.){3}[0-9]{1,3}' /etc/myapp /opt/myapp \
  --include='*.conf' --include='*.properties' --include='*.yml' --include='*.xml'

Scheduled jobs, hardcoded IP addresses, SMTP relays, license servers, LDAP or Active Directory lookups, NFS mounts and partner IP allowlists are the classic surprises. Each one is either a dependency to move, an endpoint to keep reachable, or a configuration change to make during cutover.

From the dependency data, build move groups: sets of applications that must move in the same window because they talk to each other too often to tolerate a hybrid link between them. A web app that makes dozens of database calls per request cannot run in the cloud with its database still on-premises; added round-trip latency multiplies per call.

Wave planning

A wave is a batch of move groups migrated in one planned window. Waves exist so you can prove the process on low-risk workloads before you move the systems that pay the bills.

Wave 0 is the one teams rush. Everything after it inherits its decisions: the account structure, the IP addressing plan (overlapping ranges with on-premises networks are painful to fix later), the identity model and the logging pipeline. Build it as infrastructure as code from day one so that every later wave lands in a known, reviewed environment.

Cutover mechanics

Servers: continuous replication

For rehosting, tools such as AWS Transform MGN (formerly AWS Application Migration Service) install an agent on the source server and replicate its disks at block level into a staging area in your account, continuously. You launch test instances from the replica as often as you like without touching the source. Cutover is then a short sequence: stop the application on the source, let replication catch up, launch the cutover instance, switch traffic.

Databases: full load plus change data capture

For databases, avoid "stop everything and dump" unless the data is small. Copy the bulk of the data while the source keeps serving traffic, keep the target in sync with change data capture (CDC), and cut over when the target is current.

With AWS Database Migration Service (DMS) the task looks like this:

aws dms create-replication-task \
  --replication-task-identifier orders-db-to-aurora \
  --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

{
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "include-orders-schema",
      "object-locator": { "schema-name": "orders", "table-name": "%" },
      "rule-action": "include"
    }
  ]
}

Things that catch teams out. CDC needs the source configured for it: row-based binary logging on MySQL, logical replication on PostgreSQL. DMS creates tables with what it needs to move data, not your full schema; secondary indexes, foreign keys, sequences, triggers and stored procedures come from a schema conversion step or native tooling. For same-engine moves, native replication (PostgreSQL logical replication, MySQL replicas) is often simpler and more faithful. Watch the CDCLatencySource and CDCLatencyTarget metrics; cut over only when latency is near zero and stable.

The cutover runbook

A runbook for a core system, written so a tired engineer can follow it:

1. Days before: lower DNS TTLs on every record you will change, confirm the rollback path, freeze schema changes, announce the window.
2. Validation on the synced copy: row counts and checksums per table, application smoke tests against the target in read-only mode, performance test on target infrastructure.
3. Go/no-go: replication lag, error budget for the window, people on call on both sides.
4. Cutover: stop writes (maintenance mode or revoked write grants), wait for CDC to drain, verify final counts, point the application at the target, reopen writes.
5. Verify: synthetic checks, error rates, latency against the pre-migration baseline, business metrics such as orders per minute.
6. Rollback criteria, decided in advance: which signals trigger a rollback and who decides. If you have reverse replication from target to source, rollback is a repeat of step 4 in the other direction. Without it, the source data goes stale from the moment writes resume.
7. After: keep the source available but read-only for an agreed period, then decommission in wave 5.

Some clients ignore DNS TTLs in practice. Connection pools keep talking to the old address until their connections are recycled, and some runtimes and client libraries cache DNS results longer than the TTL. Plan to restart them, or point them at the new endpoint by configuration rather than relying on DNS.

Replatform moves worth making during migration

Replatforming pays when the change removes operational work and the replacement is mature and boring:

Pick two or three per application at most. Every replatform change is a new component to learn and monitor, and changing everything at once makes a failed cutover hard to diagnose.

Licensing, data transfer and double running

Three costs are routinely missed in migration business cases.

Licensing. Commercial databases and enterprise software often have specific rules for cloud use: how virtual CPUs are counted, whether licenses can move to shared infrastructure, whether dedicated hosts are required. Read the terms before choosing the strategy. Sometimes they make repurchase or a move to an open-source engine the cheaper path.

Data transfer. Moving large datasets over the network takes longer than expected and competes with production traffic on the same link. Plan bulk transfer early (online transfer services or offline transfer for very large datasets) and use CDC for the final delta.

Double running. For the duration of the program you pay for both environments. The longer the waves drag on, the more this costs, which is a strong argument for rehosting quickly and optimizing afterwards.

What goes wrong in production

These are the failures that turn a cutover night into an incident, from the perspective of the people on call for it.

The dependency nobody listed. The finance export that runs on the first of the month, the partner who allowlists your old IP, the license server in the data center. Weeks of connection data and a search for hardcoded addresses catch most of them; a dark launch of the new environment catches the rest.

Storage that behaves differently. A database that ran on a fast SAN lands on block storage with a different IOPS and throughput profile, and latency climbs under real load. Load test on the target storage configuration, not on a smaller dev copy.

The hybrid link as a bottleneck. Half of a move group migrates, the other half waits, and every request now crosses a VPN with added latency and limited bandwidth. Move groups exist to prevent this.

No observability parity. The old environment had years of dashboards and alerts; the new one has defaults. Build monitoring, log shipping and alerting for the target before cutover, and compare against a pre-migration baseline. Our guide to observability in production covers what to put in place.

Rollback that was never rehearsed. Teams write rollback steps and never run them. Rehearse the rollback in the pilot wave, and decide in advance which signals trigger it.

Rehost and forget. Instances sized like the old physical servers, running around the clock, with no commitments and no right-sizing. The migration is declared done, and the bill becomes the argument against the cloud. Schedule the optimization pass as part of the program.

Frequently Asked Questions

What are the 7 Rs of cloud migration?

The 7 Rs are retire, retain, rehost, relocate, repurchase, replatform and refactor. Each is a different answer to what should happen to one workload: switch it off, leave it, move it as is, move its virtualization platform, replace it with SaaS, move it with targeted changes, or redesign it. AWS popularized the list, and it applies to any cloud.

Is lift-and-shift a bad migration strategy?

No. Rehosting is often the right choice when a deadline drives the move or when the application will not change much in future. It becomes a bad strategy only when it is treated as the end state, leaving data-center-shaped architecture running at cloud prices. Plan right-sizing and replatforming steps for after the move.

What is the difference between rehost and replatform?

Rehosting moves a server to the cloud unchanged, typically with block-level replication into a virtual machine. Replatforming makes targeted changes during the move, such as running the database on a managed service or the app in containers, without redesigning the application. Replatforming takes longer but removes operational work you would otherwise carry into the cloud.

How do you migrate a database with minimal downtime?

Copy the existing data first, keep the target in sync with change data capture, and validate while the source still serves traffic. At cutover you stop writes, wait for replication lag to reach zero, switch the application and reopen writes, which keeps downtime to minutes. Keep a reverse replication path or a tested restore so you can roll back.

What is a migration wave?

A migration wave is a batch of workloads moved together in one planned window. Waves are built from move groups, sets of applications that must move together because they depend on each other heavily. Early waves are small and low risk so the team can prove the runbook before moving critical systems.

Should you refactor an application before or after migrating it?

Usually after, unless the application is about to be rewritten anyway or cannot run in the cloud without changes. Refactoring and migrating at once doubles the risk and makes failures hard to diagnose. Moving first and refactoring incrementally lets you change one variable at a time.

Need help planning a cloud migration?

We plan migrations as the engineers who will run the result: discovery that finds the hidden dependencies, waves that prove the runbook early, and cutovers with a rehearsed way back. If we build it, we are on the pager for it, so we do not leave you with a migration that only worked on the night.

• Cloud architecture and infrastructure
• Software development
• Talk to an engineer