Who this is for
This is for teams moving a set of workloads from one public cloud to another. Not one app and not one database, usually a portfolio that grew over a few years. Virtual machines, a couple of managed databases, queues, object storage, a Kubernetes cluster, plus the IAM policies and scripts that hold it all together.
You may be moving because a contract is ending, because two companies merged, because of a data residency rule, or because the platform team wants one cloud instead of three. The checklist assumes the decision is made and the work now is sequencing.
If you are moving a single system, the narrower guides on this site fit better. This one is about the coordination problem: shared services, order of operations, and what breaks while two clouds run side by side.
Before you begin
Pick the unit of migration and write it down. Moving account by account, product by product or environment by environment all work, but only if inventory, testing and cutover use the same unit.
Read the exit terms of the current contract. Notice periods, minimum commitments, reserved capacity and early termination charges set your deadline and your budget for running two clouds at once. Find out who signs off before the day you need them.
Stand up the target side first: accounts, billing, landing zone, network ranges that do not overlap the source, and a working login for every engineer on the job. People who cannot get in cannot migrate anything.
Build the inventory from the provider's own export tools and the last three bills, not from memory. Tag every resource with an owner and have each owner confirm it. Bills surface the resources nobody remembers creating.
The checklist
The items below make up the Checklist: move workloads from one cloud to another. Run them in order on the first pass, then use them as a review gate before any cutover. Give each item an owner and a date.
Data movement is usually the slow part, not the compute. Do a bulk copy, then a delta sync, then a final sync inside a short freeze window. Test a restore on the target, not only a copy. A backup nobody has restored is a guess.
Account and contract cleanup runs longer than engineers expect. Give notice on time, cancel unused reservations, and keep a list of every API key, webhook and integration that touches the old cloud. Some will outlive the migration by months, and someone has to find them.
- Inventory every resource with an owner, an environment, a runtime and a data classification, cross checked against the last three bills.
- Map dependencies in both directions, including DNS names, IP allowlists, message queues, shared storage and anything holding a hardcoded endpoint.
- Mark each workload as rehost, replatform, rebuild or retire before anyone books a migration slot.
- Identify shared services such as identity, logging, secrets, CI runners and artifact registries, then decide whether each one moves, gets replaced or gets bridged.
- Add an egress estimate for all data leaving the current cloud, including backups, logs and analytics extracts, not only the one time copy.
- Redesign the network on the target: address ranges, subnets, firewalls, private endpoints and a VPN or interconnect to anything still on premises.
- Port infrastructure as code and pipelines, then run a full deploy from scratch into a throwaway target account to prove the templates work.
- Recreate identity and access: roles, groups, service principals and policy documents, with least privilege checked against the source.
- Move secrets into the target's secret store, rotate everything that was copied, then delete the old copies.
- Set up observability parity on the target, with metrics, logs, traces, alerts and dashboards live before the first real workload lands.
- Define an acceptance test per workload, including a load test at expected peak and a failure test that kills an instance.
- Write a cutover runbook with exact commands, expected timing, a named decision maker and a rollback that has been rehearsed.
- Lower DNS TTLs a week ahead, then shift traffic in stages with a canary or weighted records while watching error rates.
- Keep the source in read only or standby mode until the new side has survived a full business cycle, then decommission it and revoke the credentials.
What good looks like
An empty account plus your code produces a working environment. That is the proof the move is repeatable and not a pile of hand-built pieces. Run it twice to be sure.
Every workload has an owner, an acceptance test that passes and a rollback someone has actually rehearsed. Cutovers happen with people watching, not by default at two in the morning.
Spend shows up on the new side on day one through tags, budgets and alerts. The old side has a shutdown date and a short list of what still runs there and why.
A new hire can follow the diagrams and understand the new architecture in ten minutes, because someone updated them after the last cutover.
What to do next
Run the first pass against your real inventory this week. Any resource without an owner is a risk, not a task, and it will bite during cutover.
Choose one low risk workload as a pilot. Move it end to end, including shutting down the source, and write down what surprised you. That note is worth more than another planning deck.
If you want the inventory, target architecture and phasing done in one go, Cloudverg's Discovery and roadmap sprint is a fixed-price two week engagement that ends with diagrams, a phased roadmap and a fixed quote for phase one. It is one option among others, and the checklist above stands on its own.
Frequently asked questions
How long does a cloud to cloud migration take?
It depends on how many workloads you move and how tightly they are coupled. A few well documented workloads can move in weeks. A portfolio with shared identity, private networking and a data warehouse usually takes months of staged cutovers. Set the deadline from the contract end date and your freeze windows, not from optimizm.
What costs the most when moving between clouds?
Data transfer out of the current cloud, and running both environments at the same time. Storage and compute on the target pile up while the source is still live. People time is the other big cost, since most teams migrate alongside their normal work. Model all three before you commit to a date.
Should we rehost or rebuild during the move?
Rehost first when speed matters, then improve. A lift and shift gets you out of the old contract with behavior you already understand. Rebuild where the target's managed services remove real operational work, such as queues, managed Kubernetes or serverless functions. A mixed approach is normal, as long as each workload has a stated reason.