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.
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.
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
You don’t bulldoze resistance. You map it, address it, and reroute through influence.
Understand who has what to gain or lose. Migration realigns roles. Know whose roles are expanding, shrinking, or disappearing.
Identify blockers early. Not just technical ones, but people who are quietly resisting. Their silence now will cost you later.
Surface fears and address them openly. Do workshops, 1:1s, or team discussions where people can name their concerns.
Reassign responsibilities proactively. As infra changes, the org chart must shift with it. Don't let ownership drift.
Make C-level alignment public and strong. If the CEO or CTO is not visibly championing the migration, you’re exposed.
Build a crystal-clear business case. Show the "why" in terms of speed, safety, and customer impact. Repeat it often.
Run a workshop to list all concerns. Get skeptics to participate in defining the risks — then show how you're addressing them.
Make commitment visible. Don't rely on silent nods. Ask for explicit alignment. If someone is resisting, ask them to do it transparently.
Tie accountability to outcomes. If someone undermines the migration or creates drag, make it visible. Protect momentum.
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.
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.
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.