Cloud Migration Checklist: 12 Steps Before You Move a Single Workload

Most cloud migrations that go wrong do not fail during the move itself. They fail weeks earlier, when nobody wrote down which server talks to which database, or agreed on what “done” means. Our team has watched a company reverse an entire migration because one forgotten batch job could not reach its old file share. This checklist covers the twelve steps we work through before any workload moves, grouped into three phases: inventory, planning, and cutover.

What belongs in your pre-migration inventory?

Phase one is unglamorous, and skipping it is the most common mistake we see. Four steps:

• 1. Build a complete asset inventory. Every server, VM, database, scheduled job, license, and certificate tied to the workload. Include the systems “nobody uses anymore” — in practice, those are the ones that break.
• 2. Map dependencies. Which systems call this workload, and which systems does it call? Network flow logs and monitoring data tell the truth; tribal knowledge does not. A dependency you discover on cutover night is an outage.
• 3. Classify the data. Personal data, payment data, and anything under a regulatory regime must be flagged now, because classification constrains region choice, encryption, and access controls later. CISA’s Cloud Security Technical Reference Architecture treats this as a precondition for migration, not a follow-up task.
• 4. Baseline current performance and cost. Record response times, throughput, and today’s monthly run cost. Without a baseline you cannot prove the migration helped, and you will not notice if it quietly made things worse.

How do you pick the right path for each workload?

Phase two turns that inventory into decisions. Steps five through eight:

• 5. Choose a migration pattern per workload. Rehost, replatform, or refactor — one size does not fit a whole portfolio. The table below summarizes when each makes sense.
• 6. Pick the service model deliberately. IaaS, PaaS, and SaaS shift different duties to the provider. NIST Special Publication 800-145 defines the three models precisely, and their cost profiles differ more than list prices suggest — we walk through the numbers in our IaaS vs PaaS vs SaaS cost comparison.
• 7. Model the target cost, including egress. Compute is easy to price; data leaving the cloud is where estimates slip. The FinOps Foundation’s framework puts cost estimation in the “inform” phase for a reason: do it before you commit, not after the first invoice.
• 8. Map security and compliance controls to the target. Decide who patches the operating system, who manages identity, and who holds the encryption keys after the move. If the answer is unclear, read the provider’s shared responsibility documentation before you sign anything.

Pattern	Effort	Best for
Rehost (lift and shift)	Low	Stable apps, hard deadlines, data center exits
Replatform	Medium	Apps that gain from managed databases or storage with minor changes
Refactor	High	Core products where scaling or release speed justifies a rebuild

What does a safe cutover actually look like?

Phase three is where preparation pays off. Steps nine through twelve:

• 9. Run a pilot. Move one low-risk workload end to end first. The pilot exists to surface surprises in networking, identity, and backup while the stakes are small.
• 10. Write the rollback plan before the migration, not during it. Define the exact trigger (“error rate above X for 15 minutes”), the person authorized to call it, and the steps to return traffic to the source environment.
• 11. Build a cutover runbook. A timestamped sequence with a named owner for every task, including DNS changes, data sync checkpoints, and the go/no-go call. Rehearse it once.
• 12. Validate, then decommission. Compare against the phase-one baseline, confirm backups restore in the new environment, and keep the source system frozen but intact for an agreed period before you shut it down.

Worked example: how long will the data actually take to move?

Transfer time is the step teams most often guess at instead of calculating. Suppose you need to move 5 TB (5,000 GB) over a 100 Mbps connection. That is 40,000 gigabits, which at 100 Mbps takes 400,000 seconds — about 111 hours, or 4.6 days of sustained transfer. On a 1 Gbps link the same data takes roughly 11 hours. Real throughput is usually lower than line speed, so treat these as best-case floors. This one calculation decides whether you can sync over a weekend, need weeks of incremental replication, or should order a physical transfer appliance.

While you plan the window, also check what the provider promises when things go down mid-cutover. We cover the fine print in how to read a cloud SLA.

FAQ

How long should a cloud migration take?

It depends on portfolio size, but the inventory and planning phases usually take longer than the move itself. A single well-understood workload can migrate in weeks; discovering that you do not understand it can add months. Budget time for phases one and two accordingly.

Should we migrate everything at once?

No. Move in waves, starting with low-risk workloads, and apply what each wave teaches you to the next. A “big bang” migration turns every unknown dependency into a simultaneous incident, with no clean way to roll back one piece.

What is the most common migration mistake?

Undiscovered dependencies, followed closely by having no tested rollback plan. Both are cheap to fix in phase one and expensive to fix at 2 a.m. on cutover night. If you only adopt two steps from this list, take steps 2 and 10.

Still choosing where to land? You can compare cloud providers and migration partners side by side in our directory.