Cloud migration checklist

What a cloud migration checklist should accomplish

A cloud migration checklist should do more than track servers moving between environments. It should establish whether each workload is worth migrating, define the security and operational conditions for launch, and prove that the destination meets business requirements. For decision-makers, it creates accountable approval gates. For practitioners, it turns architecture choices into testable implementation tasks.

Use this checklist for migrations from on-premises infrastructure, colocation facilities, or another cloud. Apply it per workload, then coordinate shared dependencies across migration waves. A database, identity provider, or network hub can affect multiple applications even when each application has its own migration plan.

The central rule: approve migrations using evidence, not task completion alone. “Backup configured” is a task. “Restore completed within the agreed recovery objective” is evidence.

1. Define business outcomes and migration boundaries

Before selecting services, document what the migration must improve and which constraints cannot change.

• Assign an executive sponsor and workload owner. Separate budget authority from technical execution, and name the person who can authorize cutover or rollback.
• Define measurable outcomes. Examples include removing a data-center dependency, supporting regional expansion, reducing deployment lead time, or meeting a recovery requirement.
• Set service objectives. Record availability targets, acceptable application latency, recovery time objective (RTO), and recovery point objective (RPO).
• Identify hard constraints. Include data residency, contractual obligations, licensing restrictions, support requirements, and change-freeze windows.
• Define scope explicitly. List applications, databases, file shares, interfaces, scheduled jobs, user groups, and environments included or excluded.
• Record the baseline. Capture current operating costs, utilization, incident patterns, backup performance, and peak-period throughput.

Avoid promising savings before measuring the existing environment. Cloud spending may increase initially because source and destination systems run together, data transfer incurs charges, and teams need new operational tooling.

Exit criterion: every in-scope workload has an owner, a business reason to move, and approved success measures.

2. Discover workloads and map dependencies

An asset inventory is necessary but insufficient. Migration failures frequently originate in dependencies that were not visible in a server list.

Use tools such as Azure Migrate, AWS Application Discovery Service, or existing monitoring and configuration-management systems. Combine discovery output with interviews and observed traffic; automated scans may miss monthly jobs, manual file transfers, or external allowlists.

Workload discovery checklist

• Inventory compute, operating systems, databases, storage volumes, runtimes, and unsupported software.
• Map inbound and outbound connections, including ports, protocols, authentication methods, and DNS dependencies.
• Identify Active Directory, LDAP, certificate authorities, secrets stores, and time-synchronization dependencies.
• Record data size, growth, change rate, retention, and deletion requirements.
• Measure resource demand during representative busy periods, not just average utilization.
• Inspect hard-coded addresses, local filesystem assumptions, hardware-bound licenses, and shared credentials.
• Identify third-party integrations that require new IP allowlists or contractual approval.
• Classify data and identify regulated or sensitive fields.

Pay particular attention to applications that make frequent database calls. Splitting a tightly coupled application and database across a WAN can make an otherwise functional migration unusably slow.

Exit criterion: the dependency map has been reviewed by application, network, database, and security owners.

3. Choose a migration strategy for each workload

Do not assume every application should become cloud-native immediately. Use migration strategy labels as planning aids rather than rigid categories.

A practical program often combines these approaches. Rehosting can meet a facility-exit deadline while replatforming selected databases reduces maintenance. Refactoring every application at once expands both scope and uncertainty.

Use provider frameworks to structure assessments, such as the AWS Cloud Adoption Framework, while keeping business objectives independent of any provider’s product catalog.

Exit criterion: each strategy has an estimated effort, risk assessment, target architecture, and accountable owner.

4. Evaluate providers and build the cost model

Compare AWS, Microsoft Azure, Google Cloud, or specialist providers against workload requirements—not just headline compute prices.

Vendor-evaluation checklist

• Regional fit: required services and instance types are available in approved regions.
• Availability design: failure domains, service dependencies, and regional recovery options meet your objectives.
• Compatibility: database extensions, operating systems, architectures, and licensing models are supported.
• Connectivity: VPN or private-connectivity options meet measured latency and throughput requirements.
• Security: identity federation, key management, audit logging, and policy enforcement satisfy controls.
• Operational support: support tiers, escalation paths, and required staff skills are acceptable.
• Portability: data can be exported in usable formats, with known time and transfer costs.
• Capacity: quotas are sufficient, and critical capacity requirements have a documented provisioning approach.

Model steady-state costs and migration costs separately. Include compute, storage tiers, requests, provisioned database capacity, snapshots, backups, observability ingestion, public IPs, load balancing, NAT processing, inter-zone traffic, and internet egress.

Use the AWS Pricing Calculator, Azure Pricing Calculator, or Google Cloud Pricing Calculator with measured utilization. Validate assumptions against official pricing, such as Google Cloud network pricing, because architecture directly affects transfer charges.

Trade-off: managed services can reduce patching and administration while increasing service charges and platform dependence. Evaluate total operating effort, not infrastructure price alone.

Delay long-term commitments until workloads are stable enough to size confidently. Also confirm how existing software licenses transfer before counting licensing savings.

5. Build a secure landing zone before moving workloads

A landing zone is the governed foundation for cloud workloads: accounts or subscriptions, identity, networking, logging, and policies.

AWS Control Tower, Azure landing zones, and Google Cloud enterprise foundation approaches can accelerate implementation. They still require decisions about organizational ownership and acceptable exceptions.

Foundation and security checklist

• Separate production, nonproduction, security, and shared services where appropriate.
• Federate workforce identities; require MFA and use short-lived workload credentials.
• Establish least-privilege roles and a tested emergency-access procedure.
• Design IP ranges to avoid overlap with existing networks and future connectivity.
• Define ingress, egress, private endpoint, DNS, and network-segmentation patterns.
• Encrypt data in transit and at rest; document key ownership and recovery procedures.
• Centralize audit logs and protect them from modification by workload administrators.
• Apply tagging standards for owner, environment, cost center, and data classification.
• Use infrastructure as code through Terraform, OpenTofu, Bicep, or CloudFormation.
• Scan infrastructure definitions and images using tools such as Checkov and Trivy.
• Set budgets and anomaly alerts, recognizing that alerts do not automatically cap spending.
• Verify that backup retention and deletion controls match recovery and compliance needs.

Map controls to relevant standards and implementation guidance, such as the NIST Cybersecurity Framework. A provider’s certification does not automatically make your application compliant.

Exit criterion: a representative deployment passes identity, network, logging, backup, and policy tests.

6. Plan data migration and synchronization

Data movement often determines the migration schedule. Select an approach based on dataset size, change rate, permitted downtime, and application consistency requirements.

For a small dataset with an approved outage window, a verified backup-and-restore process may be simplest. For continuously changing databases, initial loading followed by change data capture may reduce downtime. Tools include AWS Database Migration Service, Azure Database Migration Service, and Google Cloud Database Migration Service, subject to source-and-target support.

• Test schemas, extensions, collations, encodings, time zones, and transaction behavior.
• Verify migration coverage for stored procedures, triggers, users, permissions, and scheduled jobs.
• Measure transfer throughput using representative data and the actual network path.
• Encrypt transfers and restrict temporary migration credentials.
• Monitor replication lag and source-system impact.
• Define reconciliation using counts, checksums where practical, and business-level totals.
• Establish how writes stop, drain, or redirect at cutover.
• Document the authoritative system before, during, and after migration.
• Test data restoration independently of replication.

Replication is not a backup: accidental deletion or corruption can propagate to the destination.

Rollback deserves special attention. Once the target accepts new writes, returning to the source may require reverse replication or reconciliation. “Switch DNS back” is not a sufficient database rollback plan.

7. Sequence migration waves and rehearse

Start with a workload that has limited business impact but representative operational needs. An isolated demo application may validate provisioning while revealing little about production dependencies.

Group tightly coupled services into the same wave unless hybrid operation has been tested. Schedule shared identity, connectivity, and observability capabilities before dependent applications.

Rehearsal checklist

• Deploy through the same pipeline and infrastructure definitions planned for production.
• Test functional behavior, authentication, authorization, and external integrations.
• Run load tests against agreed throughput and tail-latency objectives.
• Exercise autoscaling, dependency failures, and recovery procedures.
• Restore backups and measure recovery time and data loss.
• Validate dashboards, alerts, on-call routing, and runbooks.
• Rehearse the cutover and rollback steps with named operators.
• Record actual durations and update the production schedule.

Tools such as k6, JMeter, OpenTelemetry, and Prometheus can support performance testing and telemetry. Ensure test traffic and datasets are representative without unnecessarily exposing production information.

Exit criterion: unresolved defects have owners and explicit risk acceptance; no critical requirement depends on an untested assumption.

8. Execute cutover through a go/no-go gate

The cutover runbook should be a timestamped sequence with owners, verification steps, and decision points. Avoid making operators infer the next action during an outage.

Production cutover sequence

• Confirm readiness: staffing, communications, change approval, provider service health, quotas, and required capacity.
• Verify recovery: recent backups, tested restore procedures, and usable source infrastructure.
• Control changes: freeze conflicting deployments and configuration updates.
• Synchronize data: apply the planned write controls and confirm acceptable replication lag.
• Redirect traffic: update routing, load balancers, service discovery, or DNS as designed.
• Validate service: run synthetic transactions, authentication checks, and business-critical workflows.
• Observe: compare error rates, latency, saturation, and data reconciliation with approved limits.
• Decide: continue, pause, or roll back using predefined triggers.

Lowering DNS TTL in advance may help, but cached records and persistent connections can delay traffic movement. Test the actual routing mechanism.

Set rollback triggers around user impact and data integrity—not vague discomfort. For example, define how long critical transactions may fail before the cutover owner must act.

9. Stabilize, optimize, and decommission

A successful traffic switch is not the end of migration.

• Review production behavior across a representative business cycle, including batch processing.
• Compare actual spending with the model and investigate unexpected network or logging charges.
• Right-size resources using observed demand and reliability requirements.
• Confirm patching, vulnerability management, backup monitoring, and certificate renewal ownership.
• Update architecture diagrams, asset inventories, service catalogs, and incident procedures.
• Remove temporary migration accounts, access rules, secrets, and transfer infrastructure.
• Obtain application-owner approval before shutting down source systems.
• Preserve required records, then securely erase or dispose of retired assets.
• Cancel obsolete contracts and release unused network, storage, and licensing resources.

Track decommissioning separately. Otherwise, organizations can pay indefinitely for both environments while treating migration as complete.

Common cloud migration mistakes

• Sizing from allocated capacity: provisioned resources may greatly exceed actual demand. Start with measurements, then preserve justified headroom.
• Moving servers without dependencies: include schedulers, identity, certificates, file exchanges, and operational tooling.
• Treating connectivity as an afterthought: validate latency and transfer capacity before committing to hybrid designs.
• Relying on provider defaults: review exposure, retention, permissions, and resilience settings explicitly.
• Combining relocation with an uncontrolled rewrite: separate required compatibility work from optional redesign.
• Leaving rollback undefined: establish when rollback remains feasible and how target-side writes will be handled.

For related implementation and security planning resources, browse more Checklists topics.

Frequently asked questions

What should a cloud migration checklist include?

Include business goals, workload inventory, dependency mapping, migration strategies, vendor evaluation, cost modeling, landing-zone controls, data migration, rehearsals, cutover, rollback, and decommissioning. Give each item an owner and evidence-based acceptance criteria.

How long does a cloud migration take?

There is no reliable universal timeline. Duration depends on dependencies, data transfer, application changes, compliance reviews, and team capacity. Estimate after discovery, then revise using measured transfer rates and rehearsal results. Distinguish the overall program from each workload’s outage window.

Should applications be rehosted or refactored first?

Rehost when speed and compatibility dominate; refactor when architectural limits prevent required outcomes. Replatforming can offer a middle path. Make the choice per workload, and fund any postponed modernization explicitly rather than assuming it will happen later.

How do you know a migration is complete?

Migration is complete when the workload meets approved functional, security, performance, recovery, and cost criteria; operations teams own it; and source resources are retired or formally retained. Successful deployment alone does not demonstrate sustainable production readiness.