Single blog hero image

6. Making Migration Happen (Internally)

2024-09-01

The hardest part of cloud migration isn’t the infrastructure. It’s the people.

We’ve seen migrations blocked not by tech debt, but by fear. Not by lack of tooling, but by lack of trust. Not by what needs to change, but by who has something to lose.

If you want to make a migration succeed, you have to lead your organization through a shift in ownership, incentives, and mindset.

Where Resistance Comes From
Here’s the internal landscape most migrations walk into:

  • Devs blame infra for instability. Infra blames devs for breaking things.

  • Teams are emotionally attached to the stack they built.

  • Some engineers fear learning new tools and losing relevance.

  • Stakeholders don’t see clear business upside.

  • Early CTOs (or founding engineers) don’t trust distributed systems and fear giving up control.

  • The people most comfortable in the current setup feel threatened, and often quietly resist.

These aren’t irrational. They’re human. Migrations don’t just move workloads — they shift who has power, influence, and responsibility.

Who Pushes, Who Blocks
Internal dynamics often look like this:

Drivers:

  • New hires with something to prove

  • People tied to business outcomes (e.g., product, sales, new CTO)

  • Engineers who want to fix long-standing pain points

  • Curious devs eager to learn something new

Skeptics:

  • People whose work will be replaced or transformed

  • Engineers who built the old setup and are proud of it

  • People disconnected from business growth (e.g. fixed-salary roles)

  • Those afraid of losing status, certainty, or tooling comfort

What Actually Works

You don’t bulldoze resistance. You map it, address it, and reroute through influence.

Here’s how we lead through that:

  1. Understand who has what to gain or lose. Migration realigns roles. Know whose roles are expanding, shrinking, or disappearing.

  2. Identify blockers early. Not just technical ones, but people who are quietly resisting. Their silence now will cost you later.

  3. Surface fears and address them openly. Do workshops, 1:1s, or team discussions where people can name their concerns.

  4. Reassign responsibilities proactively. As infra changes, the org chart must shift with it. Don't let ownership drift.

  5. Make C-level alignment public and strong. If the CEO or CTO is not visibly championing the migration, you’re exposed.

  6. Build a crystal-clear business case. Show the "why" in terms of speed, safety, and customer impact. Repeat it often.

  7. Run a workshop to list all concerns. Get skeptics to participate in defining the risks — then show how you're addressing them.

  8. Make commitment visible. Don't rely on silent nods. Ask for explicit alignment. If someone is resisting, ask them to do it transparently.

  9. Tie accountability to outcomes. If someone undermines the migration or creates drag, make it visible. Protect momentum.

What Doesn’t Work

  • Relying on private buy-in. Silence is not agreement.

  • Pretending people will adapt. Most won’t unless they’re guided or given a reason.

  • Letting old heroes dominate the plan. You need shared ownership, not single-point decisions.

  • Avoiding hard conversations. Migration surfaces tension — that’s normal. Avoiding it just delays success.

Migration Is Political

The reality: migration is political. It reshapes power and visibility. Engineers who were once gatekeepers of the stack may now be part of a shared platform. Devs who relied on others now run their own environments. Leadership that once tolerated fragility now has to commit to change.

That’s why we treat migration not as a tech project, but a cultural shift. And cultural shifts need:

  • Clear vision

  • Explicit alignment

  • Transparent decisions

  • Respect for what came before

  • Confidence in where you're going

Make those visible. Address the emotional layer. And your migration won’t just succeed technically — it will succeed organizationally.