Cloud migration checklist: how to plan a move without downtime

Most migrations that go badly do not fail on the technology. They fail on something nobody wrote down: a reporting job that runs once a month, a hard-coded IP address in a supplier’s firewall, a licence tied to physical hardware. A good plan is mostly about finding those things before cutover night.

This is the checklist we follow, whether the destination is AWS, Azure or Google Cloud.

Phase 1: Discover what you actually have

• Inventory every server, database and application, including the ones only one person knows about. Discovery tools from your cloud provider can collect this automatically, but interview the people who run each system too.
• Map dependencies. Which applications talk to which databases, file shares, APIs and external partners? Look at network connections over at least a full month so monthly jobs show up.
• Record performance. Real CPU, memory, storage and network use, not the size of the original hardware. Most on-premises servers are sized for peaks that rarely happen.
• Check licences. Some software is licensed per physical core or per host and costs more, or is not allowed, in the cloud. Microsoft, Oracle and many specialist vendors have specific cloud rules.
• List compliance needs. Data residency, HIPAA, GDPR and customer contracts may decide which regions and services you can use.

Phase 2: Decide what happens to each workload

Cloud providers describe the options as the “7 Rs”. Every workload gets one:

Do not refactor everything. Rehosting first and improving later is often faster and lower risk, as long as you plan the follow-up work.

Phase 3: Build the foundations

• Account or subscription structure, separating production from non-production
• Identity: single sign-on, MFA and least-privilege roles
• Networking: address ranges that do not overlap with your offices, VPN or private connectivity back to anything that stays on-premises
• Logging, monitoring and backups switched on before the first workload arrives
• Budgets and cost alerts
• Everything defined as code (Terraform, CloudFormation or Bicep) so it can be reviewed and rebuilt

Phase 4: Migrate in waves

Group workloads that depend on each other into waves, and start with something low risk: an internal tool or a test environment. The first wave teaches you how long things really take.

For every wave, write a runbook with:

1. Pre-checks: backups verified, owners available, users notified
2. Data synchronisation: replicate databases and files ahead of time so cutover only moves the final changes
3. The cutover steps, with a named person for each
4. Test cases that prove the application works, agreed with the people who use it
5. Rollback criteria and steps: what failure looks like, and how you return to the old system

Phase 5: Cut over and support

• Choose a low-traffic window and freeze changes to the systems involved.
• Run the agreed tests before declaring success, not after the first complaint.
• Keep the old environment available, read-only, for an agreed period.
• Plan a hypercare period of one to two weeks with engineers on call.

Phase 6: Optimise after the move

A month after each wave, review real usage. Rightsize instances, buy Savings Plans or reservations for steady workloads, and schedule the next round of improvements, such as moving self-managed databases to managed services. This is where most of the long-term savings come from.

How long does it take?

A handful of servers or a Microsoft 365 move usually takes two to six weeks. Larger estates are typically moved in waves over several months. The discovery phase is what makes the estimate reliable, so it is worth doing properly before committing to dates.