A cloud-migration checklist for SMEs (that doesn't require downtime)

Most cloud migrations fail in boring ways: nobody inventoried the cron jobs, the DNS TTL was a week long, or the database was bigger than anyone had measured. Before touching a single server, we produce three documents — a complete asset inventory, a dependency map, and a rollback plan. If any of the three can't be written, the migration isn't ready to start.

Inventory means everything: servers, cron jobs, scheduled tasks, that one PowerShell script on someone's desktop, and the SMTP credentials nobody remembers setting up. Dependencies matter more than assets — the app often survives a move, but the hard-coded internal IP in its config file doesn't.

For the cutover itself, the pattern that works is parallel running: replicate data to the new environment, keep both in sync, switch traffic in small percentages with a DNS change whose TTL you lowered days earlier. Rollback is then a one-line DNS revert, not a restore-from-backup prayer.

Post-migration is where the savings are won or lost. Right-size instances against real utilization after two weeks, set up budget alerts on day one, and turn on autoscaling only after you've watched real traffic patterns. A migration that ends at 'it works' usually leaves 30–40% of the cost savings on the table.