Moving to the cloud sounds straightforward until you're three weeks in, your staging environment is broken, and half your team doesn't know which database is the source of truth anymore.
We've helped businesses migrate to AWS, Azure, and GCP — and the difference between a smooth migration and a painful one almost always comes down to preparation. Here's the checklist we use internally.
1. Inventory everything
Before you move anything, you need to know what you have. That means every server, database, scheduled job, file share, API, and third-party integration. The stuff you forget about is what breaks first.
Create a spreadsheet. Columns: service name, what it does, who owns it, dependencies, current resource usage, and whether it's a candidate for migration or retirement.
2. Define your migration strategy per workload
Not everything should be "lifted and shifted." For each workload, decide:
- Rehost (lift and shift) — move as-is to cloud VMs
- Replatform — minor tweaks to take advantage of managed services (e.g., move from self-hosted Postgres to RDS)
- Refactor — rewrite to be cloud-native (containerize, go serverless)
- Retire — kill it. You'd be surprised how many services nobody uses
3. Pick your landing zone
Set up your cloud account structure before you start moving things. That means:
- Separate accounts/projects for dev, staging, and production
- IAM roles and policies (not root credentials everywhere)
- VPC design with proper subnet isolation
- Logging and monitoring from day one — not "we'll add it later"
4. Estimate costs before you commit
Cloud pricing is complex, and surprises are expensive. Use the AWS Pricing Calculator or equivalent, factor in data transfer costs (the hidden killer), and add 20% buffer for the unexpected.
Running a proof-of-concept with your heaviest workload for a week will give you better cost data than any calculator.
5. Set up Infrastructure as Code from the start
If you're clicking through the AWS Console to set things up, stop. Use Terraform, SST, CDK, or Pulumi. Every piece of infrastructure should be version-controlled and reproducible.
This isn't just about best practices — it's about being able to tear down and rebuild your environment when (not if) something goes wrong during migration.
6. Migrate data first
Data migration is always the bottleneck. Start with a test migration to measure transfer times and catch schema incompatibilities early.
For databases, use native replication tools to set up ongoing sync between on-prem and cloud. You want both running in parallel before you cut over application traffic.
7. Test in a staging environment that mirrors production
"It works in staging" is only meaningful if staging actually looks like production. Same instance sizes, same data volumes, same network topology. Cutting corners here means your production cutover is your first real test.
8. Plan the cutover window
Decide: are you doing a hard cutover (flip the switch, everyone's on cloud) or a gradual migration (route a percentage of traffic, increase over time)?
Gradual is safer but more complex. Hard cutover is simpler but requires a rollback plan. Either way, define success criteria and a point-of-no-return.
9. Update your DNS and networking
This is where things go wrong at 2 AM. Have your DNS changes pre-staged with low TTLs set at least 24 hours before cutover. Know exactly which records need to change and in what order.
10. Optimize after you're stable
Don't try to optimize during migration. Get things working, verify everything is stable for at least a week, then start right-sizing instances, setting up auto-scaling, and implementing reserved instances for predictable workloads.
The cloud only saves you money if you actively manage it. Otherwise, it's just a more expensive data center.
Need help with your migration?
We've done this enough times to know where the landmines are. If you're planning a cloud migration and want a second set of eyes on your plan — or need someone to run the whole thing — get in touch.