Cloud migration is now a mature practice, but the failure modes haven’t changed much. The same five mistakes show up across industries, company sizes, and target clouds. Here’s what they look like and what to do instead.
1. Treating it as an infrastructure project
The most expensive migration mistake is framing it as “lift and shift to AWS” or “move VMs to Azure.” That framing puts infrastructure teams in charge of decisions that should be product and finance decisions.
A migration succeeds when you treat it as a portfolio rationalization exercise. For every workload, the question isn’t how do we move it — it’s should we move it, retire it, replace it, or rebuild it. Roughly 20% of workloads in a typical mid-size environment shouldn’t migrate at all.
Get product owners and CFO finance partners in the room before you pick a target architecture.
2. Underestimating the data gravity problem
Compute is easy to move. Data isn’t. We routinely see migrations stall for months because the team didn’t plan for:
- Egress costs from the source environment
- Replication lag during cutover
- Schema and encoding incompatibilities
- Compliance constraints on data residency
Build a data migration runbook before the first VM moves. Know which datasets are hot, which are cold, which can tolerate downtime, and which can’t. The data plan is the migration plan.
3. Lifting and shifting the operational model
Companies that pick up their on-prem ITIL processes and drop them into the cloud lose most of the cost and agility benefits. The cloud rewards a different operating model: smaller teams, more automation, faster change cycles, more direct accountability for cost.
If your post-migration operations look like your pre-migration operations, you’ve spent millions to relocate the same problems.
4. Ignoring FinOps until month six
Cloud bills are easy to ignore until they’re not. Without cost discipline from day one, the typical pattern is: bills grow quietly for six months, the CFO notices, panic ensues, and a hasty optimization sprint claws back 20% — leaving 30% of waste in place.
Set up tagging, budgets, and anomaly detection before the first production workload moves. Make engineering teams accountable for the cost of the resources they provision. The earlier you build this muscle, the cheaper your steady state.
5. Skipping the cultural change
The migration is the easy part. The cultural shift is the hard part. Network teams accustomed to filing tickets become self-service consumers. DBAs who managed twelve databases find themselves managing forty-eight. Security teams used to perimeter controls now police identity boundaries instead.
People aren’t lazy or resistant — they’re operating under the rules of the old environment. Invest in training, restructure on-call, and rewrite job descriptions explicitly. Otherwise you’ll have cloud infrastructure run by an on-prem mindset, which is worse than either.
What good looks like
A good migration is boring. There’s a pre-flight checklist for every workload, costs are visible in real time, the cutover dates are met, and the team running the new environment looks visibly different from the one that ran the old one. If your migration is exciting, something is going wrong.