What successful public sector transitions have in common, and why the technology is the least important part.
Digital sovereignty projects don't fail because of the technology. The technology usually works fine.
They fail because someone tried to swap the software without rebuilding what it sits on. File format standards. Procurement rules. Vendor relationships. Compliance workflows. Training programs. Support networks. The software is the visible layer. Underneath it is an ecosystem, and when you replace the software without replacing the ecosystem, the ecosystem pulls you right back.
This is not an ideological argument for open source. Ideology doesn't survive budget reviews. Every transition that lasted was built on measurable outcomes: lower lifecycle cost, stronger security, operational flexibility, vendor independence. The question was never "is open source morally right?" It was "does it deliver better results?"
When you study the administrations that answered yes and made it stick, in Denmark, France, Germany, and Spain, a pattern emerges. They didn't start with the technology. They started at the top. And they treated the transition not as a one-time project but as a continuous practice of learning and adapting.
That pattern forms a four-layer framework. Strategic foundation at the top. Ecosystem architecture. Technical architecture. Execution and capacity building at the bottom. The layers build on each other. Skip one, and the layer below it collapses.
Layer 1: Strategic Foundation
Schleswig-Holstein's digital minister Dirk Schrödter made a comparison that reframed the state's entire approach. Just as the war in Ukraine exposed Europe's dangerous energy dependence on a single foreign supplier, he argued, dependence on a single foreign technology vendor carries the same strategic risk. Digital sovereignty became a question of institutional resilience, not server management.
That framing matters. The moment sovereignty is treated as an IT department initiative, it is already dying. It needs executive ownership, political weight, and champions across the organization — from politics, IT leadership, and specialist departments — who drive the initiative forward and overcome resistance. The state's open source strategy was backed by a unanimous cabinet decision. That is the kind of foundation that survives a change of government.
France made the same move at the national level. When DINUM ordered every ministry to formalize plans for eliminating foreign digital dependencies by autumn 2026, it was a directive from the top of government, not a suggestion from a technology team.
Open source by default, enforced at multiple levels.
Policy preferences get watered down. The most resilient transitions enforce the default through law, budget, and directive simultaneously.
Germany's Online Access Act 2.0 requires open source to be preferred in public procurement. The federal government made the Open Document Format mandatory. Laws are the hardest commitment to reverse.
Schleswig-Holstein added a structural layer by placing IT budget authority inside the ministry leading the sovereignty initiative. That department declines to fund proprietary solutions when open source equivalents exist. Not a guideline. A budget rule. Whoever controls the budget controls the stack.
Law and budget reinforce each other. Legislation alone gets ignored without enforcement. Budget control alone gets reversed when governments change. Combined, they create a default that holds. And once open source is the undisputed standard, the evaluation framework shifts entirely. The question stops being "open source or proprietary?" and becomes "which open source solution fits best?"
Schleswig-Holstein established its Open Source Programme Office in June 2025 to translate this direction into daily operations: licensing, vendor coordination, security, and accountability across the state.
Layer 2: Ecosystem Architecture
Strategy sets the direction. The ecosystem provides the economic structures that make it last.
Pool the cost.
Open source software is free to use. Maintaining it is not. Hosting, security patches, upgrades, and feature development cost real money. A single municipality carrying those costs alone will underfund the effort or conclude that the proprietary license was cheaper after all.
Denmark's OS2 network solved this: 82 municipalities, 84% of the country, share the cost of building and maintaining open source products. Each pays proportionally to its size. As the network scales, the per-member cost drops toward zero. Open source stops being "free software nobody maintains" and becomes funded public infrastructure.
The model is replicable. A consortium of regional hospitals. A network of school districts. Five neighboring municipalities with the same needs.
Fix procurement.
Traditional public procurement rewards the lowest sticker price. That systematically favors vendors who discount upfront and escalate once the administration is locked in.
The fix starts with Total Cost of Ownership over a 10 or 20-year horizon. But cost alone is not enough. Procurement must also score for security: is the code auditable? Flexibility: can you customize without vendor permission and avoid forced upgrade cycles? Scalability: does adding 10,000 users require buying 10,000 licenses? Interoperability: do systems work across agencies without proprietary bridges? Vendor independence: can more than one company maintain this software?
When procurement evaluates on all of these dimensions, open source doesn't just compete. It wins on merit, not ideology.
Filter out integrators who underbid the actual maintainers, too. If the winning bidder has no relationship with the upstream community and no capacity to deliver security patches, the administration hasn't saved money. It has purchased a liability.
Recirculate the savings.
When an administration drops its proprietary licenses, one question determines whether the transition lasts: where does the money go?
If it vanishes into the general budget, the tools degrade and the pressure to switch back builds fast.
Schleswig-Holstein saves an estimated €15 million per year by dropping Microsoft licensing. That money flows into three channels: local vendor contracts for maintenance and support, training programs for the public workforce, and the change management infrastructure that sustains the transition. That investment is front-loaded and substantial — often the largest single line item in a migration budget — declining as adoption matures and knowledge spreads through the organization.
Connect the players.
A sovereign ecosystem needs an orchestrator. Schleswig-Holstein's DigitalHub connects municipalities with local vendors, shares knowledge across institutions, and makes the ecosystem function as a network rather than isolated experiments. Distinct from the OSPO, which manages compliance and technical standards, the DigitalHub is the connective tissue.
Why ecosystems survive political change.
There is a structural reason these transitions outlast election cycles. When you have built a cooperative investment network, trained hundreds of support specialists, created a local vendor ecosystem, and reformed procurement, reversing course means dismantling all of it. No incoming government wants to destroy a domestic technology economy that employs local companies and delivers measurable results. A single vendor contract can be canceled with a signature. An ecosystem cannot.
Layer 3: Technical Architecture
The first two layers settle who decides and who pays. This one determines whether you are building real independence or swapping one dependency for another.
Test for standards, not labels.
The most common trap: confusing an open source license with freedom from lock-in. Many products are technically open source but unusable without proprietary add-ons for authentication, clustering, or analytics. This is called "open core," and it locks you in despite the label.
France's DINUM applies three tests before recommending software for government use. Can you build it from source? Does more than one vendor support it? Is the governance independent enough that the community can fork if the lead vendor pivots? If any answer is no, the label is cosmetic.
The real question is about the standards underneath. Can you export all your data in open formats? Can another product read it? Are the interfaces documented? As the architects of the Sovereign Cloud Stack put it: sovereignty is in the API layer, not the data center location.
Build modular. Switch fast.
Many government IT systems are monoliths: one vendor, one database, one codebase doing everything. You cannot switch vendors on a monolith.
The alternative: standardized, interchangeable components with published interfaces. Identity, data exchange, document workflows, video conferencing. Each an independent module.
When Jitsi Meet did not meet quality standards, Schleswig-Holstein switched to OpenTalk. Fast and clean, because video conferencing was a pluggable component, not a feature buried inside a monolithic suite. When architecture is modular, switching is an operational decision, not a political crisis.
Stay upstream. Never fork.
When an administration customizes an open source project, it faces a choice: contribute those changes back to the main project, or maintain a private modified version.
Forking feels like control. It is the opposite. A fork diverges over time. Security patches stop applying. Upgrades require expensive manual work. The fork becomes its own lock-in, except now there is no vendor to call.
The rule: customize through configuration, not modification. Contribute every change back. If a change cannot go upstream, question whether it should be built at all.
Layer 4: Execution and Capacity Building
Only after the first three layers are in place should an administration begin the actual migration. This is the layer everyone wants to start with. It is also the layer that fails without the others.
Format first. Operating system last.
The fastest way to kill a sovereignty project is to rip and replace the entire stack overnight.
France's Gendarmerie took four years. In 2004, they standardized on an open file format and replaced the office suite. They let over 100,000 personnel adjust before touching anything else. Only in 2008 did they introduce a Linux operating system, staying on the standard upstream distribution with a thin configuration layer. No deep fork.
Today it runs on 103,000 computers. Total cost of ownership down 40%. Eighteen years later, maintained by a small team, precisely because they built on upstream and gave people time.
Change what people work with before you change what they work on.
Put experts on every floor.
Every administration that made the transition stick invested at least as much effort in change management as in the technical migration itself.
The most effective change management is decentralized: trained specialists embedded in every department, immediately available. Not a central helpdesk. A colleague on your floor who walks over and helps. When someone is stuck on a formatting issue in the new office suite, the difference between a five-minute fix from a nearby expert and a ticket in a queue determines whether the tool gets adopted or resented.
That is why the best migrations staff their floors before they flip the switch. Change managers in every agency. Technical specialists who walk the hallways during rollout weeks. People whose only job, for a defined period, is to make the transition feel supported rather than imposed.
Build an error culture alongside the migration. Regular retrospectives where project teams and end users review what is working and what is not. When leadership participates visibly, feedback improves dramatically. Surfacing problems early is as important as solving them.
Build a workforce, not just skills.
Training teaches current staff new tools. Necessary but not enough. Long-term sovereignty requires engineers who can maintain and develop the infrastructure for decades.
Denmark's OS2 has 136 contributors from 48 municipalities actively maintaining shared codebases. Not a helpdesk. A distributed engineering community. Without this pipeline, you are one generation of retirements from losing the ability to run your own systems.
At any scale
This model works for a municipality of 25,000 and a nation of 67 million. The scope changes. The sequence does not.
A small municipality cannot pass national legislation. But it can commit to open formats and place budget authority with the right people. It cannot build a cooperative network alone. But it can join one, or start a consortium with neighbors facing the same problems.
Barcelona did this at the city level: political commitment, over 80% of new IT investment in open source, a dedicated transition team, and in June 2025 it became the first city globally to adopt the UN's open source principles.
Every year of inaction is another year of compounding lock-in. The playbook is running today across administrations of very different sizes. And they are still learning, still adapting, still switching tools when something better comes along. That is the point. Sovereignty is not a destination. It is a practice.
