Cloud Migrations Don't Fail for Technical Reasons
The infrastructure goes up on time, and six months later nobody works differently. The AWS Cloud Adoption Framework has six perspectives and only two are technical — yet most migration plans ignore the rest. A change management playbook for cloud migrations, plus a five-minute diagnostic for your current project.
There is a scene that keeps repeating.
The migration project is planned well. It executes reasonably well. The infrastructure ends up running, the cutover happens, the team celebrates. And six months later half the organization still works the way it did before, there are duplicated processes nobody owns, and someone in a steering committee asks why the promised savings haven't appeared anywhere in the budget.
The technical part went fine. The project went badly.
Anyone who has accompanied organizational change recognizes the pattern immediately, because it isn't a cloud problem. It's the same problem as always: we managed the technology and we didn't manage the people.
AWS already says this, but few people read that part
What's interesting is that this isn't an outside criticism. The AWS Cloud Adoption Framework itself organizes adoption into six perspectives: business, people, governance, platform, security and operations.
Six. And only two of them are strictly technical.
In practice, most migration plans I've seen discussed dedicate the overwhelming majority of their effort to platform and operations. The people perspective — culture, organizational structure, skill gaps, leadership — tends to show up as one slide near the end, with the word "training" and a number of hours next to it.
Training is not change management. It's one component of change management.
Translating the playbook
Nothing here needs inventing. Kotter's model applies as-is; it just needs translating into migration language.
Build a sense of urgency. In a migration, urgency is rarely obvious to anyone outside IT. "We're moving to the cloud" means nothing to the accounts receivable coordinator. "You'll be able to close the month without waiting for someone to free up the server" means everything. Urgency is built in each area's own language, not in the project's.
Form a guiding coalition. The migration committee cannot be only technical. If the user-facing areas have no voice in scope decisions, they will have a voice later — in the form of resistance, and at a much worse moment.
Communicate the vision, repeatedly. A migration runs for months. The kickoff announcement is forgotten in three weeks. You have to repeat it, and you have to repeat it showing concrete progress, not percentages on a Gantt chart nobody understands.
Generate short-term wins. This is where cloud has a real advantage over most change projects: you can move small, visible workloads first. One report that used to take hours and now takes minutes is worth more than any presentation about transformation.
Anchor it in the culture. If after migrating, the approval process is still the one designed for the era when you had to request a server in writing, we migrated nothing. We just relocated the problem.
A five-minute diagnostic
If you lead or support a migration project, here's an exercise worth doing today.
Open the project plan and count how many activities have an owner who is not from the technical area.
If the answer is "none," or "only the training," you've found your real risk. And you're still in time to do something about it.
Infrastructure migrates in weeks. Habits don't.
Have you lived through this gap — a project that was technically successful and organizationally stuck? What finally unblocked it?
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article