Cloud Migration Checklist Template

The first task names the workload owner, the migration lead and the go/no-go approver, and records the target platform.

• Open the workload record and name the owner, migration lead and approver — the business owner, not IT, accepts the result in Phase 6
• List every server, database, file share and scheduled job in the workload — from discovery tooling, the CMDB and the people who run it; each source misses something
• Map inbound and outbound dependencies from real traffic — Azure Migrate’s agentless dependency analysis records TCP connections; collect long enough to catch month-end jobs
• Record hard-coded IP addresses, hostnames and certificates — connection strings, licence servers and partner allowlists break when an address changes
• Capture performance baselines at peak — CPU, memory, disk IOPS and response times, so “it is slower” can be tested
• Note data volume, rate of change and compliance constraints — residency, encryption and retention rules decide the region and the migration method

The Migration strategy dropdown on the first task shows the matching Phase 5 tasks. Retain or Retire shows the last task instead, which records the reason and a date.

• Choose the strategy for this workload — Rehost, Relocate, Replatform, Refactor, Repurchase, Retain or Retire, the seven Rs in AWS guidance
• Check that licences can move to the target — Windows Server and SQL Server licences with Software Assurance can be used in Azure under Azure Hybrid Benefit; many vendor licences are tied to hardware
• Confirm the vendor supports the application on the target — an unsupported operating system or database version rules out a straight rehost
• Agree the downtime the workload can tolerate — it decides the method: replication with a short cutover, or backup and restore over a longer window
• Record the reasons and the options rejected — later waves will ask
• Record the revisit date, or hand the workload to decommissioning — a Retain with no date becomes permanent by default

• Confirm the landing zone is ready for this workload — account or subscription, address ranges that do not overlap on-premises, identity, logging and policy guardrails
• Build connectivity before any data moves — VPN or private circuit, DNS resolution in both directions and firewall rules for replication traffic
• Record what the workload costs to run today — hardware, licences, power, support contracts and staff time; the baseline the cloud bill will be judged against
• Estimate the run cost in the target, data transfer included — internet egress, cross-zone traffic and NAT gateways; AWS includes only 100 GB a month of free data transfer out across all services
• Set budgets, cost alerts and tags before the first resource is built — workload, owner and cost centre on every resource
• Confirm backup, monitoring and security tooling cover the target — part of the build, not a hypercare discovery

The approver named on the first task records Approved or Not approved on the last task. The checklist halts there, and nothing is cut over until they decide.

• Place the workload in a wave with everything it depends on — a table row per workload: wave, strategy, owner, cutover date and rollback owner
• Agree the cutover window and the change freeze on the source — and confirm the business has accepted the downtime
• Write the cutover runbook with timings — each step, its owner, its duration and the check that proves it worked
• Set the rollback trigger and its time-box — for example, roll back if acceptance tests have not passed two hours into a four-hour window
• Rehearse with a test launch — AWS Application Migration Service and Azure Migrate both run test migrations without stopping replication
• Lower the TTL on DNS records that will change — at least one old TTL before the window, so the switch takes minutes rather than a day
• Approve or reject the cutover — the approver records the decision and the reason, with the test results attached

The second, third and fourth tasks appear only for the strategy chosen in Phase 2.

• Freeze changes on the source and announce the window — to users, the service desk and integration owners
• Rehost or Relocate: confirm replication is current and launch the cutover instances — check the final sync time before stopping the source
• Replatform or Refactor: drain database replication and switch the application — with AWS DMS full load and change data capture, stop writes, let the last changes apply, then point the application at the target
• Repurchase: export, transform and load the data into the new product — reconcile record counts and spot-check records the owner chooses
• Switch DNS, load balancers, integrations and partner allowlists to the target — using the hard-coded addresses found in Phase 1
• Run smoke tests and the owner’s acceptance tests — compare against the Phase 1 baselines; at the time-box, decide
• Roll back if the trigger is met — point traffic back to the source, which stays intact and powered off rather than deleted

The acceptance result is a dropdown. Accepted shows the decommissioning tasks in Phase 7.

• Hold an agreed hypercare period with named support — two to four weeks is common, including a month-end
• Compare performance and error rates with the baseline — latency to on-premises systems that stayed behind is the usual surprise
• Confirm backups run in the target and a restore has been tested — an untested restore is not protection
• Review the first full bill against the estimate — data transfer is the line most often missing
• Right-size before committing to reserved capacity — buy savings plans or reservations only once usage has settled
• Record the owner’s acceptance — Accepted, or Not accepted with the open issues listed

The decommissioning tasks appear only once the owner has accepted the workload in Phase 6.

• Finalise the cutover in the migration tool — in AWS Application Migration Service this stops replication and discards the replicated data, so it comes after acceptance
• Hand each source server to the Server Decommissioning Checklist — DNS records, firewall rules, service accounts, backup jobs and monitoring all go
• Cancel or reassign source licences, support contracts and hosting — the business case saving only arrives when these stop
• Update the CMDB, network diagrams and support runbooks — so the service desk knows where the workload lives
• Record what the next wave should do differently — timings and the dependencies discovery missed
• Close the change record — with the acceptance and cost review attached