Why Modernization Should Be a Lock, Not a Leap

Most modernization plans are designed as a leap: current state on the left, target state on the right, and a migration date in the middle. When the date becomes the primary point of contention, it is a sign the plan is flawed from the start.

A canal lock is a better model. You cannot raise a vessel between water levels in one motion. Instead, you move it into a chamber, close the gate, equalize the pressure, and open the next gate. Each stage is short, reversible, and ensures the vessel is never stranded.

It is a less dramatic diagram, but it is how the most successful platform transitions actually operate.

Distrust the failure statistics

Before planning around a “failure rate,” verify if that number actually exists.

The most cited figure in the industry claims that 70% of digital transformations fail, usually attributed to McKinsey. We searched for the source. Secondary sources cite 70%, 69%, or 84%, often conflating these with separate Gartner claims about AI pilots. We could not find a single McKinsey publication with a stated methodology to support the figure.

Some claims are even more tenuous. One of our researchers traced a “Gartner: 83% of migrations fail or overrun” claim to its cited source, only to find the statistic was entirely absent from the page. It appears to be a fabrication sustained through repetition.

Real evidence is more modest. A November 2025 CloudBees migration study of over 300 enterprise IT leaders found an average loss of $315,000 per platform migration and an average cost overrun of 18%. While this is vendor-commissioned research, it provides a disclosed sample and a grounded 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 folklore and evidence is critical. An 83% failure rate justifies either paralysis or a “heroic” transformation program. An 18% average overrun justifies staging the work and maintaining a contingency—a far more useful conclusion for any leader.

Data Mesh: Seven years later

The most influential strategy of the last decade deserves an honest retrospective.

Zhamak Dehghani’s original articulation proposed four principles: domain-oriented decentralized ownership, data as a product, self-serve infrastructure, and federated computational governance. The diagnosis remains correct: centralized data teams are almost always a bottleneck between producers and consumers.

A January 2026 retrospective by Thoughtworks offers a balanced verdict.

What worked:

• Central data offices evolving into “enabling functions.”
• Data products acting as genuine value drivers.
• Hybrid models pairing central platforms with domain autonomy.

What failed:

• “Lip service” ownership, where IT teams were relabeled as “domains” without gaining business authority.
• Analysis paralysis over domain boundaries.
• Consistent underestimation of legacy integration efforts.

The core lesson: “Changing ways of working is harder than changing tech.” Many organizations implemented Data Mesh as an architecture rather than an organizational shift, which is why they achieved the technical setup but not the intended outcome.

The industry is settling on a “hub and spoke” model: a central platform and governance function supporting domains that own their own data products. It is less ideologically pure than the original vision, but significantly more resilient to reorganization.

Ownership is decision rights, not a wiki entry

The most common gap in modern data strategies is the “owner” who cannot actually own.

If an owner cannot prioritize their own backlog, approve or reject a definition change, or decline a low-value request, they are not an owner. They are an escalation point with a title. True ownership requires the authority to say “no.”

You can test this before reorganizing. Take one dataset, name its owner, and ask them to reject the next request for a bespoke extract. If they cannot, your ownership model is decorative. No amount of “mesh” vocabulary will fix that.

The quiet maturation of contracts

Tooling has genuinely improved at 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, while the Open Data Product Standard reached 1.0.

It is important to define what a data contract actually is:

• It IS: A machine-readable declaration of schema, semantics, quality expectations, and service levels that can be tested in CI.
• It IS NOT: A legal agreement that prevents an upstream team from breaking things.

A contract does not stop the break; it makes the break immediately visible and attributable. That is a smaller, more achievable claim.

Note that adoption figures in this space are often self-reported by the standards’ stewards. As they admit, a GitHub star is a bookmark, not a deployment.

Cost as a first-class strategy

The FinOps Foundation’s State of FinOps 2025, analyzing $69 billion in public cloud spend across 861 respondents, found that workload optimization and waste reduction are now the top priorities. Additionally, the share of practitioners managing AI spend has nearly doubled to 63%.

This shifts the modernization conversation. A migration justified purely on “capability” must now answer a cost question that didn’t exist three years ago. 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. Without a plan for behavioral change, the cost curve never bends.

Aeolus view — Identify the smallest reversible stage of your plan. Ask: “If we stopped here, would we still be better off?” If the answer is no, you are planning a leap, and you will find yourself defending that plan long after it should have been revised. The most successful migrations we’ve seen utilize dual-writes and validation, cutting over one consumer at a time while keeping the old path live. It looks slower on a slide, but it is faster in practice because nothing has to be perfect on a Tuesday night.

The “Build vs. Buy” benchmark myth

We searched for a credible, independently funded total cost of ownership (TCO) study comparing managed platforms against assembled open source. We found none. Every available study is produced by a party selling one of the two options.

This absence is important. Build-vs-buy decisions are often presented with a confidence that the evidence does not support. Generally:

• Buy hides costs in renewals and consumption charges.
• Build hides costs in headcount and opportunity cost.

A meaningful comparison requires a five-year horizon—which is longer than most people modeling the decision will remain in their current role.

Where this leaves you

Modernizing a data platform in 2026 is rarely a technology problem. The tools are capable and becoming more affordable.

The actual challenges are:

1. Defining who truly owns the data (and giving them the authority to act).
2. Staging the transition so it can be paused or reversed.
3. Creating an honest cost model that survives into year two.

If you are scoping a modernization and want a critical eye on the plan before it becomes a budget line, we can help. If your data isn’t ready for this yet, we’ll help you get there. Sometimes the most useful conclusion is that your current platform is fine, but your ownership model is broken—a problem that is cheaper to fix, though harder to hear.