Every quarter we get called in to rescue a cloud migration that went sideways. The patterns are remarkably consistent, and every one of them is avoidable with a little upfront discipline. What follows is the list we now walk through with every client before a single workload moves.
The first - and most expensive - mistake is lifting and shifting without re-architecting. Dragging a monolith onto bigger virtual machines just moves your bottleneck to a pricier bill. On-premise hardware is a sunk cost you have already paid for; in the cloud, that same idle capacity bills you by the hour, forever. Cloud-native patterns - managed databases, autoscaling groups, event-driven pipelines - are where the savings actually live, and they are the reason a migration pays for itself instead of quietly becoming a new fixed cost.
The second is having no cost observability from day one. Teams switch on the bill at the end of month one and find a number nobody can explain. Tag every resource with an owner and an environment before you provision it, not after. Set a budget alert at fifty per cent of what you expect, not a hundred. If you cannot answer the question of which team caused this week's increase within about five minutes, you do not have cost observability - you have an invoice.
The third is treating security as a post-migration task. Network rules, identity boundaries and secret management are cheap to design at the start and expensive to retrofit once forty services are live and talking to each other over paths nobody documented. The migration itself is the single best opportunity you will ever get to fix permissions that grew organically over a decade - it is the one moment when everything is being touched anyway.
The fourth is skipping a rollback plan. Every migration runbook we see describes in detail how to move forward and says nothing about how to go back. Before each cutover, write down what going back actually requires: is the old system still running, is data still replicating to it, how long can it stay warm, and who has the authority to make the call at two in the morning. If the honest answer is that going back is impossible, you are not migrating - you are gambling.
The fifth is migrating everything at once. A big-bang cutover concentrates every unknown into a single weekend. Thin, reversible slices - one service, one database, one team at a time - mean that when something breaks, and something always does, you are debugging one change instead of forty. The first slice should be something that matters enough to be real but not enough to end a career if it stalls.
There is a short pre-flight test we use. Can you name the owner of every workload being moved? Can you produce last month's cost per service? Can you roll back the first slice within an hour? Does someone outside the migration team know the plan? And is there a date after which you stop migrating and start optimising? Five yeses and the migration tends to be boring - which, for infrastructure, is exactly what you want.
