Show me a stalled cloud programme and I will show you a plan that funded everything except the organisation.
Every migration plan carries a budget for infrastructure, tooling, and architecture. Almost none carries an equivalent budget for the organisational change that makes the technical work stick. The migration itself is the part the market has already solved. Integrators can move the workloads, and the patterns are well understood. The part that decides whether the programme delivers is the redesign of process and people around the new model, and that is the part most plans treat as an afterthought.
The Technology Was Never the Hard Part
The tools for cloud migration are mature and widely available. Lift-and-shift, re-platform, refactor: the patterns are documented, the skills are hireable, and the vendors are eager. None of that is where large programmes come undone.
They come undone because a cloud platform demands a different way of working, and most organisations keep the old one. Run an elastic, self-service platform through processes designed for scarce physical infrastructure, and you inherit the speed of the datacentre on the cost base of the cloud. The technology changed. The behaviour did not.
Three Process Anti-Patterns That Quietly Defeat Cloud
The first is governance built for the datacentre era. Change advisory boards, multi-week approval windows, and manual sign-offs were sensible when provisioning meant buying hardware. Applied to a platform where a resource appears in seconds, they do not reduce risk. They move it off the books, as teams route around controls that no longer fit the medium.
The second is an approval chain that treats cloud provisioning like procurement. A developer who could technically stand up an environment in minutes waits weeks for it, because the request still flows through a process designed to control capital purchases. The cloud’s central advantage, speed of iteration, gets throttled by a workflow inherited from a world of purchase orders.
The third is a skills strategy that retrofits old roles onto new architectures. Relabelling a systems administrator as a cloud engineer changes a job title, not a capability. Without genuine investment in new skills, in automation, infrastructure as code, and platform operations, the organisation runs modern infrastructure with manual habits, then wonders why the promised efficiency never arrived.
Assess the Organisation Before You Assess the Architecture
The instinct in most programmes is to start with a reference architecture. The more reliable starting point is an honest assessment of whether the organisation can operate a cloud model at all. Three questions surface most of the risk. Can a team provision what it needs within guardrails, without a human approval gate for routine work? Does funding follow durable products and teams, or does it still flow to time-boxed projects? Do the roles on the org chart reflect cloud responsibilities, or datacentre ones wearing new titles?
The answers predict programme outcomes better than any architecture diagram. An organisation that scores poorly here will struggle to operate even a well-designed platform. One that scores well can succeed with an imperfect architecture, because it can adapt. Readiness is not a technical property. It is an organisational one, and it should be measured before the first architecture decision, not discovered after the programme stalls.
What Funding the Organisation Actually Means
Funding the organisation is not a line for training vouchers and a change-management workstream that runs in parallel and reports green. It means designing the target operating model with the same rigour applied to the target architecture, and giving it the same executive ownership. Someone has to own how decisions get made in the new model, not just how workloads get deployed.
In practice that means redrawing decision rights, so the teams accountable for an outcome can act without routing every choice upward. It means rewriting the funding model, so money follows products and platforms rather than projects that disband the moment they ship. It means a real skills plan, with time and budget protected for engineers to learn automation and platform operations rather than absorbing it after hours. And it means redrawing roles to match the work the cloud actually requires, rather than relabelling the work the datacentre used to.
None of this appears on an infrastructure diagram, and none of it can be bought from an integrator as a fixed-scope deliverable. That is precisely why it gets deferred. It is also why the programmes that fund it pull away from the ones that did not, long after both finished the technical migration on time.
The Migration You Cannot Outsource
There are two migrations inside every cloud programme. One moves workloads, and an integrator can run it on a fixed timeline against a clear scope. The other moves people and process to a new operating model, and no one can run it for you. The second is slower, harder to measure, and decisive, which is exactly the combination that leaves it underfunded.
So put a blunt line in the next budget. The organisational change deserves the same money, the same ownership, and the same scrutiny as the infrastructure. Resourced that way, the technical migration finally earns its return. Left as an afterthought, it buys nothing more than a faster way to run the organisation you already had.