Move between AWS, Azure and Google Cloud safely
Move workloads between AWS, Azure and Google Cloud in any direction, with each service mapped, rebuilt in code and cut over with a rollback ready.
Overview
Companies switch clouds for ordinary reasons: an acquisition on another provider, a customer that mandates Azure, credits that ran out, or a team that knows one platform far better. The hard part is rarely the virtual machines. It is identity, networking, managed databases, queues and all the small integrations nobody wrote down.
We map every service to its equivalent on the target cloud, rebuild the foundation in infrastructure as code and move workloads in waves. Each wave has a cutover window, verification checks and a way back. Old resources are only removed once the new ones have carried production traffic.
Signs you need this
- You pay for two clouds and most of the expertise is on one of them
- Your services use provider-specific features with no plan for their replacement
- Previous migration attempts stalled after the easy workloads moved
- IAM, DNS and networking between the clouds are held together by manual changes
What you get
- Service mapping
- Each source service matched to a target service, for example SQS to Service Bus or Cloud SQL to RDS, with behaviour differences noted.
- Wave plan
- Workloads grouped by dependency and risk, with an order of moves your team agrees to before work starts.
- Target foundation in code
- Accounts or subscriptions, networking, identity and shared services on the target cloud, written in Terraform.
- Data transfer setup
- Replication for databases and sync for object storage, sized so transfer finishes inside the planned windows.
- Cutover and rollback runbooks
- Ordered steps per wave, including DNS, secrets, checks and the exact trigger for rolling back.
How the work runs
- 1
Discovery and mapping
1 to 3 weeks
Inventory resources and dependencies, map services across providers and flag anything without a clean equivalent.
- 2
Foundation
2 to 3 weeks
Build the target environment, connect the two clouds with VPN or interconnect, and set up identity federation.
- 3
Migration waves
3 to 10 weeks
Move workloads in agreed groups, starting with low-risk services and ending with the main databases.
- 4
Clean-up
1 to 2 weeks
Remove the source resources, close the link between clouds and confirm billing on the old provider has stopped.
Timings depend on the size of your estate. The assessment fixes them before any build starts.
What you can check afterwards
- All production traffic is served from the target cloud
- The source account has no running workloads and its bill has stopped growing
- The target environment is fully described in Terraform in your repository
- Each wave has a written record of what moved, when and how it was verified
Tools we work with
- AWS
- Microsoft Azure
- Google Cloud
- Terraform
- AWS DMS
- Azure Database Migration Service
- Google Database Migration Service
- rclone
- Kubernetes
- Cloudflare DNS
Questions buyers ask
- How much downtime should we expect?
- Stateless services usually move with none, using DNS or load balancer switching. Databases need a short write freeze at cutover, and we agree the window with you in advance.
- Do we need to change application code?
- Sometimes. Code that calls provider SDKs directly, such as queues or storage, needs changes. The mapping lists each one so your developers can plan the work.
- What access do you need?
- Read access to the source cloud, admin access to the target cloud, and access to your repositories and CI. Everything is done in your accounts.
- Can we run both clouds for a while?
- Yes, and for larger estates we recommend it. The two clouds are linked during the waves so services can talk across them until the move is finished.
Talk to us about cloud-to-cloud migration.
Tell us what you run and where. We reply within one business day with questions or a quote.