The Cloud Migration Checklist: What to Sort Out Before, During and After the Move

Most cloud migrations don’t go wrong on moving day. They go wrong in the planning nobody did beforehand, and in the cleanup nobody does afterward. The servers come across fine. The old firewall rules, the shared admin password and the forgotten test database come across too.

Here’s a checklist that covers the parts that tend to get skipped. It’s written for small and mid-sized teams moving to AWS, Azure or Google Cloud, and it leans on each provider’s own migration guidance where that’s useful.

Before the move

Know what you have

You can’t plan a migration around systems you don’t know about. Build an inventory before anything else:

• Every server, VM and appliance, with an owner for each one
• What each system talks to: databases, file shares, APIs, outside vendors
• Where sensitive data lives, and any rules that apply to it (HIPAA, PCI DSS, GDPR, contracts)
• Scheduled jobs and scripts that run on a box somewhere and nobody remembers writing

The dependency mapping is the part people rush. If you move an app and leave its database behind, you’ve built a slow, expensive network link between two data centers.

Pick a strategy per workload

AWS’s prescriptive guidance groups migration options into the “7 Rs,” which grew out of an earlier Gartner model. Every workload should get one:

• Retire: turn it off. You’ll find more of these than you expect.
• Retain: leave it where it is for now.
• Rehost: lift and shift onto cloud VMs as they are.
• Relocate: move a whole virtualized environment, such as VMware, without changing it.
• Repurchase: swap it for a SaaS product.
• Replatform: small changes on the way, like moving a self-managed database to a managed one.
• Refactor: rebuild it to use cloud-native services.

Rehosting is the quickest, but it brings every existing problem along with it. That’s fine as long as you’re honest that it’s step one, and you plan the follow-up.

Set up the landing zone before any workloads

The account structure, identity and guardrails should exist before the first server arrives. Retrofitting them later is much harder.

• Separate accounts or subscriptions for production and everything else
• Single sign-on for people, with MFA required
• The root or global admin account locked away, with MFA, and not used for daily work
• Organization-wide activity logging switched on (CloudTrail, Azure Activity Log or Cloud Audit Logs) and sent somewhere admins can’t quietly delete
• Budget alerts, so a misconfigured service shows up as an email and not a surprise invoice

AWS Control Tower, Azure landing zones and Google Cloud’s setup checklist all give you a starting template for this. The CIS Foundations Benchmarks for each provider are a good second pass once it’s running.

Decide who secures what

Every provider publishes a shared responsibility model. The short version: they secure the hardware and the managed service, and you secure your configuration, your identities and your data. A VM in the cloud still needs patching. A storage bucket is still yours to keep private. Write down who on your team owns each of those before go-live.

During the move

• Lower DNS TTLs a few days before cutover so changes take effect quickly
• Move data over encrypted connections, and encrypt it at rest on arrival
• Run the old and new systems side by side long enough to compare results
• Have a written rollback plan with a clear trigger: what goes wrong, who decides, and how you switch back
• Freeze unrelated changes during the cutover window

Test the rollback before you need it. Until you’ve run it once, you don’t know whether it works.

After the move

This is where most migrations quietly stop, and where the risk builds up.

• Review security groups and firewall rules. Lift-and-shift often copies “allow from anywhere” rules that made sense on a private network.
• Check that no storage buckets, snapshots or databases are publicly reachable by accident
• Remove migration-only access: temporary admin accounts, VPN tunnels, replication users
• Turn on your provider’s security posture tool (AWS Security Hub, Microsoft Defender for Cloud or Security Command Center) and work through the findings
• Set up backups in the new environment and run a test restore
• Decommission the old hardware and wipe it properly, so the data you moved doesn’t also live on in a closet

Then schedule the next step for anything you rehosted. Lift and shift is a reasonable way to get out of a data center. It isn’t a reason to keep running the cloud like one.

The short version

Inventory everything, give each workload a strategy, build identity and logging before you move anything in, keep a rollback you’ve actually tested, and finish the cleanup. If you have to prioritize, start with the landing zone. It’s the part that’s cheapest to get right at the start and most painful to fix later.