Cloud Operating Model: Why Migrations Stall

The migration is complete. The workloads are running, the data centre contract has ended, and the programme board has marked the milestone green.

‍

And yet a simple change to a service still takes six weeks to reach users. Cloud costs are higher than forecast, nobody is quite sure who owns them, and the teams running the service are working the way they did before the move.

‍

That outcome points to a business change problem that was funded and managed as a technology project. Our view is that the fix starts with ownership. Funding models, decision rights, assurance and team skills all need someone to act on them, and that someone is the person accountable for the service after go-live. The post-live service owner’s responsibilities are an extension of the Product Owner’s during agile delivery – this is covered later in this blog.

Where cloud programmes go wrong

In our experience, benefits tend to leak away in three places.

Cloud is treated as a hosting swap. The programme moves applications from one place to another, and the processes around them stay the same. Releases still run to a quarterly rhythm, and the same approvals apply however small the change. The organisation pays for flexibility it never gets to use.

Funding follows projects, not services. A project gets budget, delivers, and disbands. A cloud service needs continuous ownership, funding for improvement, and someone accountable for cost, performance and security once it’s live. When the money stops at handover, ownership ends with it.

Governance is built for a different pace. Change boards, assurance routes and supplier management were designed for infrastructure that changed a couple of times a year. Cloud infrastructure can change several times a day, so teams either wait for approvals that no longer fit or find ways around, and neithe ris good.

‍

What needs to change

Start with ownership. Every service needs a clear owner who is accountable for its outcomes, cost included. Without that, cloud spend belongs to everyone and nobody, and the other changes highlighted below have no one to drive them.

Our assumption: A PO’s engagement typically ends after a short duty of care period following go-live, yet the responsibilities they carry remain necessary for as long as the service runs. The question for every programme is who will hold them, often a service owner on the client side. The duty of care period is the natural window for a deliberate handover, and that handover works best with a route to architectural assurance, so the new owner can keep drawing on technical assurance, governance and compliance traceability as the service changes.

Once ownership is in place, four changes tend to follow:

Funding and commercial models. Funding services for ongoing, product-style delivery lets teams improve them continuously without waiting for the next business case. In multi-supplier environments, contracts and service management need to reflect how cloud services really behave, so each supplier can be held to account for its part of the whole chain.

Decision rights. Teams need authority to make low-risk changes quickly, within guardrails that are agreed in advance and, where possible, automated. Security and compliance become more effective at providing assurers continuous evidence when they’re built into the delivery pipeline than when they’re applied as a gate at the end. Our piece on designing access control into delivery shows what this looks like in practice.

Skills and ways of working. Cloud rewards cross-functional teams that build, run and secure a service together. That doesn’t mean everyone needs to become a cloud engineer. It means leaders deciding early and deliberately on what to train, hire and partner for, and giving their team time to adapt. A cloud centre of excellence can help set shared standards and modern agile practices give those teams a way of working that fits the platform.

‍

Why this matters more in sensitive environments

Regulated environments add pressures that generic cloud advice rarely covers.

• Accreditation cycles can set the pace of every release. If assurance sits outside the delivery team, each change waits in a queue.

• Multi-supplier accountability gets complicated when several contractors share one service. Ownership should be written into contracts and service management from the start.

• Clearance and supply constraints narrow the pool of people who can run the service, so skills planning must begin well before go-live.

Our pieces on modernising in defence without compromising security and delivering Secure by Design programmes cover this in more depth.

In these settings, the operating model belongs in the architecture work from the first design decision. An environment that is compliant on day one can become harder to manage and assure every month afterwards if nobody owns how it changes.

Five questions to ask this week

If you run or sponsor a cloud programme, these questions will tell you quickly which kind of programme you have. They also pair well with a cloud maturity assessment:

• Who owns each service after go-live, and are they accountable for cost as well as availability?

• Is funding in place to keep improving services once the project closes?

• How long does a low risk change take from request to production, and what’s the biggest source of delay?

• Are security and assurance activities built into delivery, or applied at the end?

• Do the people running these services have the skills and the authority to work in the way the platform allows?

If several of these are hard to answer, the migration may be finished while the transformation is still waiting to begin.

Getting the balance right

At Ntegra, our engineers work alongside our business change specialists because we’ve learned that neither half works alone. Strong engineering without operating model change gives you a well-built platform nobody can use to its potential. Strategy without delivery experience gives you a plan that doesn’t survive contact with real constraints.

If you’re planning a cloud programme, or wondering why one hasn’t delivered what it promised, we’d be glad to talk it through with you. And if you’re weighing up outside help, our guide on how to choose a digital transformation consultancy is a good place to start.

Frequently asked questions

What is a cloud operating model?
It is the combination of ownership, funding, decision rights, assurance and skills that determines how a cloud service is run and improved after it goes live.

Why do cloud migrations fail to deliver the expected benefits?
Most are funded and managed as technology projects. The workloads move and the processes, funding and accountability around them stay the same, so releases remain slow and costs go unowned.

Who should be accountable for a cloud service after go-live?
One named person with authority over the service’s priorities, cost, performance and security. Their responsibilities extend those of the Product Owner during agile delivery, who typically hands over after a short duty of care period. The programme should settle who takes over before go-live.

Why does ownership matter more in regulated environments?
Accreditation cycles, several suppliers sharing one service and a limited pool of cleared staff all slow change and blur responsibility. Clear ownership, with continued access to architectural assurance, keeps a compliant service manageable as it changes.

‍