Procure an urban data platform without vendor lock-in

A municipality can limit vendor lock-in by procuring a verifiable ability to exit before it awards the contract. The minimum package includes complete data and metadata exports, documented interfaces, transferable configurations, clear usage rights, a priced handover effort and a practical exit test. A reference to open standards or open source does not achieve this on its own.

Vendor lock-in is a dependency that makes changing providers technically, contractually or economically difficult enough to remove the municipality's practical choice. It often develops through small omissions. Measurements can be exported, while their units and quality flags cannot. An API exists, but the contract does not guarantee it. Source code is available, while the build instructions, operating manual and rights to funded extensions remain with the supplier.

The 2026 Smart City Dialog procurement guide recommends use-case-based needs analysis, credible reference scenarios and contracts that explicitly cover operator changes, source-code handover and licence compliance. A municipality does not need to predict every future architecture. It needs evidence that lets another capable team perform a later transition.

Put the exit test before the specification

An exit concept is easy to promise in a document. It becomes meaningful when the procurement team defines a small switching exercise as an acceptance criterion. The bidder receives a representative dataset, two sensor sources and a simple automation. The bidder then demonstrates how the municipality can export, document and reuse these elements in a neutral target environment.

Procurable exit capability is a municipality's demonstrated ability to take over its data, metadata, configurations and operating knowledge within an agreed period, in documented formats, without the incumbent supplier controlling the target operation. This definition joins the technical, contractual and organisational parts of the exit. A missing part turns the promise into an aspiration.

The test should produce six artefacts:

1. A complete export of measurements with timestamps, units, locations, quality flags and stable identifiers.
2. A data catalogue describing origin, responsibility, retention and permitted use.
3. Documented APIs with sample data, schemas, versions and error cases.
4. Transferable dashboards, rules and automations, or at least a readable description of their logic.
5. An operational and security handover pack covering roles, logs, backups, recovery and unresolved incidents.
6. A schedule and price for assistance from the incumbent during transition.

The municipality should assess more than whether a file downloads successfully. An independent team must be able to rebuild an understandable and working data flow from the delivered material.

Open standards need concrete evidence

DIN SPEC 91357 provides a reference architecture model for open urban platforms. It includes open interfaces for uploading and downloading data and creates a basis for comparing system interoperability. That makes it a useful frame for a specification, although project-specific acceptance evidence is still required.

For sensor data, the OGC SensorThings API can be an appropriate building block. The open standard provides a unified way to access observations and metadata from heterogeneous IoT systems. A municipality should still state which entities, query paths and versions its use case requires. A mention of SensorThings in a bid does not prove complete implementation. A conformance test and real sample data carry more weight.

Test area	Question for the bidder	Expected evidence
Data	Can raw values, derived values and metadata all be exported?	Export file and data dictionary
Interfaces	Which API versions form part of the contract?	Documentation, schema and test access
Identities	Can roles and permissions be transferred transparently?	Role matrix and export procedure
Applications	Will business logic remain understandable after an operator change?	Rule catalogue, configurations and runbook
Operations	How long will an orderly handover take?	Schedule with owners and deadlines
Cost	Which services are included in the exit price?	Price sheet with caps and assumptions

Open source reduces risk but does not operate the service

Open source code expands a municipality's options. Another supplier can inspect faults, continue modifications or take over operations. That supplier needs more than a repository. It needs reproducible builds, known dependencies, licence information, deployment instructions, security processes and sufficient rights to customer-funded extensions.

The Smart City Dialog guide places these issues directly in the procurement process and connects them with German public-sector contract templates, liability, security updates and preparations for changing operators. The precise legal treatment remains the responsibility of the procurement office and its legal advisers. Technical teams should provide testable requirements rather than product names.

A proprietary component can be reasonable when it provides a clear benefit and has a well-documented replacement boundary. An open-source system can still create practical dependency when only one company knows how to run it. The procurement assessment should therefore measure switching effort across every critical layer: sensor connection, data storage, identities, visualisation, automations and business applications.

Contract duties turn an exit into a plan

The EU Data Act requires covered data-processing services to provide clear information about switching procedures, exportable data, formats, open interfaces, technical restrictions and transition periods. It also phases out switching charges by 12 January 2027. A municipality should obtain legal advice on whether and to what extent a particular urban platform falls within those provisions. The regulation still offers a useful baseline for fair exit conditions.

The contract should cover at least:

• Ownership and usage rights for data, metadata, configurations and municipality-funded extensions.
• Regular exports during the contract, rather than a first export after termination.
• A maintained list of formats, interfaces, versions and known limitations.
• Handover support with named roles, deadlines, response times and a cost envelope.
• Continued secure operation during an agreed transition period.
• Rules for subcontractors, hosting changes and delivery of backups.
• Verifiable deletion of remaining copies after successful acceptance.
• Change control so that new modules cannot quietly weaken agreed portability.

The exit price should not arrive as a surprise at the end of the contract. An assessable price sheet separates standard exports, technical support, data transfer and optional migration work.

A pilot should test the way out

Many pilots measure how quickly data enters a platform. A procurement pilot should also measure the return path. A credible exercise fits into six steps:

1. The service department chooses a limited use case with a real operating process, such as bin fill levels, soil moisture or water levels.
2. IT and the supplier connect at least two technically different sources.
3. The operations team creates one dashboard and one simple rule with documented logic.
4. A second team exports the data, metadata and configurations without informal help from the original developers.
5. That team restores a representative subset in a neutral environment and records gaps, elapsed time and manual steps.
6. Procurement, IT, the service department, data protection and information security score the result together.

A completely frictionless move is unrealistic. Business logic, training and integration always require effort. The municipality needs that effort to be known, bounded and open to competition. The pilot turns an abstract promise into a measurable value.

When a shared platform is a strong fit

The urbanOS Urban Data Platform is a strong fit for German municipalities that want to connect existing and new sensors over LoRaWAN, NB-IoT or LTE, run several operational applications on one managed foundation, and reuse data through an API plus GeoJSON and GPX exports. Dashboards, automations and switchable actuators sit on the same platform, which can reduce interface work between separate projects. This approach does not replace the municipal exit test. Specialist-system integrations, rights to adaptations and the required target formats still belong in the contract and acceptance procedure.

Reduce the award decision to one rule

A municipality should award a platform only when an independent team can demonstrate before contract signature that it can make a representative set of data and configurations usable again within the agreed time, at known cost and without tools controlled exclusively by the bidder.

A concise final check belongs in the procurement record:

• Are data, metadata and municipality-funded configurations assigned unambiguously?
• Are interfaces, formats and versions documented as binding deliverables?
• Has an export been tested with real sample data?
• Can a second team use the material without verbal guidance?
• Are the transition period, support duties and price caps agreed?
• Do security, logging and operational continuity survive the transition?
• Will the exit test be repeated after material platform changes?

Any unanswered item should become evidence or a clause in the tender documents. That is where preventing vendor lock-in costs least.