Migrations Are a Mindset, Not a Project

Every migration I've run started the same way: a detailed technical plan, and not nearly enough thought given to the people affected by it.

The plan had Gantt charts, dependency maps, rollback procedures, cutover windows, risk matrices. It was thorough. It also treated the hardest part of the project as a footnote: getting everyone to actually believe the new setup would be better than the old one.

The technical side is the easy part

Software doesn't have feelings about where it runs. Move an application from an on-premise VMware cluster to an AWS EC2 instance and it won't miss its old home.

People will.

When we planned our first major AWS migration, I spent weeks on workload dependencies, VPC design, identity federation. That work mattered, and the project still nearly stalled — twice — not because of anything technical. There was a systems administrator who'd spent twelve years building deep expertise in our on-premise setup, and he saw the whole migration as a threat to what he'd built.

He wasn't wrong to feel that way. His skills really were specialized, and the migration really would make some of them less relevant. My first mistake was treating that as a problem to manage instead of a concern to actually address.

The mindset comes before the migration

What I eventually learned: the real migration starts months before anyone touches a VM.

It starts with helping the sysadmin see that cloud skills build on what he already knows about networking and storage, rather than replacing it. It starts with the application owner understanding that "the cloud" isn't one thing — it's a set of services his team controls, usually with more visibility than physical hardware ever gave him. And it starts with finance understanding why comparing capex to cloud spend honestly means counting the costs that never showed up on a hardware invoice: facilities, cooling, the hours spent on physical maintenance.

None of that is technical work. All of it is migration work.

On rollback plans

I used to think of a rollback plan as technical caution. Now I think of it as organizational caution.

Reverting DNS or failing back a workload is the easy part. The harder question is what happens to the trust you've built with the people who were already skeptical, if the migration fails and you have to walk it back.

A failed migration with a clean rollback and honest communication is recoverable. One that was oversold, under-planned, or left people in the dark at the worst moment can set cloud adoption back for years.

A rollback plan is really just an answer, written down in advance, to: what do we tell people if this goes wrong?

What I'd tell myself at the start

Run the technical plan and the people plan side by side, not one after the other.

For every technical risk, there's a matching organizational one. Who loses status or relevance in this change? Who has a real fear they're expressing badly? Who needs to see it working somewhere low-stakes before they'll trust it in production?

Give those people something real, not reassurance — everyone can smell reassurance. Real is a working proof of concept in staging. Real is a specific written answer to the exact thing they're worried about, not a general one about cloud being reliable. Real is answering "what happens to my role" directly.

The destination mindset

One more thing: the end of a migration isn't a technical state. It's a new normal.

It's done when the on-call team reaches for the AWS console the way they used to reach for vSphere, without thinking about it. That takes longer than the cutover itself, so plan for it — give people time to find the rough edges and build intuition for the new environment.

The Gantt chart ends at go-live. The migration ends when nobody calls it "the new system" anymore.