The migration lands on time. Eighteen months later, the AI roadmap it was meant to enable still hasn’t shipped. The gap between those two sentences is an ownership problem, and it opens the day the migration programme closes.
Series – this is part 1 of 3 on AI and Cloud consulting. Part 2: How to Buy AI and Cloud Consulting. Part 3: What Transformation Governance Is Actually For.
Cutover succeeds. The programme board declares victory, the steering group disbands, and the delivery partners roll off. With them goes the one person who could get a data access request approved inside a week.
Then the AI initiatives arrive – the ones the business case promised. Each needs data access, an environment, a spend approval, and a pipeline someone will stand behind. Each request lands in a different queue. Six months later the board pack blames data readiness, and AI projects stalling after cloud migration gets discussed as if it were a technology problem.
It’s an ownership problem. The technology was fine on the day it was migrated.
The Migration Programme Was Secretly Your Operating Model
Consider what the programme actually did while it ran. It held a budget with a named owner. It had the authority to grant access, approve spend, and force decisions across team boundaries. It met weekly, tracked blockers, and escalated anything that sat still for more than a few days. Requests moved because a programme manager was paid to make them move.
None of that was designed as an operating model. All of it functioned as one.
When the programme closed, that structure was dismantled rather than handed over – deliberately, because programmes are supposed to end. The workloads stayed. The decision-making machinery around them evaporated, and nobody noticed, because decommissioning scaffolding looks like tidiness right up until you need to change something.
What Nobody Owns After Cutover
Three things lose their owner the day the programme closes, and every AI initiative sits directly on top of all three.
Access. During the migration, an access request had a route: the programme approved it or escalated it, usually within days. Afterwards, the same request bounces between security, the data office, and whichever product team half-owns the source system. No one of them can say yes on their own. All of them can say “raise it with architecture”.
Cost. An AI training run is a spend decision with no natural home. It isn’t one product team’s line item, and finance has no category for it. So it waits for the next budget cycle, and the team that proposed it loses its window and often its sponsor.
Data contracts. The agreements between data producers and consumers – schemas, quality thresholds, delivery cadences – were policed by the programme while it ran. Unowned, they decay one small breaking change at a time. We were brought into one enterprise where that decay had compounded into 2.2 million data conflicts; fixing the pipeline and its ownership took the count to 15,000, a 99 percent reduction. The conflicts weren’t the disease. They were the symptom of contracts nobody was measured on keeping.
The Strongest Case for Embedded Ownership
The counter-position deserves its full weight, because it won the last decade for good reasons.
Product teams sit closest to the workload. They know what it needs, they feel its failures first, and they can change it without waiting for anyone. Autonomy ships faster than any centrally coordinated alternative, and every layer of central approval added to a delivery path slows it measurably. The function a platform team resembles – central IT – earned its dismantling: ticket queues measured in weeks, change boards that met monthly, and an operating culture where the safest answer was always no. Shadow IT was a rational response to that. So was the whole “you build it, you run it” movement.
All of that is true, and a platform team run as a gatekeeping function will recreate every one of those failures with newer tooling. If the real choice on the table is between devolved ownership and a central team that treats the platform as territory to defend, choose devolution. It fails more gracefully.
Why It Loses Anyway
Embedded ownership works when a team can own a thing end to end. AI workloads refuse to be that shape.
Training data crosses team boundaries by definition – the value of the model usually comes from joining sources that no single team produces. Compute spend is shared infrastructure wearing a project costume. Access decisions carry security and regulatory consequences that reach well outside any one team’s remit. Each product team makes locally rational calls, and the platform between the teams belongs to nobody.
The failure is slow, which is why it survives. Nothing breaks at cutover. Each quarter the queues get slightly longer, the data contracts slightly staler, the automation slightly less trusted. A standing platform team at one client removes 6,000 engineering days a year of manual cloud operations through automation it owns and maintains. Automation at that scale is an asset with a maintenance bill. Give it a permanent owner and it compounds. Rotate ownership through product teams and it rots quietly until the day it pages nobody.
A Platform Team That Doesn’t Repeat History
The position is uncomfortable and worth stating plainly: the structure that reliably keeps an AI programme moving after migration is a permanent, centrally funded platform team – the same shape of function most enterprises spent the last decade taking apart.
What changes is the mandate. The team is run as a product, with the internal teams as its customers. It builds paved roads – approved patterns for access, environments, and pipelines that make the compliant path the fastest path. It is measured on time-to-access, time-to-environment, and cost per workload: the queue metrics the old central function was never held to. It stays small and senior, and it is funded as a standing budget line rather than programme by programme, because everything above depends on it outliving whichever initiative is currently fashionable.
One boundary matters. This is an argument about the operating model – who owns the platform and answers its questions week to week. Whether your governance forums would even notice the stall before the board pack does is a different argument, and we make it in What Transformation Governance Is Actually For.
Q&A: Ownership After Migration
Isn’t a permanent platform team just central IT under a new name?
Structurally, yes – and pretending otherwise is how the argument gets lost. The difference is the mandate. The old function was measured on control and stability, so it optimised for saying no. A platform team is run as a product and measured on time-to-access, time-to-environment, and cost per workload. Same position on the org chart, opposite incentives.
Our product teams own their workloads and it works. Why change?
If every workload can genuinely be owned end to end by one team, don’t change it. AI programmes break that condition: training data crosses team boundaries, compute spend is shared, and access decisions carry consequences outside any single team’s remit. Devolved ownership handles the workloads well. It has no answer for the platform between them.
How big should the platform team be?
Smaller than the migration programme it replaces. It’s a product team whose product is the platform: enough people to own access, spend, automation, and data contracts as first-class responsibilities, and senior enough that the other teams accept its calls. Scale follows the size of the estate. The non-negotiable part is permanence.
We’ve already migrated and the stall is happening now. Where do we start?
Name one owner for access, spend, and data contracts this quarter – publicly, with the authority to decide. Have that owner triage the stalled AI initiatives by what’s actually blocking each one; expect most blockers to be ownership questions wearing technical costumes. The structural fix, a funded standing team, follows once the queue makes the cost visible enough to defend the budget line.
Next in the series – part 2, How to Buy AI and Cloud Consulting, takes this argument to the commercial model. Part 3, What Transformation Governance Is Actually For, takes it to the boardroom.
Working Through This With Vertex Agility
Our AI and Cloud consulting practice treats the ownership question as part of the migration, with the operating model named before cutover, FinOps and access governance running from day one, and automation given a permanent home rather than a programme-shaped one.
If a migration is still ahead of you, the cheapest moment to settle ownership is before cutover. Our free Cloud Migration Readiness Checklist puts the ownership questions alongside the technical ones, so the operating model gets designed with the landing zone instead of after it.