How to Use This Checklist
This checklist is designed for engineering and operations teams preparing to move workloads from on-premise or legacy cloud environments to a modern cloud infrastructure. It is structured in three phases: assessment, planning, and migration. Work through each section in order. Items marked as blockers should be resolved before moving to the next phase.
This checklist does not prescribe a specific cloud provider or architecture. It is intended to surface gaps and decisions early — before they become delivery risks.
Phase 1: Assessment
Workload Inventory
- All applications and services are catalogued with their current hosting environment, runtime, and dependencies
- Dependencies between services are mapped — including database connections, message queues, internal APIs, and third-party integrations
- Data volumes and growth rates are documented for each workload
- Availability and recovery requirements are recorded for each service (RTO, RPO)
- Compliance requirements affecting data residency, encryption, or access logging are identified
Current State Evaluation
- Infrastructure-as-code coverage is assessed — what is managed by code vs. managed manually
- Existing CI/CD pipelines are reviewed for compatibility with target cloud environments
- Secrets management practices are reviewed — no credentials stored in source code or unencrypted configuration files
- Logging and monitoring coverage is assessed across all services
- Current deployment frequency and lead time are documented as a baseline for comparison post-migration
Decision: Lift-and-Shift vs. Re-Architecture
- For each workload, a disposition is assigned: lift-and-shift, re-platform, re-architect, or retire
- Re-architecture candidates are scoped separately — they require more planning time and carry higher delivery risk
- Retire candidates are confirmed with business stakeholders before proceeding
Phase 2: Planning
Team and Ownership
- A named delivery lead is assigned with clear accountability for migration outcomes
- Each workload or workload group has a named technical owner
- Escalation paths are defined — who approves architecture changes, who resolves cost overruns, who owns rollback decisions
- Stakeholders who need milestone visibility are identified and communication cadence is agreed
Architecture and Infrastructure
- Target cloud region(s) are selected based on latency, compliance, and cost requirements
- Network topology is designed — VPCs, subnets, peering, ingress/egress controls
- Identity and access management model is designed — roles, service accounts, least-privilege policies
- Compute sizing is estimated for initial deployment, with a plan to right-size after observing production load
- Storage strategy is defined — object storage, block storage, managed databases, backup retention
- Infrastructure-as-code tooling is selected (e.g., Terraform, CDK, Pulumi) and a module structure is agreed
Cost and Governance
- Budget estimates are documented for the migration period and steady-state operation
- Cost alerting thresholds are configured in the target environment before any workloads are deployed
- Tagging strategy is defined — all resources will be tagged with owner, environment, and workload identifiers
- Reserved capacity or savings plans are evaluated for predictable workloads
Runbooks and Rollback
- A runbook exists for each planned migration event — including pre-migration checks, migration steps, validation steps, and rollback procedure
- Rollback procedures are tested in a non-production environment before the migration window
- A communications plan is prepared for planned downtime or degraded service windows
- Go/no-go criteria are defined for each migration event
Phase 3: Migration
Pre-Migration
- Target environment is provisioned and validated in a staging configuration before production migration begins
- Data migration tooling is tested with a representative sample before full migration
- Access controls in the target environment are verified against the least-privilege model
- Monitoring and alerting are active in the target environment before traffic is shifted
Execution
- Each workload is migrated according to its runbook
- Validation steps are completed and documented for each migrated workload
- Traffic cutover is performed incrementally where possible — route a percentage of traffic to the target environment before full cutover
- Rollback is exercised if validation fails; the rollback procedure is not skipped to meet a schedule
Post-Migration
- All production workloads are confirmed running and meeting availability requirements in the target environment
- Legacy infrastructure is documented but not deleted for a minimum agreed retention period
- Cost actuals are reviewed against estimates within the first billing cycle
- A post-migration retrospective is conducted and findings are documented
- Monitoring baselines are updated to reflect the new environment
Common Gaps That Delay Cloud Migrations
Incomplete dependency mapping. Services that appear isolated often have hidden dependencies — a shared database, a legacy authentication service, or a third-party integration that only works from a specific IP range. Discovering these during a migration window rather than during planning is the most common source of delay.
Secrets sprawl. Credentials embedded in application configuration files, deployment scripts, or environment variables outside a secrets manager create blockers during migration and security risks post-migration. Inventory and rotate all credentials before the migration begins.
Untested rollback procedures. Rollback plans that exist on paper but have never been executed under time pressure are not reliable. Run a rollback rehearsal in a staging environment before every significant migration window.
Skipped right-sizing. Over-provisioning to ensure migration success is reasonable, but leaving over-provisioned infrastructure in place for months after migration is avoidable cost. Schedule a right-sizing review for 30 and 90 days after each workload migration completes.