5 Mistakes I Made in Cloud Migration (And How to Avoid Them)

Cloud migration is usually framed as a technical exercise. In practice, the hardest problems I've seen had very little to do with technology.

Some of the most painful failures I've been involved in happened before the first workload ever moved. The architecture looked sound on paper. The tooling was modern. The cloud provider wasn't the issue.

The mistakes were in the assumptions.
These are five mistakes I've personally made or inherited in real enterprise migrations, and what I do differently today.

1) Treating migration as a project instead of a foundation

Early in my career, I approached cloud migration like a classic delivery project. Define scope. Set a timeline. Move workloads. Declare success.

Technically, it worked. Architecturally, it didn't.
We ended up with environments that were fragile, expensive, and difficult to govern because no one had defined how the organization was supposed to operate once the migration was “done”.

Cloud is not a destination. It's an operating model.

What I do now is slow the program down before the first workload moves. I define ownership models, decision boundaries, and what “good” looks like after migration. If teams cannot explain who owns cost, security, and runtime decisions, migration only accelerates future problems.

2) Underestimating identity and access complexity

In several early migrations, identity was treated as configuration work: Entra ID integration, some roles, a few service principals, and we moved on.

The consequences always surfaced later. Over-privileged access. Manual exceptions. Security reviews blocking delivery. Temporary fixes becoming permanent.

Identity is not about login. It defines how trust flows through the platform.

Today, identity is the first architectural decision I make. Human identities and workload identities are separated. Privileged access is designed for scale, not heroics. Temporary access always has an expiry path. If identity is weak, everything built on top becomes harder and riskier.

3) Migrating costs without changing behavior

One lesson cost several organizations a lot of money:
Cloud does not reduce cost by default. It exposes inefficiency faster.

In multiple migrations, workloads moved successfully but behavior didn't change. On-prem sizing habits were carried over. Environments stayed static. No one owned spend. Teams had no visibility into the financial impact of their designs.

The result wasn't a technical failure. It was financial shock.

Now, I treat cost as an architectural dimension. Every platform decision includes cost visibility. Teams see the impact of their choices. Guardrails exist before invoices arrive. FinOps is introduced as a collaboration model, not a control mechanism.

Cloud rewards intentional design. It punishes assumptions.
If you want to build that discipline, this is exactly where FinOps & cost governance needs to start.

4) Ignoring network and connectivity reality

It's easy to draw clean diagrams. It's harder to deal with hybrid latency, legacy dependencies, and organizational boundaries.

I've seen migrations stall for months because network design was deferred. IP planning was rushed. On-prem dependencies were underestimated. “Temporary” connectivity patterns became permanent bottlenecks.

Connectivity problems rarely appear on day one. They surface when scale and load increase.

Today, hybrid paths are tested early. Latency-sensitive systems are identified before migration waves. Network design is reviewed with security and operations together. Failure modes are discussed upfront.

If the network is not boring, something is wrong.

5) Assuming AI can be added later

Recently, I've seen a new variation of an old mistake:
“Let's migrate first. We'll add AI later.”

That assumption usually leads to fragmented data, unclear ownership, and security models that block automation. Fixing it later often requires expensive re-architecture.

AI is not a feature you bolt on. It consumes architecture quality.

Even when AI is not an immediate goal, I design for it. Data must be discoverable and governed. APIs must be intentional. Security models must support automation safely. Knowledge cannot live only in tickets and PDFs.

Good cloud foundations make AI possible. Poor ones make it risky.
If you want a pragmatic path, start by strengthening your platform decisions — and treat AI as an operating model concern, not a “phase 2”.

Final reflection

None of these mistakes were caused by missing tools or immature cloud services. They were caused by rushing decisions that deserved more thought.

The most successful migrations I've led had one thing in common: they slowed down before speeding up. They asked hard questions early about governance, identity, cost, operations, and future capabilities.

Cloud success doesn't come from moving fast.
It comes from building the right foundation first.