Running workloads across more than one cloud provider sounds good on paper: no vendor lock-in, lower costs, better resilience. But the reality is that multicloud migration is one of the more complex things a Linux team can take on. Networking differs between providers. IAM models are incompatible. Storage APIs do not map cleanly. This guide covers how to set up a multicloud environment properly and walks through the main migration strategies teams actually use in production.
Why Teams Go Multicloud
Most organizations do not plan to go multicloud. They end up there because different teams make different choices. One team starts on AWS, another prefers Azure for Microsoft integrations, and a third picks GCP for BigQuery or Vertex AI. Over time the infrastructure spans all three.
But there are deliberate reasons to run across multiple clouds too. Vendor lock-in is the most common one. If your entire stack lives in one provider, that provider controls your pricing. Spreading workloads gives you negotiating power and a fallback if one provider has a major outage. Some regulated industries also require data to stay in specific geographic regions, and not every provider covers every region equally.
The tradeoff is operational complexity. You now manage multiple billing dashboards, multiple IAM systems, multiple networking models, and multiple support contracts. Plan for that before you start.
The Foundation: Infrastructure as Code Across Clouds
The most important decision in a multicloud setup is how you manage infrastructure. Clicking through cloud consoles does not scale across one provider, let alone three. Use Infrastructure as Code from day one.
Terraform is the standard tool here. It supports AWS, Azure, and GCP through provider plugins and manages all three from one codebase. Install it on your Linux management machine:
# Ubuntu / Debian
wget -O - https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform -y
terraform versionA basic Terraform config that provisions resources on AWS and Azure from one file looks like this:
terraform {
required_providers {
aws = { source = "hashicorp/aws", version = "~> 5.0" }
azurerm = { source = "hashicorp/azurerm", version = "~> 3.0" }
}
}
provider "aws" { region = "us-east-1" }
provider "azurerm" { features {} }
resource "aws_instance" "web" {
ami = "ami-0c02fb55956c7d316"
instance_type = "t3.micro"
}
resource "azurerm_resource_group" "main" {
name = "myapp-rg"
location = "East US"
}Keep cloud credentials in environment variables, never in Terraform files. Store state files in a remote backend like S3 or Azure Blob so the whole team works from the same state.
Workload Portability with Kubernetes
Containers are the main reason multicloud migration is practical at all. A containerized app does not care whether it runs on EKS, AKS, or GKE. The Kubernetes API is consistent across all three, so you write deployment manifests once and they work everywhere with minor adjustments for load balancer classes and storage drivers.
For teams that want one control plane across all clusters, GCP Anthos and Azure Arc are the main options. Anthos manages clusters on GCP, AWS, Azure, and on-premises from one dashboard. Azure Arc extends Azure management to resources running on other clouds. Neither is perfect, but both beat managing three separate cluster fleets independently.
Before you deploy to a multicloud cluster, decide which container runtime you want on your Linux nodes. Our guide on Docker vs Podman on Linux walks through the key differences to help you choose.
The 6R Migration Strategies
Not every workload migrates the same way. The 6R framework gives you a decision model for each application. Assign an R to each workload during your planning phase, before you touch a single server.
Rehost: Lift and Shift
Move the workload to a new cloud with no changes. Export a VM image and spin it up in the target cloud. AWS Application Migration Service and Azure Migrate automate most of this process. Rehosting is fast and low-risk, but you do not get any cloud-native benefits. Use it when you have a hard deadline or a stable application that rarely changes.
Replatform: Lift and Reshape
Move the workload and swap out one or two components for managed cloud services. Replace a self-managed MySQL server with Amazon RDS or Azure Database for MySQL. The application code stays the same. The database becomes someone else’s responsibility to patch and back up. This is the most common approach for databases, caches, and message queues.
Refactor: Re-architect
Redesign the application to use cloud-native services fully. Break a monolith into microservices. Move from a cron job to event-driven functions. Use managed Kubernetes instead of self-managed nodes. Refactoring takes the most time and carries the most risk. Save it for applications that genuinely need it, not as a default strategy.
Repurchase, Retain, and Retire
Repurchase means dropping the existing software and buying a SaaS replacement instead. Retain means leaving a workload on-premises because compliance or technical constraints block migration for now. Retire means shutting down workloads nobody uses. A thorough audit before starting almost always uncovers servers that have been idle for months. Shut those down first and save the cost immediately.
Multicloud Networking
Networking is where most multicloud setups hit trouble. Each cloud uses its own VPC model, routing concepts, and firewall rules. Traffic between clouds travels over the public internet by default, which adds latency and cost.
For private connectivity between AWS and GCP, AWS launched Interconnect for multicloud in late 2025. It builds private high-throughput links between Direct Connect and GCP Interconnect points without manual cross-connects. For Azure connections, ExpressRoute combined with GCP Partner Interconnect covers the same need.
For DNS, use a provider-agnostic service like Cloudflare or AWS Route 53 as your global layer. Then you can fail over between clouds by updating DNS records rather than rewriting application configs.
Cost Management
Cloud bills across three providers are genuinely difficult to read. Each uses different names for the same concept. AWS calls it EC2, Azure calls it Virtual Machines, GCP calls it Compute Engine. The services are similar but the billing units differ.
Use a third-party cost tool from day one. CloudHealth, Spot.io, and the open-source Infracost tool all aggregate spend across providers into one view. Tag every resource consistently before migrating. A tag like env=production team=backend cloud=aws on every resource makes cost reporting much cleaner down the line.
Migration Checklist
# Before you start
1. Inventory all workloads and assign each an R strategy
2. Set up Terraform with a remote state backend
3. Configure IAM roles in each cloud with least-privilege access
4. Tag all existing resources consistently
5. Set up centralized logging across all three providers
# During migration
6. Migrate in waves - start with low-risk non-production workloads
7. Run source and target environments in parallel before cutover
8. Test rollback for each workload before cutting over DNS
9. Validate data integrity after every database migration
# After migration
10. Remove unused resources in the source environment
11. Set billing alerts in each cloud dashboard
12. Review security groups and firewall rules per cloudConclusion
A solid multicloud migration starts with clear decisions about which workloads move and how, not with which cloud logos end up on your architecture diagram. Use Terraform for infrastructure, containers for portability, and the 6R framework to assign a strategy to each workload. Sort out your networking model before you migrate the first server, not after. Tag everything from day one so your cost reports are readable six months in. If you run AI workloads as part of your multicloud setup, also read our guide on installing Ollama on Linux for running models locally alongside cloud-hosted services.