Guides · Cloud

Cloud migration checklist.

By Mokshify Engineering · Updated 17 Jul 2026 · 5 min read

The promised guide, delivered. Whether you are leaving a data centre, a legacy host, or one cloud for another - this is the checklist we run before any workload moves. Print it; argue with it; use it without us.

Before deciding anything

• Inventory honestly. Every application, database, cron job, integration and certificate - including the forgotten ones that only surface at 2am. The migration killer is always the workload nobody listed.
• Classify by risk, not size. Stateless services are luggage; databases and anything with customer state are surgery. Sequence luggage first to build confidence and tooling.
• Measure the baseline. Current latency, throughput, error rates and monthly cost - or you will never be able to say whether the migration worked.
• Choose for reasons you can write down. Team familiarity, region coverage, pricing, managed services - the logo matters least.

The migration itself

1. Land infrastructure as code first. The target environment exists as Terraform before anything moves - reviewable, repeatable, destroyable.
2. Move state with rehearsals. Database migration gets a full dress rehearsal with production-sized data and a measured cutover window - never a first-time-live event.
3. Run parallel, compare, then cut. Old and new serve shadow traffic side by side; discrepancies are found by diffing, not by customers.
4. Cut over behind a rollback. DNS or gateway-level switch with the old environment kept warm until the new one has survived a real load cycle.
5. Decommission deliberately. The old environment dies on a date, after backups are verified restorable - not by fading into an unmaintained liability.

After the move

Re-measure the baseline; set cost visibility per service so the new bill cannot drift silently; and write the runbook while memories are fresh. A migration that is not documented is half-done.

Related: Cloud Engineering service · DevOps practices · All checklists