An engineering firm prescribed a CMMS-and-GIS platform three years ago to a private industrial operator. The choice was defensible at the time: the platform had a public API, published OpenAPI 3.0 documentation and export formats stated in the commercial fact sheet. Three years later, the operator becomes part of a corporate group that decides to consolidate operations on a different platform. The operator asks the engineering firm, within the still-active advisory relationship, to support the migration. The first week uncovers what the commercial sheet did not say. The bulk export endpoint exists, but returns each entity in a proprietary paginated JSON that loses the relations between assets, work orders, contracts and tenants. The field mapping toward OGC formats is a matter of interpretation by each integrator. The full historical export requires twelve hundred paginated calls. What was supposed to be a three-month migration turns into an eighteen-month project, and the conversation with the operator changes tone.
The scene cannot be blamed on the CMMS vendor, nor even on the engineering firm that prescribed the platform. It is the consequence of the absence of an explicit contractual criterion at prescription time. In a technical SaaS market where "open API" has become a commercial baseline, the exit clause is what the engineering firm did not negotiate in enough detail. That clause is a technical prescription criterion today, not a legal add-on to be closed on the last page of the contract.
What "open API" actually means
OpenAPI 3.0 is a documentation standard, not a data portability guarantee. A vendor can publish an impeccable OpenAPI specification and expose only operational endpoints: create a work order, update a status, query an asset. The bulk export path — the ability to pull the entire asset master, the entire maintenance history, the entire georeferenced cartography — is a different promise that rarely appears in detail on the commercial sheet. An engineering firm that verifies only the presence of an OpenAPI passes the formal check and skips the useful one.
The second ambiguity is the format. An endpoint that returns JSON is not equivalent to an endpoint that returns GeoPackage, GeoJSON or Shapefile with a documented field schema. A vendor can claim "export in standard formats" while meaning JSON, XML and CSV, none of which carries GIS topology without additional conversion. When migration time arrives, that conversion becomes the hidden project nobody estimated, and the engineering firm ends up absorbing it in unbilled hours.
The four clauses the prescription should fix
The responsibility of an engineering firm that prescribes a long-duration technical platform does not end at the selection. It includes defining the conditions under which the client can leave that platform without technical dependency. Four clauses resolve most cases and should be part of the technical specification or of the contractual annex.
The first is bulk export in OGC formats. For spatial data, the vendor hands over the asset master in GeoPackage or Shapefile with documented attribute schema. For operational data, a normalized format that preserves relations — typically a SQL dump or a multi-table CSV — with published schema. The second is the export of the complete history. Not a twelve-month window; the full record from the start, with original timestamps and user traceability. The third is an SLA on the duration of a complete export process against a reference portfolio; without that SLA, the export becomes an open-ended project of undefined duration. The fourth is a data escrow clause: what happens if the vendor ceases operations, is acquired by a direct competitor of the client, or unilaterally raises commercial terms above an agreed threshold.
Practical verification before signing
Contractual clauses are only worth what their live verification is worth. The verification is straightforward and consists of three tests. The first is a demonstration of the bulk export against a dataset that represents the project — at least one thousand assets with topology, work orders and attachments — not against the vendor's demo dataset. The second is the reading of the exported file by a second platform or an open tool to check that the schema is genuinely self-describing and does not require internal documentation from the vendor. The third is the measurement of the total time from click to complete availability of the downloadable file. If any of the three tests fails, the platform does not meet the criterion, no matter what the commercial sheet says. The operational cost of running these three tests for the prescribing engineering firm is roughly one working day per candidate platform, a cost that is recovered many times over the first time the exercise avoids a migration that would have turned into a project. The absence of this verification is what produces the eighteen-month migration three years later.
At Maptainer we publish the OpenAPI specification URL and the full export flow on the public site, precisely so that prescription does not depend on the salesperson's word but on the technical prescriber's own verification. Comparison between platforms is done under the same criteria against the same class of dataset. The market has reached a level of maturity where a serious engineering firm is entitled to demand that.
The prescriber's extended responsibility
An engineering firm that prescribes a long-duration technical platform prescribes an operating model whose life horizon exceeds that of the project it belongs to. When that model runs into a migration five years later, the engineering firm that prescribed it keeps showing up in the conversation, even if it no longer works with the client. The professional criterion that today separates a defensible prescription from a vulnerable one is not in the platform's functionality — the market has converged on functionality — but in the robustness of the exit clause. That clause is the boundary of extended technical responsibility: the line beyond which the prescriber asserts that their choice will not trap the client when the context changes. Firms that adopt this discipline shift the conversation with their clients from "which platform is more powerful" to "which platform lets us stay in charge of the data three years from now." The second question is the one clients actually want answered, even when they do not know how to phrase it.