Most enterprise cloud programmes are run on a rulebook written for a world that no longer exists.
The rulebook is the datacentre-era governance model: change advisory boards, lengthy approval chains, quarterly capacity planning, and project-based funding. Every one of these made sense when infrastructure was physical, scarce, and slow to change, and delivery happened in long waterfall cycles. Applied to cloud, where infrastructure is dynamic, abundant, and provisioned in seconds, and delivery is continuous, the same mechanisms do not just underperform. They actively work against the thing the cloud investment was meant to deliver, and they do it while looking like prudent governance.
Why the Old Rulebook Is Structurally Incompatible
The incompatibility is not a matter of degree, it is structural. Datacentre governance was designed to control a scarce, slow resource by adding deliberation before every change, because in that world a change was expensive and hard to reverse. Cloud inverts every assumption behind that design. The resource is no longer scarce, the change is no longer expensive, and most changes are trivially reversible. Governance built to slow down expensive, irreversible changes, applied to cheap, reversible ones, is friction with no corresponding benefit.
The result is a governance model that imposes datacentre-era latency on a platform whose entire value is speed. Teams that could provision in minutes wait weeks. Delivery that could be continuous is gated to a quarterly rhythm. The cloud is technically present and operationally throttled, and the throttle is the governance model, faithfully doing the job it was designed for in an environment where that job no longer needs doing.
Five Anti-Patterns, and Their Cloud-Native Alternatives
Five datacentre-era governance anti-patterns do the most damage, and each has a cloud-native alternative that achieves the actual goal without the friction.
The first is the change advisory board reviewing every change. The goal, managing risk, is right; the mechanism is wrong. The cloud-native alternative is automated policy and guardrails that enforce the rules continuously, so safe changes flow freely and only genuine exceptions reach a human.
The second is the lengthy approval chain for provisioning. The cloud-native alternative is self-service within guardrails: teams provision what they need from a pre-approved, policy-enforced catalogue, with approval built into the platform rather than added as a queue.
The third is quarterly capacity planning. Cloud capacity is elastic and does not need to be planned quarters ahead. The alternative is to manage capacity dynamically, with cost controls and monitoring, rather than forecasting a resource that now scales on demand.
The fourth is project-based funding that disbands the team when the project ends. The alternative is product-based funding that sustains a team to own a service across its life, because cloud services are operated continuously, not delivered once and handed off.
The fifth is manual compliance checking at the end. The alternative is compliance as code, enforced automatically in the pipeline, so the system is compliant by construction rather than inspected for compliance after the fact.
Governance Redesign Is a Prerequisite, Not a Refinement
It is tempting to treat governance redesign as a later-phase refinement, something to tidy up once the technical migration is done. That sequencing guarantees trouble, because the old governance model throttles the programme from the start, and the throttling gets read as the cloud underdelivering rather than the governance misfitting. A cloud programme governed by datacentre rules cannot produce cloud outcomes, however good its architecture, because the governance is the part actively preventing the outcomes.
This makes governance redesign a prerequisite of the programme, not a nice-to-have within it. The organisation has to decide, early and deliberately, that the cloud will be governed by cloud-native mechanisms, and it has to make that decision against real institutional resistance, because the old mechanisms are familiar, they feel safe, and giving them up feels like giving up control. The reframe that unlocks it is recognising that automated guardrails are not less control than a change board. They are more control, applied continuously rather than occasionally, and without the friction that drives teams to evade it.
Redesign the Governance, or Forfeit the Investment
A cloud programme inherits its governance whether it chooses to or not, and the default inheritance is a datacentre-era rulebook structurally incompatible with everything the cloud is for. Left in place, it throttles the speed, gates the delivery, and funds the work in a way that fights the platform, all while presenting as responsible oversight. The fix is not to govern less but to govern differently: guardrails instead of boards, self-service instead of approval chains, compliance as code instead of end-stage inspection. Redesign the governance to fit the cloud, or accept that the governance you kept will quietly forfeit the investment you made.