The Public-Sector Linux Migration Is a Compliance Decision, Not a Cost Cut

Why the strongest argument for the move is the one that rarely makes the press release.

Every public-sector Linux migration gets reported the same way: a government is leaving Microsoft, and here is how much it expects to save. Schleswig-Holstein announced in 2024 that it would move roughly 30,000 government workstations to Linux and LibreOffice. Staatskanzlei Schleswig-Holstein, Einstieg in den Umstieg (2024) Denmark's Ministry of Digitalisation began phasing Microsoft out of its own department in 2025, with Copenhagen and Aarhus moving in the same direction. Digitaliseringsministeriet, digital sovereignty pilot (2025) The Austrian Bundesheer committed to migrating 16,000 workstations off Microsoft Office. Collabora, Austrian Armed Forces case study The French Gendarmerie has been running its own Ubuntu build across tens of thousands of machines since 2008 and is still running it today. Canonical, Gendarmerie Nationale upgrades 85,000 PCs

Read those as budget stories and you will draw the wrong conclusion, because the budget case is genuinely arguable. Migration costs real money in retraining, document remediation and line-of-business application work, and the savings arrive slowly. If licence cost were the whole argument, a finance director could talk you out of it in one meeting.

The argument that survives that meeting is a compliance argument. What these organisations are buying is a control environment they can inspect, evidence them, and defend in an audit — on a lifecycle they set themselves.

Auditors do not test intent. They test evidence.

Sit in enough SOC 2, FedRAMP and SOX ITGC testing and a pattern emerges: the finding is almost never "the control does not exist". It is "we could not evidence that the control operated for every item in the population". Population completeness is where programs bleed.

Configuration state is the most common failure point. When your baseline lives inside a management console, the evidence you can produce is a screenshot of a console at a point in time, plus a report the vendor generates from a data model you cannot see. That is testable, but it is testable at the vendor's resolution, and every question the auditor asks outside that resolution becomes a support ticket.

When your baseline is expressed as declarative configuration in version control — Ansible, Puppet, a Nix or image build definition, a set of systemd units and package pins — the evidence changes shape. The population is the repository. The change history is the change log. Drift is a diff, not an opinion. You can hand an auditor a deterministic answer to "show me every workstation configuration change in Q2, who approved it, and what it changed" without asking anyone to take a screenshot.

That is the same argument I make about change management generally: the control should emit its own evidence as a by-product of doing the work, rather than requiring a second, parallel documentation activity that everyone resents and nobody keeps current.^[1]

End-of-support is a control finding, not an IT ticket

Unsupported software is one of the few findings that writes itself. Every framework in the regulated stack expects vulnerable components to be remediated or replaced on a defined cadence, and an operating system that no longer receives security fixes fails that test on its face.

The uncomfortable part is that the timing of that finding is not yours. Windows 7's end of support pushed South Korean agencies toward Linux; the Interior Ministry publicly framed the shift as a way out of recurring dependency and upgrade cost. The Korea Herald, S. Korean government to switch to Linux The French Gendarmerie's own account of its migration credits the XP deadline with forcing a decision it had been deferring. ZDNET, How the end of XP support helped France's gendarmes embrace Ubuntu Windows 10's end of support produced the same scramble a decade later, this time with hardware eligibility rules attached.

The point is not that Linux never reaches end of life. It is that with a long-term-support distribution you choose the support window, you can extend it commercially or maintain it yourself, and the decision is not coupled to a hardware refresh someone else defined. For a public body running a ten-year asset cycle, that is the difference between planned remediation and an unplanned finding.

You cannot secure a supply chain you cannot enumerate

Software bill of materials requirements have moved from aspiration to procurement clause. US federal software suppliers have been working to SBOM expectations since Executive Order 14028, and the EU's Cyber Resilience Act pushes comparable obligations onto products sold into Europe. CISA, Software Bill of Materials

An open platform makes that obligation tractable. Package managers already know exactly what is installed, at what version, from which signed repository, and distributions publish machine-readable vulnerability data against those versions. Generating a complete SBOM for a fleet becomes a query rather than a project. On a closed platform, most of your inventory is a vendor attestation you are obliged to trust and unable to verify.

When a critical CVE lands on a Friday, the operationally useful question is "which of my 30,000 endpoints contain this component". The platform that can answer that in minutes is the one that will keep your incident-response control from failing its next test.

Sovereignty matters, and it is a separate conversation

Nearly every migration above is framed publicly around digital sovereignty: keeping citizen data under domestic jurisdiction and reducing dependence on a small number of foreign providers. That is a real and serious driver, and it deserves its own treatment — jurisdictional exposure, cross-border transfer mechanisms and the concentration risk of a single hyperscaler are a different analysis from the one above, and I will write it separately. Set it aside here, and the operational case still stands on its own.

Where these programs actually fail

Munich's LiMux is the case everyone cites as the counterexample, and it is instructive for the wrong reason. LiMux ran for over a decade and was reversed in 2017, but the post-mortems consistently point at organisational causes: split responsibility between central IT and departments, unresolved line-of-business application dependencies, a support model that never matched user expectations, and shifting political sponsorship. Interoperable Europe / OSOR, LiMux The Gendarmerie, running a comparable technical migration with a single accountable owner and a standard managed image, is still on Linux twenty years on.

The difference is governance. That is also the reason to treat this as a compliance program rather than a desktop project: the disciplines that make a migration stick — a defined owner, a documented baseline, change control over that baseline, evidence of exception handling — are the same disciplines an auditor will test afterwards.

If you own compliance for a platform facing this decision

Five things worth doing before anyone chooses a distribution:

• Write down which controls currently depend on a vendor console for evidence. That list is your real migration scope and your real benefit case.
• Name one accountable owner for the endpoint baseline, with authority over departmental exceptions. LiMux's failure mode starts here.
• Put the baseline in version control from day one, and route changes to it through the same change process as production. Retrofitting this later costs an audit cycle.
• Inventory line-of-business applications and document formats before committing a date. The unmigratable 5% is what sets the timeline.
• Agree with your auditor, in advance, what evidence the new configuration management will produce. Getting that acknowledged early converts a perceived risk into a demonstrated improvement.

None of this makes the migration cheap or fast. It makes it defensible — which is the standard the decision will actually be judged against, long after the licence savings have been absorbed into a budget line nobody reads.