You Moved the Data to the Cloud. Who Owns the Numbers Now?

I recently read a thoughtful piece from a consultancy about cloud migration in financial services, and I agreed with almost every sentence in it, which is exactly what made me uneasy, because it said the right things at a level where nobody can disagree and nobody knows what to do on Monday morning. Migration should be driven by business value, governance matters more than security, data localisation limits centralisation, and senior sponsorship is critical. All true. What I missed was the part I see most often in practice, namely that a cloud migration moves not only the data but also every unresolved argument about what that data means, and that the new platform then starts charging by the hour for the privilege of hosting those arguments.

Why do so many cloud migrations cost more than planned?

The numbers on this have been uncomfortable for years. In McKinsey’s 2022 survey of around 450 CIOs and IT decision makers, 75 percent of companies said their cloud migration had gone over budget, and 38 percent said it was behind schedule. Four years later the problem has moved from the migration project to the running bill: in Flexera’s 2026 State of the Cloud report, based on more than 750 cloud decision makers, 85 percent name managing cloud spend as a top challenge, and 40 percent of those working on AI in the cloud point to data quality for model training as one of their main obstacles.

In my opinion these are not two different problems. A migration that is planned as an infrastructure project is estimated as an infrastructure project, by counting servers, databases and terabytes, and then it runs into the part nobody counted: seven definitions of revenue, three versions of the customer table, reconciliations that used to happen quietly in a spreadsheet on somebody’s laptop and now have to happen inside a platform that meters every query. The overrun is rarely in the storage. It is in the meaning.

What does the shared responsibility model leave out?

Cloud providers are right when they say that security in the cloud is shared, and the consultancy article is right when it says that the focus has shifted from security to governance. I would go one step further. The shared responsibility model divides who protects the infrastructure, who configures access and who encrypts what, but no provider will ever take responsibility for the question that decides whether the migration pays off: who in the business owns this number, which definition of it is the official one, and which system is allowed to change it. That responsibility is not shared at all. It stays entirely with the company, and in my experience it is the one that is most often left unassigned when the project plan is written.

For banks, payment companies and commodity traders this has a regulatory edge as well. In the European Union the Digital Operational Resilience Act has applied since January 2025 and requires financial entities to have exit strategies for critical ICT services, including cloud. An exit strategy is a comfortable phrase until someone asks the practical question behind it, which is whether you could move your data to another provider without also moving, and paying for again, every undocumented transformation that lives inside the current one. A company that does not know who owns its numbers cannot answer that question honestly.

What does it look like when the ownership is settled first?

Two projects from our own work show the difference better than any framework. The first was an international retail group preparing for a group valuation, where sales data from seven CRM systems did not reconcile with the ERP and accounting systems, so management could not fully trust the consolidated figures that were about to be shown to valuers. The platform was already in the cloud, on Snowflake, and it was expensive. The first six weeks were an assessment rather than a build, and it identified around 40,000 dollars a month of potential cloud savings, but I think the more important result was the reconciliation itself: once the seven CRM systems were aligned with the ERP and each number had an agreed definition and source, key reports ran 40 percent faster and, more importantly, management could rely on the consolidated figures again for the valuation. The cost and the meaning turned out to be the same problem seen from two sides.

The second was an international payments technology company that needed access to more than four terabytes of data across three core tables held by another organisation. The conventional route would have been exports, file transfers or a custom API, which means a second copy of sensitive data, a pipeline to maintain and a provider who loses control of what happens to its data once it leaves. Because both sides ran Snowflake in the same cloud region, the data could be shared directly instead of copied: access was in place within one business day, there was no duplicate storage, the consumer paid for its own queries, and the provider kept the right to revoke access at any time. This is, in my view, what governance looks like when it is designed as a property of the platform rather than written as a policy about it.

Where should a migration start?

If I were planning a migration in a bank, an insurer or a trading company today, I would start with three questions before counting a single terabyte. The first is an inventory of ownership: for the twenty or thirty numbers that actually run the business, who owns each one, where is it calculated today, and how many competing versions exist. The second is a classification of what may move, what must stay in a given jurisdiction and what should be shared rather than copied, because data localisation is much easier to respect when it is decided per data set than when it is discovered per incident. The third is a cost model per workload, with an owner and a business case for each, so that the cloud bill becomes a portfolio of decisions instead of a monthly surprise.

None of this is technically exotic. The tools are not the constraint. The constraint is settling ownership while the programme is still being sold as an infrastructure move. What makes it hard is that it is organisational work that has to happen before the migration, when the pressure is to start moving data and show progress. I believe it is the cheapest work in the whole programme, because every definition you settle before the move is one you do not pay to store, process and reconcile afterwards, every hour, in the cloud.

Sources: McKinsey via RTInsights, cloud migration overruns (2022 survey of ~450 CIOs); Flexera, 2026 State of the Cloud Report; Cadvel case study: international retail group sales reconciliation; Cadvel case study: secure data sharing for an international payments technology company

‍