Modernization is a lock, not a leap

Most modernization plans we are shown are shaped like a leap. Current state on the left, target state on the right, a migration in between, and a date. The date is the part everyone argues about, which is a sign the plan is wrong before it starts.

A canal lock is the better shape. You cannot raise a boat between water levels in one motion. You move it into a chamber, close the gate behind it, equalise, and open the next one. Each stage is reversible, each is short, and the vessel is never stranded between levels. That is a less exciting diagram, and it is how the successful platform transitions we have seen actually ran.

First, distrust the failure statistics

Before planning around a number, check whether the number exists.

The most quoted figure in this space is that 70 percent of digital transformations fail, usually attributed to McKinsey. We went looking for the study. Secondary sources cite 70, 69 and 84 percent, sometimes conflating it with an entirely separate Gartner claim about AI pilots not reaching production. We could not trace the figure to a single McKinsey publication with a stated methodology.

Worse, one of our researchers chased a “Gartner: 83 percent of migrations fail or overrun” claim to the page it was attributed to and found the statistic was not on that page at all. It appears to be a fabrication that has entered circulation through repetition.

There is real evidence, and it is more modest. CIO Dive reported in November 2025 on a CloudBees migration study of more than 300 enterprise IT leaders, which found an average loss of $315,000 per platform migration project and an average cost overrun of 18 percent. That is vendor-commissioned research and should be read as such, but it is at least a disclosed sample with a stated figure.

Migration statistics, ranked by whether they exist

What happens when you try to trace the numbers people plan with.

Item	Claimed figure
"83% of migrations fail" not on the page it cites	83%
"70% of transformations fail" no traceable study	70%
Average cost overrun disclosed sample, vendor-commissioned	18%

The gap between the folklore and the evidence is the whole point. An 83 percent failure rate justifies either paralysis or a heroic transformation programme. An 18 percent average overrun justifies staging the work and holding some contingency, which is a far more useful conclusion.

Data mesh, seven years on

The most consequential strategy idea of the last decade deserves an honest retrospective rather than either a victory lap or a dismissal.

Zhamak Dehghani’s original articulation set out four principles: domain-oriented decentralized data ownership, data as a product, self-serve data infrastructure as a platform, and federated computational governance. Read today, the diagnosis holds up well. The centralized data team as a bottleneck between producers and consumers is a real and recurring failure.

Thoughtworks published a genuinely even-handed retrospective in January 2026, and its verdict is worth quoting because it is neither. What worked: central data offices evolving into enabling functions, data products as real value drivers, and hybrid models pairing a central platform with domain autonomy. What did not: domain ownership that was “lip service,” where IT teams were relabelled as domains without gaining any actual business authority, plus analysis paralysis over domain boundaries and consistently underestimated legacy integration effort.

Their conclusion is the line to take away: “Changing ways of working is harder than changing tech.” Data mesh was an organisational proposal that most adopters implemented as an architecture, which is why so many of them got the architecture and not the outcome.

The practical settling point across the industry looks like hub and spoke: a central platform and governance function, with domains owning their own data products on top of it. That is less ideologically pure than the original and considerably more likely to survive a reorganisation.

Ownership is decision rights, not a name in a wiki

The single most common gap we see is a data product with an owner who cannot actually own it.

An owner who cannot prioritise engineering work against their own backlog, cannot approve or reject a definition change, and cannot decline a low-value request is not an owner. They are an escalation point with a title. Ownership that means anything requires the ability to say no, and most org charts hand out the label without the authority.

This is testable before you reorganise. Take one dataset, name its owner, and ask them to reject the next request for a bespoke extract. If they cannot, the ownership model is decorative, and no amount of mesh vocabulary will fix that.

Contracts have quietly matured

One area where the tooling genuinely moved is the interface between producers and consumers. The Open Data Contract Standard, now under Bitol at the Linux Foundation, reached v3.0 in 2024 and v3.1 in 2025, with a sibling Open Data Product Standard reaching 1.0.

Worth knowing what a data contract is and is not. It is a machine-readable declaration of schema, semantics, quality expectations and service levels for a dataset, which can be tested in CI. It is not an agreement that stops an upstream team from breaking things. It is a mechanism that makes the break visible immediately and attributable, which is a smaller claim and a more achievable one.

We would be cautious about adoption claims here. The figures circulating come from the standard’s own stewards and are explicitly self-reported, with the caveat, in their own words, that a GitHub star is a bookmark rather than a deployment.

Cost is now a first-class strategy question

The FinOps Foundation’s State of FinOps 2025, drawing on 861 respondents representing roughly $69 billion of public cloud spend, found workload optimisation and waste reduction the top practitioner priority by a clear margin, and the share of practitioners managing AI spend roughly doubling year over year to 63 percent.

For data teams specifically this changes the modernization conversation. A migration justified purely on capability now has to answer a cost question it did not face three years ago, and the honest answer is often that the new platform costs more in year one and less in year three, if the team changes how it works. If nobody plans for that behaviour change, the cost curve does not bend.

Aeolus view. Ask what the smallest reversible stage is, and whether you could stop after it and still be better off. If the answer is no, the plan is a leap and it will be defended long after it should have been revised. The migrations we have seen go well ran as dual-write, validate, then cut over one consumer at a time, with the old path live throughout. That is slower on the diagram and faster in practice, because nothing has to be perfect on a Tuesday night.

Build versus buy has no honest benchmark

We looked hard for a credible, independently funded like-for-like total cost of ownership study across managed platforms and assembled open source. There is not one. Everything available is produced by a party selling one of the options.

That absence is worth stating plainly, because build-versus-buy decisions get presented with a confidence the evidence does not support. What can be said generally: buy hides its cost in renewals and consumption charges, build hides its cost in headcount and opportunity cost, and the comparison is only meaningful over about five years, which is longer than most people modelling it will be in the role.

Where this leaves you

Modernizing a data platform in 2026 is mostly not a technology problem. The tools are good and getting cheaper. The hard parts are deciding who owns what, staging the transition so it can be stopped, and having an honest cost model that survives the second year.

If you are scoping a modernization and want someone to argue with the plan before it becomes a budget line, that is work we like doing. Sometimes the useful conclusion is that the current platform is fine and the problem is ownership, which is cheaper to fix and harder to hear.