← All Insights
Leading cloud programs without getting lost in tooling
Cloud migrations rarely fail on technical grounds. They fail on governance, unclear workload priorities, insufficient enablement and missing program structure.
Cloud migrations rarely fail on technical grounds. They fail on governance, unclear workload priorities, insufficient enablement and missing program structure.
In the current wave of enterprise cloud adoption, organisations are investing at a scale not seen since the SAP ERP rollouts of the 1990s. Hyperscaler contracts worth tens of millions. Platform engineering teams standing up landing zones. DevOps pipelines configured, dashboards built, runbooks documented. And yet, a striking proportion of these programmes are running six to eighteen months behind schedule, delivering significantly less than planned, and leaving their organisations more confused about cloud governance than when they started.
The causes are rarely technical. Cloud platforms — AWS, Azure, GCP — are mature, well-documented, and extensively supported. The tooling is capable. The engineers building the environments are often highly skilled. The failure is upstream: in programme governance, in how workloads are sequenced, in how vendors are managed, and in the absence of a clearly defined operating model for the future state. These are programme management failures, not technology failures.
There is a pattern that appears in almost every large-scale cloud migration we have observed: in the early months of the programme, significant energy goes into selecting and configuring the technical stack. Which infrastructure-as-code tool. Which CI/CD pipeline. Which monitoring and observability platform. Which security tooling. These are genuine decisions that matter — but they are not the hardest decisions in a cloud programme, and they are not the ones that determine success or failure.
While these technical choices are being made and re-made and configured, the programme management layer is typically under-resourced. The governance structure is informal. The steering committee meets irregularly and makes few binding decisions. Workload migration priorities are driven by what is technically convenient rather than what creates business value. Vendor management with the hyperscaler and the system integrator is reactive rather than structured. And the target operating model — how the cloud environment will be run, governed, and optimised once migrations are complete — has not been defined, because "that's a problem for later."
Later arrives. And the programme is not ready for it.
The cloud is a technology decision. Getting there safely, on time, and within budget is a programme management challenge — and it requires programme management discipline from day one.
The reasons large-scale cloud migrations stall are predictable and consistent. Understanding them is the first step to avoiding them.
Unclear migration sequencing. Many programmes sequence workloads based on technical simplicity — "lift and shift the easy ones first" — rather than business value. The result is a migration programme that spends its first twelve months moving low-criticality legacy applications nobody cares about, while the business-critical workloads that would generate real ROI remain on-premises. Stakeholder engagement drops, funding pressure grows, and the programme loses its political mandate before the valuable work begins.
Competing priorities between business and IT. Cloud migrations require sustained engagement from business owners — the people who understand what an application does, who uses it, and what disruption to availability is acceptable. Without that engagement, IT teams are making migration decisions in the dark. Cutover windows are chosen without regard to business cycles. Testing is inadequate because the right people were not involved. Go-live failures occur because business processes were not validated against the new environment.
Vendor management gaps. Large cloud programmes typically involve the hyperscaler, one or more system integrators, existing software vendors whose products need to be re-certified for cloud environments, and internal IT teams. Managing these relationships — aligning commercial terms, coordinating technical dependencies, escalating delivery failures — requires active vendor management. When it is left to happen informally, dependencies between vendors create programme blockers that nobody is accountable for resolving.
Missing operating model definition. A cloud migration without a defined target operating model is a construction project without architectural drawings. Decisions about how to manage the cloud environment post-go-live — who owns FinOps governance, who handles security patching, how change requests are processed, what SLAs the cloud operations team commits to — cannot be made at the end of the migration. They need to be made early, because they shape the architecture, the tooling choices, and the skills the team needs to develop.
Across the cloud programmes we have steered, the ones that deliver consistently share five structural characteristics:
In industrial and transport sector programmes, cloud migrations face an additional layer of complexity that is rarely adequately planned for: the intersection of cloud architecture with operational technology. OT systems — SCADA, distributed control systems, rail signalling infrastructure, factory automation platforms — were not designed with cloud connectivity in mind. They operate on different security models, with different latency requirements and availability expectations than enterprise IT systems.
When a cloud migration programme in an industrial environment fails to account for OT integration early, the programme eventually hits a wall. The cloud landing zone has been built to enterprise IT standards. The OT systems require something fundamentally different. And the two teams — IT and OT — have been working on parallel tracks without adequate coordination, because the programme structure did not define a clear interface between them.
Successful IT/OT integration in cloud programmes requires programme-level coordination: a defined interface between the IT programme team and the OT engineering team, explicit architecture decisions about which systems connect to the cloud and under what conditions, and security governance that satisfies both IT security standards and functional safety requirements. These are not technical decisions that can be left to individual teams. They are programme-level governance decisions that need senior ownership.
Velopad's role in cloud transformation programmes is not to design the cloud architecture. Our clients have cloud architects, hyperscaler teams, and system integrators for that. Our value is in the programme management layer that those technical teams typically lack: delivery governance, workload prioritisation, vendor management, stakeholder alignment, risk management, and the escalation discipline that keeps programmes moving when they hit inevitable blockers.
We act as embedded programme managers — not external advisors producing reports, but accountable delivery leaders who sit in the programme, chair the steering committee, manage the vendor relationships, and own the programme plan. We bring a structured approach to the five elements described above, adapted to the specific context of each programme.
In transport and industrial sector programmes, we bring specific experience with IT/OT integration complexity — understanding both the technology constraints and the organisational dynamics between IT and OT teams that frequently create programme friction.
Every organisation that has successfully completed a large-scale cloud transformation will tell you the same thing: the technology worked. What was hard was the governance, the change management, the vendor coordination, and the organisational alignment required to deliver the programme on time and at the expected cost.
Cloud adoption is now a strategic imperative for most large enterprises. But the organisations that will extract value from that investment are not those with the most sophisticated cloud platforms. They are those with the programme management discipline to get there systematically, with clear governance, realistic sequencing, and a defined operating model waiting at the finish line.
The tool selection can wait until the second steering committee meeting. The programme structure cannot.
We help organisations govern cloud programmes — from workload sequencing to operating model definition and vendor management.
Contact us