Most conversations about “digital sovereignty” treat it as a procurement decision. Pick a different vendor, sign a new contract, declare the dependency over. The architecture underneath the choice does not get the same attention. After working with several organisations that have actually tried to become sovereign in their document infrastructure (the applications, file formats, and tooling that handle contracts, reports, and other official files), I have come to the conclusion that the architecture is the choice. The vendor name is downstream. This article lays out what a genuinely sovereign document stack requires, and where the standard procurement story breaks down.
What “sovereign” actually has to mean
In practice, a sovereign document stack is one that an organization can keep using even if a specific vendor disappears, raises prices, changes licenses, or gets acquired. The word “vendor” here is doing a lot of work. It includes the company that made the word processor, the company that controls the file format the word processor saves in, the company that hosts the cloud tier, and the consulting firm that runs the migration. A sovereign stack has to be replaceable at every one of those layers without losing access to the existing files.
Most procurement cycles do not test for that. They test for “is this vendor European” or “does this vendor offer an on-premise option” or “is the price negotiable.” Those are real questions, but they are not sovereignty questions. A European vendor of a product that saves in a format controlled by a non-European vendor is not sovereign. It is sovereignty theatre with a friendlier flag.
The test that actually matters is simpler and harder: can the organization still open every document in ten years, on a different stack, without manual conversion, without paying anyone, without asking permission? If yes, the stack is sovereign. If no, it is not, regardless of who signed the contract.
The three things that have to be open
A sovereign document stack rests on three things that all have to be open, not just the one the sales conversation talks about.
- The source code of the application layer. A truly open-source word processor, spreadsheet, and presentation app, with a license that survives acquisition and prevents relicensing. The Mozilla Public License 2.0 is the strongest of the common open-source licenses for this purpose (a license that requires modifications to also be open and prevents a future owner from converting the code to a closed product).
- The document format itself. A standard with a published specification, no royalties on implementation, and a governance process that any organization can participate in. ISO/IEC 26300 (the Open Document Format, ODF) meets this. A “published specification” of a vendor-controlled format does not.
- The format and the application have to be the same standard. A sovereign stack treats the open format as the native format, not as an export option. If the application saves in the open format by default and reads it back identically, the organization is sovereign. If the application saves in a closed format and “supports” the open one as a secondary export, the dependency is still there.
- The supply chain behind the application has to be auditable. Open source code is not sovereign if the binary distribution is signed by a single corporate account in a country that can revoke the signing key. A serious sovereign stack includes reproducible builds (a process where anyone can rebuild the same binary from source and verify the result matches what is shipped) and a foundation-controlled distribution pipeline. Without this, the application is one export-control event away from a forced migration.
These four layers are the test. If any one of them is closed, the stack is not sovereign. The most common failure mode is the third: an application that nominally supports the open format but is engineered around a closed one, so the open-format output is a lossy export rather than a peer-native file.
Why this is harder than it looks
The political case for sovereignty is straightforward. The architectural case is where most deployments fail. Three obstacles come up consistently.
The first is the legacy file problem. Most organizations have decades of files in the dominant proprietary format. The format is published, and the open-source stack can read it, but round-trip fidelity (the ability to save in the open format, reopen in the proprietary one, and preserve every formatting detail) is imperfect. For a finance team or a legal team, “mostly the same” is not good enough. A serious migration is a multi-year project, not a procurement event.
Next, the macro problem. Office documents often contain macros (small embedded programs that automate tasks), and the macro languages in the open-source stack are not identical to the macro languages in the dominant proprietary suite. Some macros port cleanly. Some do not. A team that relies on a specific macro to generate monthly reports has to either rewrite the macro, replace the workflow, or accept the dependency. This is the single most common reason “sovereign” projects get stuck.
Finally, the support problem. The dominant proprietary suite comes with a global support contract, a phone number, and a service-level agreement (a formal commitment about response and resolution time). The open-source stack has a community, a few commercial support vendors, and a much smaller body of institutional knowledge for unusual problems. For a critical workflow, that asymmetry is real. Sovereignty that breaks the help desk is not sovereignty that survives a quarterly review.
What real sovereign deployments look like
A few organizations have actually done this at scale, and the pattern is consistent.
Germany’s federal government folded ODF, alongside the accessible PDF standard PDF/UA, into the Deutschland-Stack (a technical framework that governs how all levels of German public administration procure and build digital infrastructure) earlier this year. The mandate was not a recommendation. ODF is the native format; OOXML (the dominant proprietary office document format) is not on the approved list. The decision was the result of a multi-year review and several public debates about what “sovereign” actually requires.
Italy’s Ministry of Defence has migrated well over 100,000 workstations to LibreOffice under a program called LibreDifesa. The French National Gendarmerie has been on a similar path for two decades. Austria’s armed forces moved 16,000 workstations off the dominant proprietary office suite in 2024 after a 2020 review of what guarantees existed for running office software without a cloud connection. The City of Munich’s long-running initiative is the clearest example that sovereign document infrastructure is achievable at municipal scale, even with the political turbulence that came with the program.
What these deployments share is a willingness to invest in the migration cost over years, not quarters. The savings show up later, in the form of negotiating room with the dominant vendor and in the option to walk away entirely if a contract dispute ever requires it.
What “saving in the open format” actually requires from a vendor
A sovereign stack is not a marketing claim. The application has to make the open format the default for new files and the recommended target for legacy files. Three implementation details separate the genuine case from the export-option case.
- Default file extension on save. If the application offers “ODF” and “Word format” with the same prominence in the save dialog, the dependency is still there. The native format should be unmarked and the proprietary format should require a deliberate choice.
- Round-trip behavior on complex documents. A document with tracked changes, comments, tables, embedded charts, and footnotes should save in ODF and reopen in the same suite with every detail preserved. If the proprietary format loses details the open format does not, the open format is more honest. If the open format loses details the proprietary format does not, the application is not genuinely a peer of the dominant suite.
- Macros and scripting. The macro language has to support the same workflows in both formats. If a complex macro works in the proprietary suite and breaks in the open-source suite, the organization is not sovereign, only price-shopping.
These are auditable, technical requirements. A vendor that says “we support sovereignty” without meeting all three is selling the word, not the architecture.
Trade-offs
Sovereignty is not free. The migration cost is real and multi-year. The macro rewriting is the single largest line item for most organizations, and it is the line item that procurement teams underestimate by the largest factor. The support asymmetry is real too. The dominant proprietary suite has more institutional knowledge, more support staff, and more third-party consultants than any open-source alternative. A small organization that does not have the staff to absorb that asymmetry should think hard before declaring the dependency over.
The format question is also subtler than it looks. “ODF” is a published standard, but specific applications can interpret the standard in subtly different ways. A document that renders correctly in one open-source suite can render with subtle spacing differences in another. That is not a failure of the standard; it is a reality of any complex document format. The mitigation is testing, not switching formats. Organizations that take the open-format route have to commit to running the same suite consistently, not switching every two years chasing a new vendor.
The upside is real too. An organization with a sovereign stack has negotiating room it did not have before. It can credibly walk away from a renewal negotiation. It can hire from a larger pool of developers who know the open stack. It can survive an acquisition of its current vendor without an emergency migration. None of those benefits show up in the first eighteen months of the project. They show up over the next five to ten years.
Bottom line
Sovereign document infrastructure is a multi-year architectural commitment, not a procurement event. The test is whether the organization can still open every document in ten years without asking anyone’s permission. The three layers (open source code, open format, native support for the open format) all have to be present. The dominant proprietary suite fails the test by design. A few open-source stacks, anchored on a published ISO standard, meet the test. The deployments that have actually worked are the ones that treated the migration as a multi-year program with a real budget, not a press release. If your organization is serious about sovereignty, plan for three years and a multi-million-euro (or equivalent) budget. If you cannot commit that, the honest answer is that you are not buying sovereignty, you are buying a different dependency.