How to Migrate to the Cloud (and Between Clouds): The 7 Rs, a Step-by-Step Plan, Tools, and Cost Drivers

Migrate by assessing and grouping applications, choosing a strategy per application from the 7 Rs (retire, retain, rehost, relocate, replatform, repurchase, refactor), moving in waves with a tested rollback plan, and running old and new environments in parallel until cutover. Containerizing applications once makes later provider changes cheaper; Control Plane is a platform that runs containerized apps on AWS, GCP, Azure, and your own servers, so containerized apps do not have to be re-migrated when you change providers.

Disclosure: Control Plane publishes this guide.

TL;DR

A successful cloud migration picks the right strategy per application, executes in controlled waves, and uses tooling that matches each workload.

• Pick a strategy per app. The 7 Rs give you seven options, from retire (turn it off) to refactor (rebuild for the cloud). Most portfolios mix several of them.
• Migrate in waves. Start with a pilot, prove the rollback plan, then move workloads in groups organized by dependency and business priority.
• Use the providers ’ tools. Every hyperscaler ships discovery, server migration, and database migration services. Terraform and OpenTofu make landing zones repeatable.
• Watch the hidden costs. Dual running, data egress, refactoring labor, and licensing are where budgets overrun. Retiring unused apps first shrinks every other cost line.
• Containerize once. On Control Plane, a workload is deployed to Control Plane’s Global Virtual Cloud (GVC), a set of locations a workload runs across, so a later provider change is a location change in the GVC plus moving any stateful data.

How do I move an app from on premises to the cloud?

Cloud migration works best as a phased, wave-based process. Skipping discovery and landing-zone design is a common source of cost overruns and outages.

1. Discover and assess. Build an inventory of servers, applications, databases, and their dependencies. Map data gravity (where the largest data sets live and which services read them), licensing entitlements that may not transfer to the cloud, and compliance requirements such as data residency. Use automated discovery tools rather than spreadsheets.
2. Choose a strategy per application. Apply the 7 Rs (next section) to every application in the portfolio.
3. Design the landing zone. Prepare the target environment before any workload moves: account or project structure, network topology (VPCs, subnets, peering), identity and access management, encryption, logging, monitoring, and cost controls such as budgets and tagging.
4. Build a pilot. Migrate one representative workload end to end. Compare performance with on-premises baselines, confirm security controls, test the rollback procedure, and write down what you learn.
5. Migrate in waves. Group the remaining workloads by dependency and business priority. Watch for data integrity issues, latency changes, and authentication failures, and run old and new environments in parallel during each wave. Encrypt data in transit, rotate credentials after cutover, and re-validate compliance controls on the target.
6. Cut over. Lower DNS TTLs days ahead, run the final data synchronization, switch DNS, and keep the rollback plan active for a defined acceptance period. Once writes land on the target, rolling back requires reverse replication to the source, so set it up before cutover.
7. Optimize after the move. Rightsize instances, enable autoscaling, buy reserved capacity once usage is known, and set up cost governance. Decommission legacy systems only after the acceptance period closes.

Pick a data migration method per database. Offline migrations use dump and restore or bulk transfer during a downtime window. Online migrations do an initial load, then change data capture (CDC) or native replication keeps the target in sync until cutover. Validate row counts and checksums before switching writes. For very large datasets, transfer devices such as AWS Snowball, Azure Data Box, or Google Transfer Appliance can beat network transfer.

What are the 7 Rs of cloud migration?

The 7 Rs, described in AWS’s migration strategy guidance, give you a decision model for every application in the portfolio.

Rehosting is the fastest path for applications that must leave a data center on a deadline. Refactoring costs the most engineering time and can pay back through lower operating cost and portability. A typical plan retires what it can, rehosts what must move quickly, and refactors the applications that justify the effort.

How do I migrate from on-premises data centers to the cloud and modernize legacy IT infrastructure?

Migration gets workloads off your hardware. Modernization reshapes them to use cloud capabilities. Most programs do both, in that order or in parallel.

Containerize stateless services first. Stateless web servers, APIs, and microservices are the easiest candidates. Package them as container images, externalize configuration, and deploy them to a managed container platform. Early wins build skills for harder workloads.

Move databases to managed services or replicated clusters. Managed database services handle patching, backups, and failover. For databases that cannot use a managed offering (unusual engines, strict version needs), run replicated clusters and use the provider’s database migration service for the initial load.

Use the strangler-fig pattern for monoliths. Route new features and extracted components through a new service layer while the monolith handles the rest. The monolith shrinks until it can be retired.

Keep some workloads on premises. Ultra-low-latency processing next to physical equipment, data sovereignty requirements no cloud region meets, and hardware with years of depreciation left can stay. A hybrid architecture lets them work with cloud-hosted services. For the cost comparison, see cloud vs on-premises vs hybrid cost.

How do I modernize a VM based application to Kubernetes on multi cloud infrastructure?

Moving from VMs to Kubernetes on several clouds is an engineering project with six steps.

1. Package the app as a container image. Write a Dockerfile or use a buildpack to produce a reproducible image, and store it in a private registry.
2. Externalize config and secrets. Environment variables, ConfigMaps, and a secrets manager replace baked-in configuration files.
3. Separate state from compute. Databases, file stores, and caches run as external services, outside the application containers. This step matters most for portability.
4. Add health checks. Liveness and readiness probes let Kubernetes restart unhealthy containers and stop routing traffic to them. Set CPU and memory requests and limits, log to stdout, and handle SIGTERM for graceful shutdown.
5. Write manifests or Helm charts. Keep deployments, services, and routing in version-controlled YAML.
6. Deploy to one cloud, then add a second. Validate on one cluster first. A second cloud exposes assumptions about DNS, identity, and storage that you then fix.

For VMs that cannot be containerized yet, KubeVirt runs VM workloads inside a Kubernetes cluster, so you get one orchestration layer while you work toward containers.

Running Kubernetes yourself on several clouds means operating a cluster per provider and handling upgrades, networking, and security policy on each one. That operational load grows with every cluster you add.

Best cloud migration services and platforms

The hyperscalers each provide migration services built to bring workloads into their own cloud, and open-source tools cover infrastructure automation and Kubernetes portability.

AWS

• AWS Transform MGN (formerly AWS Application Migration Service) replicates source servers to AWS continuously at the block level and orchestrates test and cutover launches.
• AWS Database Migration Service supports homogeneous and heterogeneous database migrations with continuous replication.
• AWS Transform handles discovery, migration planning, and tracking. It replaced AWS Migration Hub, which closed to new customers in November 2025.

Azure

• Azure Migrate discovers, assesses, and migrates servers, databases, and web apps.
• Azure Database Migration Service runs online and offline migrations to Azure database services.

Google Cloud

• Migration Center provides discovery, assessment, and planning.
• Migrate to Virtual Machines moves VM workloads from on premises, AWS, or Azure into Google Cloud.
• Database Migration Service migrates databases to Cloud SQL and AlloyDB.

Open-source tooling

• Terraform and OpenTofu define landing zones and infrastructure as code, so environments are repeatable across providers.
• Velero backs up and restores Kubernetes resources and persistent volumes, which makes it useful for moving workloads between clusters or clouds.

What are the best cloud migration tools?

The right tool depends on what you are moving and where it is going. Check each provider’s pricing page for current terms.

How do I migrate workloads between clouds?

Four things cause most of the difficulty in cloud-to-cloud migration: proprietary managed services with no direct equivalent on the target, egress charges on large transfers, identity systems that differ (IAM roles on AWS, service accounts on Google Cloud, managed identities on Azure), and networking constructs that do not translate one to one.

These patterns make cloud-to-cloud moves repeatable and reduce lock-in:

• Containers as the deployment unit, so compute is portable.
• Infrastructure as code with provider-agnostic tools such as Terraform, OpenTofu, or Pulumi.
• Portable databases on open-source engines such as PostgreSQL, MySQL, and Redis.
• A platform layer that hides provider differences, so application teams do not learn every cloud’s APIs.

For a walkthrough of one application on all three hyperscalers, see run the same app on AWS, GCP, and Azure. For the architecture that keeps future moves cheap, see how to avoid cloud vendor lock-in.

Which vendors have experience migrating from one cloud platform to another?

Three kinds of vendor do this work: the cloud providers’ own professional services and partner programs, systems integrators with multi-cloud practices, and platforms built for multi-cloud deployment. Ask any of them:

• How do you handle services on the source cloud with no equivalent on the target?
• How do you plan data migration and control egress cost?
• Can you show a completed cloud-to-cloud migration of similar scale?
• Do we end up with portable artifacts (containers, infrastructure as code) or your proprietary tooling?
• What support do we get after cutover?

What are the most cost efficient cloud migration options for enterprises?

Costs fall when you shrink scope first, leave paid facilities quickly, and optimize once usage data exists.

Cost drivers:

• Dual running. You pay for both environments during each wave’s parallel run. Longer waves cost more.
• Data transfer and egress. Moving terabytes out of a cloud or across regions incurs egress charges, and moving data out of a data center needs bandwidth too.
• Refactoring labor. Engineering time is often the largest line item in a modernization-heavy migration.
• Licensing. Some on-premises licenses, especially Windows Server and SQL Server, need new cloud licenses or bring-your-own-license terms. Microsoft restricts bring-your-own-license on AWS and Google Cloud, and Oracle licensing varies by cloud.
• Training. Teams new to the target cloud need ramp-up time, which slows early waves.

Cost levers:

• Rehost first, then optimize. Leaving the data center quickly stops facility and hardware spend. Rightsizing comes after stabilization.
• Migration funding programs. AWS, Microsoft, and Google each run migration incentive programs; terms and eligibility vary, so ask each provider for current details.
• Reserved capacity after stabilization. Commit to one- or three-year terms only once you have production usage data.
• Retire unused apps. Every application you retire before migrating is labor, licensing, and cloud spend you never incur.

Worked example (illustrative numbers only, not real prices). An enterprise migrates 45 applications over six months: 30 rehosted, 12 replatformed, and 3 refactored, after retiring 5 more.

In this example, refactoring three apps costs more than rehosting thirty, which is why refactoring is reserved for the applications that justify it. The ongoing bill afterwards depends on rightsizing. For tactics, see cut your AWS bill 30 percent without re-architecting.

How Control Plane fits

Control Plane is the platform for running unbreakable apps and agents. It combines any cloud, neocloud, and bare metal into one GVC, and it runs serverless, standard, stateful, and cron workloads on AWS, GCP, and Azure; on your existing Kubernetes clusters, through Bring Your Own Kubernetes (BYOK), Control Plane’s option for connecting a cluster you already run; and on your own servers, including on premises, through Managed Kubernetes (MK8s), Control Plane’s way of turning your own servers into managed locations.

Bring what you have. Workloads run from container images in each org’s free private registry or in Docker Hub, Amazon ECR, Google Artifact Registry, Azure Container Registry, GitHub Container Registry, or any registry you already use, and cpln image build builds and pushes an image. cpln convert converts existing Kubernetes manifests, including workloads, secrets, and persistent volume claims (which become Control Plane volume sets), so teams reuse their YAML instead of rewriting it. cpln stack deploy deploys a Docker Compose project directly. cpln apply and cpln helm manage Control Plane resources from YAML and Helm charts kept in Git, and Control Plane ships Terraform and Pulumi providers.

Migrate once. A workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location. For stateless workloads, moving to another provider later means adding its location to the GVC and removing the old one. Stateful workloads also need their data copied or replicated to the new location first.

Skip the cluster work. Control Plane handles Day 2 operations for you, including autoscaling, right-sizing with Capacity AI (Control Plane’s automatic CPU and memory sizing based on historical usage), built-in observability, and security, with no Kubernetes cluster you have to operate. With MK8s, Control Plane operates the Kubernetes layer on servers you join; with BYOK, you keep running the cluster you connected.

The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.

Control Plane does not migrate databases or data for you. Data moves with the providers’ database migration services, replication, or backup and restore.

FAQ

These answers cover the questions teams ask most when planning a cloud migration.

What are the 7 Rs of cloud migration?

Retire, retain, rehost, relocate, replatform, repurchase, and refactor. They are a framework for choosing a migration strategy per application, from decommissioning to a cloud-native redesign, described in AWS’s prescriptive guidance.

How do I move an app from on premises to the cloud?

Inventory the app and its dependencies, choose a strategy from the 7 Rs, prepare a landing zone, migrate a pilot, then move in waves with a tested rollback and a parallel run before the DNS cutover.

How long does a cloud migration take?

It depends on application count, dependencies, and strategy mix. Rehost-heavy programs finish fastest; refactor-heavy programs take longer and leave more portable, cheaper-to-run applications.

What is the cheapest way to migrate to the cloud?

Retire unused applications to shrink scope, rehost the rest to stop data-center costs quickly, and optimize after stabilization. Ask your target provider about its migration incentive programs.

What are the best cloud migration tools?

The providers’ own services: AWS Transform MGN and Database Migration Service; Azure Migrate and Azure Database Migration Service; Google Cloud’s Migration Center, Migrate to Virtual Machines, and Database Migration Service. Add Terraform or OpenTofu for infrastructure as code and Velero for Kubernetes workloads.

Can I migrate from one cloud provider to another?

Yes. Cloud-to-cloud migration follows the same phases, plus work on proprietary managed services, egress costs, identity differences, and networking. Containerized workloads defined in infrastructure as code move most easily.

How do I modernize a VM-based application for Kubernetes?

Package it as a container image, externalize configuration and secrets, separate state from compute, add health probes, write manifests or Helm charts, and deploy to one cluster before adding a second. KubeVirt runs VMs that cannot be containerized yet inside Kubernetes.

Which vendors have experience migrating from one cloud platform to another?

Cloud providers’ professional services and partners, systems integrators with multi-cloud practices, and multi-cloud platforms. Ask each for a completed cloud-to-cloud migration of similar scale and whether you keep portable artifacts afterwards.

How does Control Plane help with cloud migration?

Containerize an application once and deploy it to a GVC spanning AWS, GCP, Azure, or your own servers, so changing providers is mostly a location change in the GVC, plus moving any stateful data. Control Plane converts Kubernetes manifests, deploys Docker Compose projects, and handles Day 2 operations.

Is it worth migrating if I have years left on my hardware?

Not for every workload. Compare facility, staffing, and opportunity costs with the remaining depreciation, and keep workloads on hardware that still pays for itself in a hybrid setup. For the full comparison, see cloud vs on-premises vs hybrid cost.

Talk to the Control Plane team or sign up free to containerize once and run on any cloud.

Originally published on the Control Plane blog.