A practical cloud migration checklist

Most cloud migrations don't fail dramatically. They fail quietly — a surprise bill, an app that's slower than before, a dependency nobody mapped. The good news is that the failure modes are predictable, which means a checklist genuinely helps. Here's the one we work from.

Before you move

Know what you have. You can't migrate what you haven't inventoried.

• List every application, who uses it, and how critical it is.
• Map dependencies — what talks to what. The integration nobody remembered is the classic migration-day surprise.
• Note data volumes and where data lives.

Decide the strategy per workload. Not everything should move the same way:

• Rehost ("lift and shift") — move as-is. Fast, but you carry old problems up with you.
• Replatform — small optimisations on the way (e.g. a managed database).
• Refactor — rework the app to be cloud-native. Most value, most effort.
• Retire / replace — some things shouldn't move at all.

Set a budget and guardrails. Cloud cost is usage-based, which is a feature and a trap. Agree budgets, turn on cost alerts, and right-size from the start rather than copying oversized on-prem servers.

Plan security in, not on. Identity and access, encryption, and network rules belong in the design — see our note on security and data handling.

During the migration

• Migrate in waves, lowest-risk first. Early wins build confidence and surface process problems cheaply.
• Test before cutover — functionality, performance, and integrations in the new environment, not just "it booted."
• Keep a rollback path for each wave. Define, in advance, what "this isn't working, revert" looks like.
• Mind the data. Large datasets take longer to copy than people expect; plan the final sync and the acceptable downtime window.
• Communicate cutover so users aren't surprised when something moves.

After you move

• Validate against the success criteria you set — not vibes.
• Right-size again. Real usage data lets you trim over-provisioned resources; this is where a lot of the savings actually appear.
• Confirm backups and recovery work in the new environment — see backup and disaster recovery.
• Monitor cost and performance, and set alerts so problems find you rather than the other way around.
• Decommission the old environment once you're confident — paying for both is a common, avoidable cost.

A migration isn't done when the workload runs in the cloud. It's done when it's right-sized, monitored, backed up, and the old environment is switched off.

The boring truth

The teams that have smooth migrations aren't the ones with the fanciest tooling — they're the ones who inventoried honestly, moved in waves, and kept a way back. The technology is rarely the hard part.

If you'd like a hand planning or running a migration, it's one of our cloud services. Get in touch and we'll map out an approach.