Migrations Are a Mindset, Not a Project

Every migration I've ever run started the same way: with a detailed technical plan and an underestimation of the human work.

The technical plan had Gantt charts, dependency maps, rollback procedures, cutover windows. It had risk matrices and stakeholder communication templates. It was thorough and professional and, in retrospect, treated the hardest part of the project as a line item in the appendix.

The hardest part: getting everyone to genuinely believe the destination was better than the origin.

Why technical migrations are the easy part

Software doesn't have feelings about where it runs. An application migrated from an on-premise VMware cluster to an AWS EC2 instance doesn't miss its old home. It doesn't need to be convinced. It doesn't have institutional memory of the last time someone made a sweeping infrastructure change and it went badly.

People do.

When I was planning our first major AWS migration, I spent weeks mapping workload dependencies, designing VPC architecture, and planning the identity federation strategy. That work mattered. But the project nearly stalled twice — not because of technical blockers, but because of a systems administrator who had spent twelve years building deep expertise in our on-premise environment, and who saw the migration as a threat to everything he'd built.

He wasn't wrong to feel that way. His skills were genuinely specialized and the migration would genuinely reduce their relevance. My mistake was treating that as a people problem to be managed rather than a legitimate concern to be addressed.

The mindset before the migration

The shift I eventually learned to make: the actual migration starts months before the first VM is touched.

It starts when you help the sysadmin understand that cloud operations is a skill set that builds on, not replaces, infrastructure fundamentals. That the people who understand networking and storage and compute at a physical level have a significant advantage when learning to manage the same resources through an API.

It starts when you help the application owner understand that "the cloud" isn't a single thing — it's a collection of services that your team controls, with more visibility and more granularity than you've probably ever had with physical hardware.

It starts when you help finance understand the difference between capital expenditure and operational expenditure, and why the total cost comparison requires honest accounting of the costs that don't appear on hardware invoices: the facilities, the cooling, the hardware refresh cycles, the people hours spent on physical maintenance.

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

On rollback plans

I used to think rollback plans were a form of technical caution. Now I understand they're a form of organizational caution.

The technical rollback — reverting DNS, failing back workloads, restoring from backup — is straightforward in comparison to the organizational rollback. What happens to the narrative when a migration fails and you have to reverse course? What happens to the trust account you've been building with the people who were skeptical?

A failed migration that had a clean rollback and transparent communication is recoverable. A failed migration that was oversold, under-planned, or that left people without information in a critical moment — that can set back cloud adoption at an organization by years.

The rollback plan is the technical version of: what do we tell people if this goes wrong, and how do we make sure they still believe we can get it right?

What I'd tell myself at the start

Run the technical design in parallel with the organizational design, not sequentially.

For every technical risk in your migration plan, identify the corresponding organizational risk. Who loses status or expertise in this change? Who has legitimate fears that they're expressing illegitimately? Who needs to see it working in a lower environment before they'll trust it in production?

And give those people something real, not reassurance. Reassurance is cheap and everyone knows it. Real is: a working proof of concept in a staging environment. Real is: a specific, written-down answer to the exact concern they raised, not a general one about how cloud is reliable. Real is: a clear answer to "what happens to my role when this is done?"

The migration that moves the fastest is the one where everyone is genuinely moving in the same direction.

The destination mindset

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

The migration is done when the new environment is as unremarkable as the old one was. When the on-call team reaches for AWS console the same way they used to reach for vSphere. When the application owner reviews CloudWatch metrics with the same comfortable familiarity they had with their old monitoring dashboards.

That normalization takes longer than the technical cutover. Plan for it. Build in time for people to get comfortable, to find the rough edges, to develop intuitions about the new environment.

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