A common narrative in the debate about digital sovereignty goes like this: Hyperscalers create enormous lock-in effects. European organizations therefore need to reduce their dependence on AWS, Microsoft, and Google, rely more heavily on open standards, and move workloads to European cloud providers. There is truth in that argument. Hyperscalers do create dependencies and switching costs concluding in significant market power.

But focusing the sovereignty debate on hyperscalers also obscures a much larger problem. Organizations were accumulating technological dependencies long before the cloud existed. Every new technology generation added another layer of software, infrastructure, interfaces, vendors, and knowledge to what was already there. Most of it never disappeared. The result is what I call tech sediment.

How Tech Sediment Builds Up

Imagine a financial services company that started digitizing its core processes in the 1980s. Customer accounts and transactions ran on a mainframe.

An IT department grew around it: operators, COBOL developers, processes, documentation, and interfaces to other systems. Then came PCs and client/server. The company did not replace the mainframe, it built applications around it and interfaces into it. The web added another layer. Mobile banking added another. Cloud services arrived, but the data center remained. SaaS products were connected. APIs and integration platforms tied everything together. Today, AI applications are beginning to sit on top. Meanwhile, the organization changed as well. Developers retired or left. Teams were reorganized. Vendors disappeared. Documentation became outdated. Nobody maintaining the mobile app today necessarily knows why an interface to the mainframe was designed the way it was twenty years ago.

After forty years, the company therefore doesn't operate one technology stack designed by anyone. It operates the accumulated remains of many technology generations and of the organizations, people, and decisions that came with them.

This is the reality all companies face. The Bundeswehr experienced it in their famous Herkules project, Volkswagen keeps struggling with their 1500 IT systems spaghetti architecture in their shop floor, and Deutsche Bank struggle with their mainframes. But also Big Tech is not immune: PayPal, a leading representative of the dotcom boom, already needs to work on its legacy, and Microsoft does still not get rid of components stemming from 1993.

Why Companies Do Not Simply Clean It Up

Technically, organizations could remove much of their tech sediment. The problem is economics. Modernization projects compete for investment like everything else. Their business cases include investment, run costs, marginal costs, opportunity costs, and the cost of change. A mainframe system optimized over decades may run on fully depreciated infrastructure at very low marginal cost.

Replacing it is a different story. Migration means significant and often uncertain cost of change. Some of the organization’s best engineers need to work on the migration instead of building new capabilities, creating high opportunity costs. And during the transition, old and new systems often have to run in parallel, temporarily increasing run costs.

So even when everyone agrees that the old system should eventually disappear, the economically rational decision often seems to interface it rather than replace it.

Tech Sediment is a Sovereignty Problem

Tech sediment would merely be an architectural nuisance if it did not create risk. But it feeds directly into all six sovereignty risks.

Unknown components increase cyber vulnerability. Hidden dependencies increase the risk of operational disruption and unmanaged regulatory exposure. Aging systems combined with people leaving the organization lead to loss of expertise. Proprietary technologies accumulated over decades create vendor lock in and potentially kill switch exposure. More importantly, sediment creates leverage. Once a technology has become deeply embedded in hundreds of applications, processes, interfaces and skills, replacing the vendor becomes a transformation project.

VMware is a good example. After acquiring VMware, Broadcom ended the sale of perpetual licenses and moved its products to subscription licensing. Customers could continue using existing perpetual licenses, but renewing support required moving toward the new model.  Broadcom could make such a fundamental change precisely because VMware had become deeply embedded in the technology sediment of thousands of organizations.

And VMware is hardly exceptional. The same mechanism exists in databases, ERP systems, operating systems, specialist software, SaaS products and even something as obscure as cemetery management software. This is why focusing the sovereignty debate primarily on hyperscalers misses the actual problem. AWS, Microsoft and Google certainly create lock in. But they are by far not the biggest problem. Lock in is a structural consequence of how organizations accumulate technology over time.

What could be solutions?

One ambitious answer is the Sovereign Cloud Stack. Its basic idea is compelling: standardize cloud infrastructure so extensively that workloads become portable between providers. Cloud infrastructure starts to resemble gasoline. The supplier matters less because the underlying product is interchangeable. But there are three fundamental challenges.

• Fundamental Disincentive of Providers: Providers need to invest significantly to make themselves interchangeable. But commercially, you usually invest into the opposite: product differentiation and customer retention. 
• Sediment is more than Infrastructure: Cloud infrastructure is only one layer of the sediment. A typical company operates dozens or hundreds of applications, often deeply integrated with each other. True interchangeability would therefore require not only a Sovereign Cloud Stack, but effectively a Sovereign Slack Stack, a Sovereign Miro Stack, a Sovereign SAP Stack, and so on.
• The technology keeps moving: Even virtualization, a mature market, is changing again. OpenStack may provide today's abstraction layer, while newer architectures increasingly combine Kubernetes directly with physical infrastructure.

Even ordinary competition struggles against this effect. A competing product can be substantially cheaper and still fail to persuade customers to migrate. The relevant price is not the license price alone. It is the total cost of change the existing sediment.

Sovereignty Is the Ability to Move

The popular narrative is not wrong. Hyperscalers create lock in, and over time they become another layer of the tech sediment. But hyperscalers are only one manifestation of a much broader problem.

Tech sediment is a structural consequence of how technology evolves and how organizations adopt it. New platform shifts arrive, companies connect them to what already exists, and another layer accumulates. We should keep looking for economic, technical, or regulatory answers to turn the tech sediment into something that participates in functioning, flexible markets. But until then, only Epictetus offers the answer: focus on what is within your control.

Then you can do what David Heinemeier Hansson and 37signals did. First, they moved from their own infrastructure into the public cloud in the 2010s. About 10 years later, when the economics no longer worked for them, they reversed that decision and moved back to their own hardware. The exit took less than six months, without consultants and without service interruption, while building redundant infrastructure and deploying their own servers.

Digital sovereignty therefore does not mean having no dependencies. It means maintaining the ability to change them at your own terms.