"Move it to the cloud" is easy to say and easy to get wrong. Most failed migrations we're asked to rescue share the same root cause: skipped preparation. Here is the checklist we use with our own clients — pragmatic, tool-agnostic, and sized for teams without a dedicated platform department.
Phase 1 — Assess (1–2 weeks)
- Inventory everything. Applications, databases, cron jobs, integrations, certificates, DNS records. The forgotten nightly job is the classic go-live incident.
- Classify each workload: rehost (lift-and-shift), replatform (small changes, e.g. managed database), or rebuild. Not everything deserves a rebuild.
- Find the hard dependencies. Static IP allowlists, on-prem file shares, legacy protocols — these decide your architecture more than any diagram.
- Estimate the real monthly cost with a calculator, then add 30% for the first quarter. Surprises are normal; budget for them.
Phase 2 — Plan (1–2 weeks)
- Pick the order of migration: start with the lowest-risk, stateless service to prove the pipeline.
- Define a rollback plan for every step. If you can't roll back, you're not ready to migrate.
- Decide on networking and identity first (VPC layout, SSO, secrets management) — retrofitting them later is painful.
- Set a freeze window for the final data sync and communicate it early.
Phase 3 — Execute
- Automate the environment with infrastructure as code from day one, even if it feels slower. Snowflake servers you clicked together cannot be rebuilt in a crisis.
- Migrate data before traffic: replicate, verify checksums, then switch reads, then writes.
- Run the old and new systems in parallel and compare outputs where possible.
- Cut over behind a DNS change with a low TTL so you can retreat in minutes.
Phase 4 — The week after go-live
- Watch cost dashboards daily — a misconfigured autoscaler shows up in the bill before it shows up anywhere else.
- Review alerts that fired vs. incidents that happened; tune both.
- Decommission the old environment on a scheduled date, not "eventually". Paying for two stacks is the most common silent budget leak.
- Hold a short retrospective: what would you do differently for the next workload?
Final advice
A migration is a project, not an event. Plan it in small reversible steps, keep the business informed, and don't be afraid to leave some legacy systems where they are — a stable server that costs little and changes never is sometimes the right answer.
Planning a migration and want a second opinion on your checklist? Talk to our cloud team.