The Limits of Digital Independence

In January 2022, a German district administration — roughly 800 employees, two full-time IT staff — migrated its email from Microsoft 365 to a self-hosted Open-Xchange installation. The migration was technically clean. Six months later, a TLS certificate expired unnoticed — the IT team was firefighting a simultaneous storage failure. Outbound email silently failed for three days. Contracts went unsigned. A procurement deadline passed. Nobody knew until a supplier called to ask why they hadn’t received the bid.

The administration had achieved sovereignty over its email. It had also achieved sovereignty over its outages.

This pattern — technically successful migration, followed by operational failure from under-resourcing — recurs across the case studies on this site. Schleswig-Holstein invested €9 million and a dedicated team. The French Gendarmerie built an internal IT organisation over two decades. The district above invested in a migration but not in the operations to sustain it. The difference in outcomes was not the software — it was the staffing.

Every other article on this site makes the case for reducing dependency on non-European providers. This one asks the question that case leaves open: how far should you go?

The answer is not “as far as possible.” It is a calculation — sovereignty value versus operational cost, security risk of under-resourcing, and opportunity cost of diverting expertise from your actual mission. Sometimes that calculation favours sovereignty. Sometimes it doesn’t. Knowing the difference is what separates strategy from ideology.

The Sovereignty Premium

Every system you operate yourself costs more than using a managed service — not in licence fees, but in attention. This is the sovereignty premium, and it is routinely underestimated.

A managed database on AWS (RDS) means Amazon handles patching, backups, failover, monitoring, and scaling. A self-hosted PostgreSQL instance on Hetzner means you handle all of that — or more precisely, your team handles it, on top of everything else they’re already doing. The monthly bill is lower. The total cost of ownership may not be.

Consider a concrete scenario: a 200-person organisation self-hosting five core services — email (Open-Xchange), file sync (Nextcloud), identity (Keycloak), a PostgreSQL database, and a Kubernetes cluster.

• Hosting cost: approximately €800/month on Hetzner dedicated servers. The equivalent on AWS would be €3,000–4,000/month. The 3–5x savings are real.
• Operational cost: each service needs monitoring, patching, backup verification, capacity planning, and incident response. At a conservative 6 hours per service per month, that’s 30 hours — roughly 20 % of a full-time senior engineer’s capacity. At €80/hour fully loaded, that’s €2,400/month in labour.
• Incident cost: when AWS RDS fails, Amazon’s on-call team responds in minutes. When your self-hosted PostgreSQL fails at 2 AM on a Saturday, your team responds — if you have weekend on-call. A single 8-hour outage costs more in lost productivity than a month of hosting savings.
• Opportunity cost: that senior engineer maintaining five infrastructure services is not building the product, improving the workflow, or training the team.

The net calculation: €800/month hosting + €2,400/month labour = €3,200/month — comparable to the hyperscaler bill you were trying to escape, but with the operational risk on your side of the table. The savings are real only if you already have the team. If you need to hire for it, the first two years are a net cost.

None of this means self-hosting is wrong. It means self-hosting is an investment, and investments have returns only when adequately funded. A self-hosted email server run by a competent team with proper monitoring is more sovereign and potentially more secure than a managed service. A self-hosted email server run by an understaffed team that also manages the firewall, the desktop fleet, and the printer queue is a security incident waiting to happen.

The sovereignty question is not “should we control this?” It is: “can we operate this at the level of reliability and security the use case demands?” If the answer is no, sovereignty is not a benefit — it is a liability.

Where Proprietary Solutions Are Genuinely Better

There is a version of the sovereignty argument that goes: “every open-source alternative is good enough; you just need to try harder.” This is not true, and pretending otherwise costs credibility. Some proprietary solutions are, today, measurably better than their open-source equivalents — not because open source is inherently inferior, but because certain problems reward the kind of sustained, concentrated investment that billion-dollar revenue streams enable.

Collaborative document editing

This is the most visible gap. Collabora Online and OnlyOffice are functional and improving, but real-time co-authoring — the experience of multiple people typing in the same document with instant cursor tracking, live comments, and seamless conflict resolution — remains smoother in Google Docs and Microsoft 365. For teams where real-time collaboration is the core workflow (editorial rooms, legal drafting, executive communications), this gap is not theoretical. It’s a daily friction.

The honest recommendation: For document creation — writing, formatting, individual work — LibreOffice is fully competitive. For real-time collaboration, evaluate Collabora or OnlyOffice against your actual workflow. If the gap matters for your team, acknowledge it — don’t pretend it doesn’t exist.

Video conferencing at scale

Jitsi works well for meetings of up to 30–50 participants. For large events — all-hands meetings with 500 people, webinars with screen sharing and breakout rooms, hybrid events with studio-quality streaming — Teams, Zoom, and Google Meet have invested hundreds of millions of dollars in infrastructure that no open-source project has matched. The quality gap for small meetings has narrowed considerably. The gap for large-scale events has not.

AI frontier models

The sovereign AI stack is real and practical for most use cases. But the frontier — the most capable reasoning models, the largest context windows, the most advanced multimodal capabilities — remains the domain of OpenAI, Anthropic, and Google. Open-weight models are catching up rapidly, and for 90 % of business use cases, a Mistral or LLaMA deployment on European infrastructure is sufficient. But for the remaining 10 % — cutting-edge research, complex multi-step reasoning tasks, advanced code generation — the proprietary frontier models are measurably better.

Managed service ecosystems

This is the structural advantage, not any individual product. AWS offers over 200 managed services. Each one eliminates a category of operational work. A startup building on Lambda, API Gateway, DynamoDB, Cognito, and CloudFront has, in effect, outsourced operations for five infrastructure categories. The equivalent on European providers requires five separate tools, five configuration efforts, five monitoring setups. The individual tools exist. The integrated ecosystem does not.

The honest take: For organisations deeply embedded in hyperscaler ecosystems, the switching cost is not just financial — it’s architectural. Pretending otherwise helps nobody.

The Self-Hosting Trap

Self-hosting is the sharpest expression of digital independence — and the one most likely to go wrong without adequate resources.

Deploying software is a project. Operating software is a commitment. The pattern is consistent across sectors: an organisation self-hosts a service, celebrates the go-live, and then discovers — months or years later — that running the service reliably is harder than installing it.

The security dimension

A managed service provider employs dedicated security teams, runs bug bounty programmes, deploys patches within hours, and monitors for intrusions around the clock. A self-hosted installation is exactly as secure as the team running it — no more.

Consider Keycloak, the open-source identity provider recommended for sovereign identity management. Keycloak is excellent software. But a Keycloak instance that is three minor versions behind on security patches, because the team was busy with other priorities, is worse than Okta — not because Okta is more sovereign, but because Okta is being patched by a team whose only job is patching it.

This is not an argument against self-hosting Keycloak. It is an argument for funding the operational capacity to do it properly. If the budget exists to hire or contract a team that keeps the instance current, monitored, and backed up — self-hosted Keycloak is the better choice, full stop. If the budget does not exist, the sovereignty gain is offset by the security loss.

The monitoring blind spot

Crashes are obvious. Silent degradation is not — and it is the more dangerous failure mode. A managed service pages someone when database response time doubles, when a certificate approaches expiration, when disk usage crosses 80 %. Self-hosted systems have alerting only if someone has built it, tested it, and maintains the alerting infrastructure itself. Monitoring is infrastructure. It requires its own maintenance.

The district administration in the opening didn’t lose email because the server crashed. It lost email because a certificate expired and nobody was watching. Not a technology problem — a resourcing problem. And resourcing problems don’t disappear because the software is open source.

A Decision Framework

The district administration in the opening paragraph and the French Gendarmerie run the same category of software. One lost email for three days; the other has operated 103,000 Linux workstations for two decades with 40 % lower TCO than the Windows equivalent. The difference is not the technology. It is not even the budget. It is the match between ambition and operational capacity — and the willingness to be honest about the gap.

The following matrix provides a structured way to make that assessment: where sovereignty adds value, and where it adds risk.

Axis 1: Sovereignty value

How much does controlling this system reduce your concentration risk?

• High: Identity management, email, core data storage. These systems contain your most sensitive data and are the most dangerous to have under foreign jurisdiction. A disruption here is existential.
• Medium: Office suite, file synchronisation, internal messaging. Important, but a temporary disruption is survivable. Data sensitivity varies by use case.
• Low: CDN, public website hosting, monitoring tools, CI/CD pipelines. These systems process little sensitive data and can be replaced quickly.

Axis 2: Operational complexity

How hard is it to run this system reliably?

• High: Email (deliverability), Kubernetes clusters, databases with strict uptime requirements, identity management at scale. These require dedicated expertise and 24/7 monitoring.
• Medium: File sync (Nextcloud), static site hosting, basic application servers. These need attention but are manageable with a competent team.
• Low: Desktop applications (LibreOffice), document format choices (ODF), browser choice. These have near-zero operational overhead.

The matrix

The top-left corner (high value, low complexity) is where every organisation should start. Switching to open document formats costs nothing and creates optionality. Deploying FIDO2 hardware keys improves security and sovereignty. Installing LibreOffice requires no infrastructure.

The bottom-right corner (low value, high complexity) is where sovereignty efforts waste resources. Running your own CDN to serve a public website is operationally expensive and gains nothing — no sensitive data is at stake, and CDNs are trivially replaceable. Using a US-hosted AI API for non-sensitive tasks (summarising public documents, generating marketing copy) is a pragmatic choice when the alternative is deploying and maintaining a GPU cluster for low-stakes work.

The difficult decisions live in the middle and upper-right: systems that are highly valuable to control but operationally complex. These are where the decision comes down to resources, not principles. If you have the team and the budget, self-host. If you don’t, use a European managed provider. If no adequate European managed provider exists, a US provider under a sovereignty-aware contract (data residency, exit clauses, Data Act compliance) is a better choice than an under-resourced self-hosted installation.

Five Rules for Rational Sovereignty

Drawing from the patterns across this site — the successes and failures of public sector migrations, the managed services gap in cloud, the TCO reality of open-source workplaces — five rules emerge:

1. Harvest the free wins first

Open document formats. FIDO2 hardware keys. LibreOffice. Open standards. These cost nothing, require no infrastructure, and introduce zero operational risk — yet they create more optionality than any server migration. ODF instead of .docx means your documents survive a vendor switch. A €50 FIDO2 key eliminates the most common attack vector. If your organisation hasn’t done these, everything else is premature.

2. Never self-host what you can’t staff

A self-hosted Nextcloud that isn’t backed up is worse than Dropbox. A self-hosted Keycloak that isn’t patched is worse than Okta. Every unmonitored service you operate is not a sovereignty gain — it is an unmonitored attack surface. The rule is simple: if you cannot fund an on-call rotation for it, you cannot self-host it. Use a European managed provider instead — managed Keycloak, managed Nextcloud, managed Matrix all exist. Sovereignty does not require running the server yourself; it requires keeping data under a jurisdiction you control.

3. Distinguish data sovereignty from software sovereignty

These are different problems with different solutions. Data sovereignty — ensuring your data stays under a jurisdiction you can enforce — is achievable even with proprietary software. The French Bleu model (Microsoft software on French-controlled infrastructure) demonstrates this. Software sovereignty — ensuring you are not dependent on any single vendor’s product roadmap — requires open source. You may need one, the other, or both, depending on your threat model. Conflating them leads to bad decisions.

4. Hybrid is the target architecture, not a compromise

No successful migration on this site achieved 100 % sovereignty — and none tried to. The Gendarmerie kept 3 % on Windows. Schleswig-Holstein acknowledges permanent exceptions. Austria kept Teams for external meetings. These are not concessions; they are design decisions.

A hybrid architecture with documented criteria — “these systems are sovereign, those are managed, here’s why” — is more resilient than either full dependency or under-funded full independence. The target is not zero US software. It is no single point of failure: no single vendor whose disappearance stops your operations.

5. Measure sovereignty by resilience, not by purity

The test of a sovereignty strategy is not “do we use any US software?” It’s “what happens if our largest vendor becomes unavailable tomorrow?” If the answer is “we switch to a documented alternative within days or weeks,” your sovereignty strategy is working — even if you currently use hyperscaler services. If the answer is “government stops,” your sovereignty strategy has failed — even if every server runs Linux.

Resilience is the goal. Sovereignty is the method. Don’t confuse the two.

The Five Failure Modes of Sovereignty

The case for reducing dependency on non-European providers is sound — concentration risk is real, the economic dependency is measurable, and the alternatives are increasingly viable. But the sovereignty movement has recurring failure modes that undermine its own goals. Five deserve naming:

Sovereignty theatre. Deploying an open-source tool and declaring victory, without funding the operations team to keep it running. The tool sits there, unpatched, unmonitored, and less secure than the proprietary service it replaced. The box is checked. The risk has increased.

100 % purity as a goal. Refusing to use any US-based service, regardless of the operational cost, leading to under-resourced alternatives for every system instead of well-resourced alternatives for the systems that matter. Perfect is the enemy of good — and in infrastructure, perfect is often the enemy of functional.

Ignoring the user. The Munich LiMux reversal was political, but the political case was built on real user complaints. Sovereignty that degrades the daily experience of the people using the systems will generate resistance — and that resistance will eventually find a political vehicle. User experience is not a luxury; it’s a prerequisite for sustainability.

Assuming European means trustworthy. A European company is subject to European law — which is a genuine structural advantage for data sovereignty. But “European” is not a quality label. European software can be poorly maintained. European providers can have inadequate security. European startups can be acquired by non-European companies, as the DigiD/Solvinity case demonstrated. Evaluate providers on capability and governance, not just on jurisdiction.

Underestimating transition costs. Every article on this site includes an “honest about trade-offs” dimension. But the aggregate transition cost — migrating cloud, office, email, identity, OS, and AI simultaneously — is enormous. Organisations that try to do everything at once typically do nothing well. The Gendarmerie took twenty years. Schleswig-Holstein plans for five to seven. These timelines are not signs of slowness; they’re signs of seriousness.

What Follows

Digital independence is a risk management strategy. Like all risk management, it involves trade-offs. Eliminating one risk (vendor dependency) can introduce another (operational fragility). The organisations that navigate this successfully are not the ones that pursue sovereignty most aggressively — they’re the ones that pursue it most intelligently.

The practical sequence, incorporating the limits above:

Start immediately (zero cost, zero risk):

• Switch to open document formats. Save in ODF, not .docx. This is the single most impactful sovereignty step, and it costs nothing. Every subsequent migration becomes easier when your data is in open formats.
• Deploy FIDO2 hardware keys for administrators and executives. €50 per key. Improves security and sovereignty. No operational overhead.
• Audit your vendor dependencies. Map every critical system to its provider, jurisdiction, and alternative. You cannot manage risk you haven’t measured.

Start this quarter (low risk, high return):

• Deploy LibreOffice organisation-wide. Schleswig-Holstein and the Italian military started here. No infrastructure required. The document compatibility gap is manageable with planning.
• Evaluate a European cloud provider for new workloads. Don’t migrate existing systems. Deploy the next new project on Hetzner, Scaleway, or an SCS-certified provider. Build experience before you need it.

Plan in months (moderate effort, team investment needed):

• Pilot Nextcloud, Element, or Keycloak — but only if you can commit the operational capacity. A pilot that dies from neglect teaches you nothing. Budget the staff time before you deploy the software.
• If self-hosting isn’t feasible, use a European managed provider. Managed Keycloak, managed Nextcloud, managed Matrix — these exist and are legitimate sovereignty choices. You don’t have to run the server yourself to keep data under European jurisdiction.

Accept and manage (ongoing):

• Some systems will stay on hyperscalers. Global CDN, frontier AI APIs for non-sensitive tasks, specialised managed services with no European equivalent — these are rational choices, not sovereignty failures. Document them. Ensure exit clauses. Revisit annually.
• Hybrid is the steady state. The goal is not 100 % sovereignty — it’s enough sovereignty that no single disruption is catastrophic. A conscious, documented hybrid strategy is more resilient than either full dependency or under-resourced full independence.

The organisations that will weather the next disruption — whether it’s a licence change, a sanctions expansion, a price hike, or an acquisition — are not the ones that replaced every US service. They’re the ones that reduced their dependency to the point where any single disruption is an inconvenience, not a catastrophe. They did it by investing where it mattered most, not by spreading resources thin across everything.

The district administration in the opening paragraph learned this the expensive way: sovereignty without operational investment is just a different kind of fragility. The Gendarmerie learned it over twenty years: sovereignty with investment compounds into genuine independence. The difference between the two is not conviction — it’s capacity.

Digital independence is not a destination. It is a capability — the capability to switch, to adapt, to absorb a disruption without your operations stopping. Build that capability where it matters. Rent the rest. And be honest about which is which.

Start with our overview: Why digital-independence.org?