The Vendor Exit Problem.

Every software contract a public agency signs has an end date. Procurement documents often spend dozens of pages on what the system must do and a paragraph, if that, on what happens when it stops. That's the vendor exit problem. The data is public and the service is public, but the ability to keep either running after the contract ends often isn't.

The ground under these contracts moves even when the agency stands still. Socrata, the platform behind many US city open-data portals, changed hands when Tyler Technologies completed its acquisition on April 30, 2018, for roughly $150 million. The current version of its API says query requests "must be either authenticated by a user or marked with a valid application token". That's a defensible engineering choice. It's also a change to the terms of access for public records, made by a vendor rather than by a city council.

The same documentation shows a quieter kind of lock-in. Every Socrata dataset has an identifier of "eight alphanumeric characters split into two four-character phrases by a dash", and every API call is built around it. A city leaving the platform can export its rows. It can't take those URLs along, and every dashboard, script and research paper that pointed at them breaks.

Boston is a useful case because its exit went well and still cost something. In 2017 the city traded its "original Socrata-powered open data portal" for a new OpenGov platform built on CKAN, an open-source data management system. The team chose to avoid bringing over information "that is outdated or no longer maintained" and marked older material with a "legacy portal" tag. That's sensible curation. It also shows that a migration is the moment an agency decides, usually without much public notice, which parts of the record survive.

Office and back-office software follow the same logic at larger scale. In April 2024 Schleswig-Holstein's cabinet decided to roll out LibreOffice as the standard office suite for the roughly 30,000 employees of the state administration, with the operating system, collaboration platform, directory service, specialist applications and telephony to follow. By December 2025 the state reported LibreOffice on nearly 80 percent of workplaces outside the tax administration, almost 44,000 mailboxes moved to Open-Xchange, and more than €15 million saved in license costs, against €9 million in one-time migration spending planned for 2026. Those are the government's own figures and nobody has audited them independently yet. Still, the direction is on the record.

Munich is the counterexample, and it deserves a straight telling. The city's LiMux project moved its desktops to Linux, then reversed. In February 2017 the council voted to develop a strategy around a Windows client that didn't exist yet, with costs and write-offs to be reported before a final decision. In November it voted 50 to 25 to move its remaining Linux systems to Windows 10 in 2020, with €49.3 million set aside. One councillor said "Users were unhappy and software essential for the public sector is mostly only available for Windows", adding that about half of roughly 800 required programs didn't run on Linux. The same report notes the migration was never fully realised: the mail servers had already ended up on Microsoft Exchange.

We don't read Munich as proof that open source fails in government. We read it as proof that the operating system was never the hard part. The specialist applications were the lock-in, and moving the desktop without moving them left staff working around them. Munich's own story didn't end in 2017 either. In 2020 a new governing coalition committed to the "Public Money? Public Code!" principle, though the FSFE pointed to "typical loopholes" in the wording.

Auditors and regulators are now documenting the risk instead of leaving it to anecdote. The Dutch Court of Audit found in January 2025 that for 84 of the 126 most important public cloud services used by central government, 67 percent, no risk assessment had been made, warning that services could suddenly stop. In the UK, the competition authority's cloud investigation found that Amazon and Microsoft hold "positions of significant market power", pointed to egress fees, interoperability barriers and Microsoft's licensing as limits on customer choice, and in March 2026 announced a strategic market status investigation into Microsoft's business software.

Dutch central government in the cloud

most important public cloud services with no risk assessment

84 of 126

most important public cloud services with no risk assessment

• Share without a risk assessment 67%

The UK government's own guidance is candid that it's "impossible to avoid technical lock-in completely" and that "the advantages of being locked-in can often outweigh the disadvantages." We agree. Lock-in is a cost like any other. The mistake is pricing it at zero on the day the contract is signed.

Law is starting to set a floor, at least in Europe. The EU Data Act, which applies from 12 September 2025, requires contracts for cloud and other data processing services to set a switching notice period of no more than two months, a transition of at most 30 calendar days, at least 30 days for data retrieval, and "an exhaustive specification of all categories of data and digital assets that can be ported." From 12 January 2027 providers may not impose any switching charges, and they must point customers to an online register of the data structures and formats they use. There's a catch for the public sector: some of these obligations don't apply to services whose main features were mostly custom-built for one customer and aren't offered at broad commercial scale. That describes a lot of government software.

So what goes into the contract before signing? Start with data return. The UK's Digital, Data and Technology Playbook says contracts should oblige suppliers to hand data back at the end, to "enable data extraction in a common format," and to deliver it in time for it to be given to upcoming bidders. Name the formats, and include the schema and metadata, not only the rows: field definitions, code lists, identifiers, revision history. Require a written exit plan, as the Playbook does, and rehearse it before every renewal. The UK cloud guidance suggests teams periodically re-evaluate switching-cost estimates, and the cheapest way to do that is to actually run an export. Put public URLs on a domain the agency controls, so identifiers outlive the vendor. For custom software that can't be open, consider escrow with explicit release triggers. US defence acquisition guidance describes a third-party agent holding code "until a contractually specified condition occurs," while noting escrow is "not preferable in all cases." Where possible, skip the escrow and buy code published under an open licence, which the Playbook already expects of government code.

For any portal or pipeline, the test is simple: if the contract ended tomorrow, what would come out, in what shape, and what would break?