Cloud migration is rarely a single project. For most startups it is a sequence of small, reversible moves — and the teams that treat it that way finish, while the teams that plan a big-bang cutover usually stall.
Begin with an inventory and a dependency map. The surprises in a migration are almost never the application servers; they are the cron job on a forgotten VM and the shared file mount nobody documented.
Then pick a strategy per workload rather than per company. Lift-and-shift is the right answer for a stable internal service. Re-platforming pays off for anything with variable load. Rewrite only where the current design actively blocks growth.
Finally, budget for the observability work. A migration without metrics and traces in place is a migration you cannot verify, and the rollback window closes fast.
