Cloud10 min read

Cloud Migration Checklist for Startups

A practical, phase-by-phase checklist for moving to AWS without downtime or nasty surprises.

DM

Deep Mehta

Founder & Cloud Engineer · Updated August 27, 2026

Migrations fail in predictable ways: no rollback plan, a dependency nobody mapped, a data cutover that loses writes. None of that is exotic, it comes from skipping the boring preparation. Here is the checklist we run, phase by phase.

Phase 1, Assess before you move anything

  • Inventory every application, service, and data store
  • Map dependencies, what talks to what, and over which ports
  • Note compliance and data-residency constraints
  • Record current performance baselines so you can compare after
  • Identify the riskiest workload and plan to migrate it last

Phase 2, Pick a strategy per workload (the 6 Rs)

Not everything migrates the same way. Classify each workload:

  • Rehost, lift-and-shift as-is (fastest, least optimized)
  • Replatform, small tweaks, e.g. managed database instead of self-hosted
  • Repurchase, move to a SaaS equivalent
  • Refactor, rearchitect for cloud-native (highest effort, highest payoff)
  • Retire, turn it off; you may not need it
  • Retain, leave it where it is for now

Phase 3, Prepare the landing zone

Set up the AWS foundation before workloads arrive: account structure, networking, identity, and logging. Migrating into a messy single-account setup just moves the mess.

Phase 4, Migrate data carefully

Data is where migrations actually go wrong. Use replication to keep source and target in sync, then cut over during a low-traffic window with reconciliation checks on both sides.

bash
# Lower DNS TTL a day ahead so cutover propagates fast
# Replicate continuously, verify row counts + checksums, then flip
aws route53 change-resource-record-sets ... # TTL 60s pre-cutover

A migration without a tested rollback is not a plan, it is a bet. Always know how to get back.

Phase 5, Cut over and validate

  • Run the cutover in a low-traffic window
  • Validate against your pre-migration performance baselines
  • Keep the old environment warm until you are confident
  • Have the rollback runbook open and tested

Phase 6, Optimize after landing

Once stable, right-size and clean up. Migrating and optimizing at the same time is how you introduce variables you cannot isolate when something breaks. Land first, optimize second.

If you want the landing zone and cutover handled by people who have done it before, that is exactly what our cloud migration work covers, with the rollback plan written before we touch anything.

#Cloud#AWS#Migration
DM

About the author

Deep Mehta

Deep is the founder of 3 Dices Technology, a cloud engineering studio. He has shipped AWS architecture, DevOps automation, and production AI systems for startups and SMBs, and writes about the practical version of that work, not the conference-talk version.

Connect on LinkedIn

Frequently Asked Questions

How long does a cloud migration take?
A single application can move in days; a full estate is usually 4–12 weeks spread across phases so each cutover is low-risk.
Can we migrate with zero downtime?
For most workloads, yes, using continuous replication and a cutover in a low-traffic window with a tested rollback ready.
What are the 6 Rs of migration?
Rehost, replatform, repurchase, refactor, retire, and retain, a framework for choosing the right move per workload instead of treating everything the same.

Have a Question This Didn't Answer?

Ask us directly, we're happy to share what we know about your specific situation.