The migration was flawless. Zero downtime, every test green, the new platform measurably faster on the numbers that mattered. Six weeks later, half the team was still SSH-ing into the old servers "just to check something." The rollback nobody approved had quietly happened anyway — not in the infrastructure, but in people's habits.
I've watched this pattern repeat across banks, telcos, and startups from Muscat to Istanbul. Engineers treat transformation as a deployment problem: ship the better thing, and adoption follows. It doesn't. Change is a people problem wearing a technical costume, and the sooner you design for that, the fewer of these ghost-rollbacks you'll have.
Resistance is usually rational
When a senior engineer drags their feet on the new pipeline, the reflex is to call it stubbornness. It rarely is. That person spent three years building instincts about where the old system breaks at 2 a.m. Your shiny replacement resets that expertise to zero. What looks like resistance is often an accurate risk assessment: the new tool is better on average and worse in the specific failure they already know how to survive.
Once you see resistance as information rather than obstruction, your job changes. You're not overcoming people; you're closing the gap between "better in the demo" and "safe in production at 2 a.m."
Map the change before you ship it
Every transformation redistributes three things: status, muscle memory, and control. Before writing a rollout plan, I write down who loses each.
- Status: Who was the go-to expert on the old system, and what do they become on the new one? If your migration turns a respected veteran into a confused beginner, you've built your loudest skeptic by accident.
- Muscle memory: Every keystroke someone has automated is a small tax you're about to charge them. Multiply it across a team and a quarter, and "just learn the new CLI" is a real productivity hit, not a footnote.
- Control: Does the change move a decision out of someone's hands into a platform, a policy, or another team? People fight hardest over autonomy they're about to lose.
None of these show up in a test suite. All of them decide whether your rollout sticks.
Run change like an incident, not a memo
The worst way to announce a significant change is a Friday email that opens with "Effective immediately." The best transformations I've run borrowed their structure from incident response, because engineers already trust that ritual.
- One named owner. Not a committee, not "the platform team" — a person whose job is this change landing well.
- A predictable comms cadence. What's changing, when, what breaks, and where to shout when it does. The silence between announcements is where rumors compound.
- A blameless line for the old way. Nobody who preferred the previous system is an idiot. Say so, out loud. It costs nothing and buys enormous goodwill.
People don't resist change. They resist being changed — especially by someone who never acknowledged what the old way did well.
Make the new way the path of least resistance
Culture follows defaults. You won't win a transformation by asking people to be disciplined; you win it by making the right thing the easy thing and the old thing genuinely harder to reach.
Concretely: seed the new platform with working templates, not empty docs. Migrate the noisiest team first and let their relief do your marketing. And once you've committed — delete the old path. A migration with a permanently open escape hatch isn't a migration; it's two systems to maintain and a team that never fully commits to either.
Where to start Monday
Pick one change already in flight. Spend thirty minutes writing down who loses status, muscle memory, or control — by name. Then find the single person most likely to become your loud skeptic, and talk to them before the rollout, not after. That one conversation will teach you more about your transformation than any dashboard.
The technical migration is the part you can test. The human one is the part that decides whether the test mattered.