Cross-cloud migration — AWS ↔ Azure ↔ GCP ↔ OCI — is driven by cost optimization, lock-in avoidance, M&A consolidation, or compliance. Base compute rates are similar across hyperscalers, so savings usually come from rightsizing, committed-use discounts, and avoiding egress, not the move itself. Be clear on your motive before committing — it shapes the whole plan.
Lead with the landing zone
Build the target-cloud landing zone first: accounts/subscriptions, networking (VPC/VNet), IAM, and guardrails. Establish connectivity (VPN/Direct Connect/ExpressRoute) to the source for replication. Inventory source resources tagged by application, and map each managed service (databases, queues, serverless, storage) to its target equivalent — the managed-service layer is where lock-in and rework concentrate.
Use the native migration services
- Servers: AWS MGN, Azure Migrate, or Google Migrate to Virtual Machines (agent-based replication).
- Databases: AWS DMS / Azure Database Migration Service (full load + CDC).
- Storage:
aws s3 sync/azcopy/gsutil(mind egress costs).
Re-platform infrastructure as code (Terraform/Bicep/CloudFormation) rather than clicking it twice.
Cutover & validation
Final delta sync, freeze source writes, switch DNS/traffic to the target, validate apps, integrations, and cost, then run a hypercare window with the source as fallback. Test DNS failover and an IaC apply on the target during pre-checks.
Watch the egress
Large data transfers between clouds incur egress fees — factor them into both the plan and the business case. For steady-state workloads, also model whether the target’s committed-use pricing actually beats the source.
De-risking
Replicate a pilot workload + database end-to-end and validate before scaling. Keep replication tasks until cutover is signed off.
Open a source→target page for cloud-specific steps and a per-vCPU TCO model.