Runbook
The Cloud Migration Checklist
Five phases, thirty checkpoints, zero surprise outages. This is the sequence we run before touching a single production workload — use it to plan your own migration or to pressure-test a vendor's.
Most cloud migrations don't fail during the move. They fail two weeks earlier, in the assumptions nobody wrote down — an undocumented cron job, a hardcoded IP, a compliance control nobody re-tested post-cutover. This checklist exists to surface those assumptions before they surface themselves in production.
It's organized the way we sequence real engagements: assess what you actually have, plan the target state, execute the migration, validate before you cut over traffic, then optimize once the dust settles. Skipping a phase doesn't save time — it just moves the cost to incident response.
Assess
Know what you're actually moving before you plan how to move it.
Inventory every workload and its dependencies
Services, cron jobs, batch processes, background workers, anything triggered manually.
Map data flows and storage
Databases, object storage, caches, queues, residency requirements.
Catalog hardcoded infrastructure references
Literal IPs, internal hostnames, on-prem-only DNS baked into config or code.
Identify compliance and data-residency constraints
SOC 2, HIPAA, PCI, regional data laws.
Baseline current performance and cost
Latency, throughput, spend, before anything changes.
Flag single points of failure
Call out anything with no redundancy today explicitly.
Plan
Decide the target architecture and the strategy for getting there.
Choose a migration strategy per workload
Rehost, replatform, or refactor.
Select provider and region based on constraints, not defaults
Design the target network topology
VPC layout, subnetting, peering/transit gateway.
Define infrastructure as code from day one
Terraform, Pulumi, or equivalent.
Write the cutover and rollback plan together
Sequence workloads by risk and dependency
Low-risk first.
Set a rollback trigger threshold in advance
Decide the error-rate/latency threshold before cutover, not during an incident.
Migrate
Execute in reversible, observable steps.
Stand up target infrastructure via code, not console clicks
Migrate data with a verified, resumable process
Checksum source vs. destination.
Stand up CI/CD pipelines targeting the new environment
Before real traffic arrives.
Shift traffic incrementally
1%, then 10%, then the rest.
Keep the old environment warm until validation passes
Migrate secrets and credentials through a vault, not a spreadsheet
Rotate anything exposed during the move.
Validate
Prove the new environment holds under real conditions before you call it done.
Run functional tests against the new environment
Full regression, not just smoke tests.
Load test at realistic and peak traffic levels
Compare against the Assess baseline.
Verify monitoring, logging, and alerting are live
In the new environment.
Re-run compliance and security checks
New environment, new attack surface.
Confirm backup and disaster recovery actually work
Restore from a backup before you need to.
Get sign-off from every downstream team
Optimize
The migration isn't finished when traffic cuts over — it's finished when the new environment is cheaper and better-understood than the old one.
Decommission the old environment
Only after full sign-off and a complete traffic cycle.
Right-size compute and storage against real usage
Review the bill line by line
Reserved instances, storage tiering, orphaned migration resources.
Document the new environment for the team
Runbooks, diagrams, on-call procedures.
Schedule a retro on the migration itself
Running this yourself, or want a second set of eyes?
This is the same checklist we work from on client engagements — adapted per workload, not applied as a template. If you're mid-assessment and want a sanity check on the plan before you touch production, that's a fifteen-minute conversation, not a sales pitch.
Request a platform walkthrough — See how Deploy, Pipelines, Guard, and Observe fit into a migration like this one.
Inquire