Three years ago, a 45-person engineering firm delivered the asset inventory for a 50 MW solar plant in the countryside near Seville: trackers, string boxes, inverters, transformer stations, the perimeter fence in sections, the cameras, the pits and the drainage network. Four months of fieldwork, every element with its geometry, its record and its photograph, loaded into the tool the plant operator had contracted for maintenance.
This autumn the operator is switching O&M contractor, and the new one brings its own software. It asks for the inventory. What comes out of the old tool is one spreadsheet per asset type, with coordinates in a text column, no fence or drainage because they were lines rather than points, and a folder of 30,000 photographs with sequential names that no longer say which asset they belong to. The tracker codes were renumbered after a storm a year ago, and the work order history is in no file.
The client's operations manager does not call the software vendor. He calls the engineering firm that built the inventory, because its name is on the deliverable. The firm can redo part of the work for free or explain that the problem is not theirs, knowing the client will not tell the difference.
The inventory belongs to the client, but the problem comes back to the firm
A firm that delivers an inventory inside a platform delivers two things: the data and the way it is stored. The first it controls and invoices. The second it often decides without noticing, by accepting the client's tool or recommending one without asking how you get out of it. If the data can only be read inside that tool, the client does not own its inventory in practice, whatever the contract says.
With outdoor assets the risk is higher than in a building. An inventory of a solar plant, a business park or a private irrigation network is mostly geometry: positions with no postal address, linear routes, plot boundaries, fence sections. An export that reduces this to latitude and longitude columns loses what took longest to survey. And photographs, the only evidence of the condition of an asset nobody visits every week, are worth little if nobody knows which element they belong to.
For the firm this is a matter of margin, not principle: an inventory rebuilt three years later is unbilled rework, and a client who has lived through it will distrust the next platform project.
What to require from the tool
Six technical conditions separate a portable inventory from one tied to the vendor. First, open formats: data that comes out in files any GIS or spreadsheet can open without vendor licences or converters, with geometry in a standard format and a declared reference system.
Second, a complete export, not just the asset register. The value of a living inventory also lies in what has been done to it: work orders, issues, photographs and documents. Third, the client must be able to run that export whenever it wants, without opening a support ticket or paying for a migration service.
Fourth, stable identifiers. Each asset needs an identifier that does not change when a row is renumbered, an inverter is replaced or the hierarchy is reorganised. Without it, matching the inventory against the history or a later survey becomes manual work.
Fifth, photographs with their fingerprint: each image linked to the asset and to the job that produced it, with a hash that proves the delivered file is the one taken in the field. When a plant has suffered cable theft, as at the Seville sites where the Guardia Civil recovered two tonnes of stolen copper in July 2026 according to El Debate, a dated, intact photograph is the evidence of the prior condition. Sixth, documentation of the data model: what each file contains, what each field means, how assets, orders and attachments relate to each other.
What the contract should say
A tool can allow all of the above without the contract guaranteeing it. Four clauses are worth checking in writing. That the data belongs to the client and the vendor only processes it on the client's behalf. That the complete export is included in the subscription and does not depend on a higher plan. That there is a defined exit period when the contract ends, with access to view and download data throughout. And that, if the vendor ever stopped providing the service, there would be enough notice to migrate without rushing.
These belong in the contract or an annex, not on a web page. A two-week exit period for a portfolio with tens of thousands of photographs is not a real period. One month's notice forces a migration under the worst possible conditions.
The exit test before signing
The reliable check is to export a demo environment or a small pilot and open it with the tools the firm already uses. Load the geometries into QGIS and see whether lines are still lines. Open the tables in a spreadsheet and check that orders link to assets through an identifier that is not the visible code. Pick ten photographs at random and confirm you can tell which asset and job they belong to. If the test takes more than a morning, the real day will be worse.
What Maptainer brings here is that the complete export is always included: assets, orders, issues and photographs, with a manifest describing each file, the SHA-256 hash of every photograph and document, and a spreadsheet folder with one CSV per entity. Geometries always come out as GeoJSON in EPSG:4326, there are 90 days of access to download everything when the contract ends and, if the service were ever discontinued, customers would be told six months in advance. The way in is just as open: inventories are imported from GeoPackage, Shapefile, GeoJSON, DXF or CSV, and the public API documentation can be read without a key before signing.
What to decide in the next proposal
Three decisions are enough to avoid the call in the opening scene. First, include a deliverable portability section in the technical proposal: which formats the inventory is delivered in, which reference system, how assets are identified and how photographs are linked, Second, run the exit test before recommending or accepting a platform, and keep the result as part of the project documentation. Third, hand the client, together with the inventory, an exported copy in open formats with its documentation, dated at project close.
None of them costs many hours if decided at the start, and all three make data ownership verifiable: what was delivered still belongs to the client the day it changes vendor, and whoever surveyed it will not have to do it again.