On-prem to cloud migration: a practical checklist

What should you inventory before the move?

You cannot migrate what you don't know you run. Catalog workloads, dependencies, data, and the people who actually operate each system — not just what the architecture diagram claims.

Classify every workload

• Lift-and-shift candidates: stable systems that move as-is with little change.
• Re-architect candidates: where the cloud model pays for redesign.
• Retire candidates: systems nobody depends on anymore.

Sort out network, security, and identity first

Connectivity, DNS, firewall posture, and access control need to exist on the cloud side before the first workload lands. Doing this late is how migrations stall.

Move in waves, with a rollback plan per wave

• Start with low-risk, low-dependency workloads to prove the path.
• Define a cutover window and a documented rollback for each wave.
• Verify data, logs, and monitoring before you call a wave done.

After the move

• Rightsize: cloud makes it easy to over-provision on day one.
• Document the new topology and hand it to the team that runs it.
• Decommission the old environment — or it keeps costing you.

Bottom line: a migration is a series of small, reversible moves planned up front — not one big flip.