Most dealer principals only think about dealership data portability at the worst possible moment: the day they decide to switch a core system. By then the leverage is gone, the renewal is months away, and the vendor holds the keys to years of customer records, vehicle history, deal files and accounting links. The question stops being "can we leave" and becomes "how much of our own data can we actually take with us, and in what shape."
This article is about the right and the method, not the trap. The lock-in problem (proprietary schemas, walled gardens, contracts designed to make leaving expensive) is real, but it is a separate subject. Here we focus on what you are entitled to under EU law, what a clean export actually looks like in practice, and the contract language and technical checks that turn a vague right into data you can load into the next system on day one.
What data portability actually means for a dealership
Data portability is the ability to obtain a copy of the data held about your business and your customers, in a structured and machine-readable form, and to move it to another provider or hold it yourself. It is distinct from simply viewing a report or printing a PDF. A report is a snapshot the vendor chooses to show you. Portability is the underlying records in a form another system can ingest.
For a dealership this spans several overlapping data sets, and they are rarely all stored in the same place:
- Customer and prospect records (contact details, consent flags, communication history)
- Vehicle and stock records (specification, history, costs, reconditioning, photos)
- Deal and sales files (offers, finance applications, trade-in appraisals, signed documents)
- Service and aftersales history where the system covers it
- Financial postings and the links between invoices, deals and the ledger
The legal right and the practical export are two different things. You can have a clear entitlement to your data and still receive a single flat spreadsheet that has lost every relationship between a customer, the cars they bought and the money that changed hands. Getting portability right means insisting on both: the right in the contract, and the structure in the file.
Your rights under the Data Act and EU law
Two strands of EU law sit behind dealership data. The General Data Protection Regulation gives individuals a right to portability of their personal data, which matters for customer records. Separately, the EU Data Act addresses data generated by connected products and related services and is designed to reduce lock-in and make switching between data-processing providers more practical. We cover the broader picture in the EU Data Act and what it means for the automotive industry.
The practical effect for a dealer is a shift in default assumptions. The direction of travel in EU policy is that you should be able to leave a provider without being held hostage by your own operational history, that switching should be supported rather than obstructed, and that data should be made available in commonly used, machine-readable formats. The deeper ownership question of who holds rights over vehicle and customer data is worth understanding in its own right, and we go into it in who owns vehicle data in Europe.
What a complete export looks like
The single most common failure in a dealership migration is an export that is technically delivered but practically useless. The vendor ticks the box, you receive the files, and only when you try to load them do you discover what is missing.
A genuinely complete export has three properties: it covers all the entities you depend on, it preserves the relationships between them, and it includes the metadata that gives records meaning.
| Layer | What to demand | Common gap |
|---|---|---|
| Entities | Customers, vehicles, deals, documents, financial postings | Only the "primary" table exported, related objects dropped |
| Relationships | Keys linking a customer to deals, vehicles and invoices | Flat tables with no foreign keys, relationships lost |
| Documents | Signed contracts, appraisals, photos as files | Links to documents exported, but not the files themselves |
| Metadata | Timestamps, user IDs, status history, audit trail | Current state only, no history of how it got there |
| Codes and lookups | The meaning behind status codes and category IDs | Raw codes with no key to decode them |
If you receive customer and vehicle records but the deal that ties a specific buyer to a specific car has been flattened away, you have lost the part that took years to accumulate. The relationships are frequently the most valuable and the most fragile part of the data, and they are the first thing a careless export destroys. This is also why vehicle data silos within a dealership make exits harder: if the data was never joined up internally, no single export will join it up on the way out.
Formats: portable versus merely delivered
A file you cannot open without the vendor's software is not portable in any meaningful sense. The format is what separates data you own from data you are merely allowed to look at.
Open, documented formats (CSV with a published schema, JSON, Parquet, or open table formats) can be read by many tools and loaded into any modern system. Proprietary database dumps, encrypted archives, or undocumented binary blobs cannot. We make the broader case for open, owned formats in open formats and owned data with the automotive Iceberg pattern.
A practical test is simple: can a competent third party, with no relationship to your old vendor, open the export and understand it from a data dictionary alone. If the answer is no, the data is not portable yet, regardless of what the contract says. Below is the kind of self-describing structure that makes an export immediately usable, where every record carries its own keys and meaning.
{
"vehicle": {
"id": "veh_10293",
"vin": "WVWZZZ1KZAW000001",
"stock_date": "2026-04-12",
"cost_total": 18450.00,
"linked_deal_id": "deal_55821",
"linked_customer_id": "cust_30021"
}
}The point is not the exact format. It is that each record carries the keys it needs to be reconnected to everything else, in a structure any system can parse.
How to plan the export before you switch
The mechanics of portability are easier when they sit inside a wider switching plan rather than a panic at the end of a contract. We walk through the operational side of a system change in how to switch your DMS without downtime; here is the data-specific sequence.
- Inventory what exists. List every data set the current system holds and which ones you actually depend on. You cannot demand a complete export of data you have not mapped.
- Request a sample export early. Ask for a small, real extract before you commit to anything, so you can inspect the format and completeness while you still have leverage.
- Validate the relationships. Open the sample and confirm that customers, vehicles and deals can be reconnected using the keys provided.
- Reconcile counts. Match record counts and financial totals against your live system so you can prove nothing was silently dropped.
- Plan the load. Confirm the receiving system can ingest the format, and budget time for cleaning and mapping rather than assuming a clean lift-and-shift.
The contract clauses that make it real
The difference between a smooth exit and a painful one is usually written down years earlier. A portability and exit clause is far cheaper to negotiate at signing or renewal than to litigate at termination. The essentials to insist on:
- A defined export scope listing the entities and relationships covered, not a vague reference to "your data".
- A named, open format with a published data dictionary, so the export is usable without the vendor's tools.
- A maximum delivery time after a request, measured in days, not "reasonable efforts".
- A capped or zero export fee, so the cost of leaving is known in advance and cannot be used as leverage.
- A post-termination access window during which you can still request data after the relationship ends.
- A deletion and certification step, so you know your data is removed from the old system once the migration is verified.
These clauses do not assume bad faith. They simply make the right to your own data concrete and time-bound rather than something you have to negotiate from a position of weakness on the way out.
Where VehIQ fits
VehIQ is being built on the assumption that a dealer should never have to fight to leave. The design principle is that the data a dealership generates is owned by the dealership and held in open, documented formats the customer can read and export without permission, with field-level lineage so every value can be traced to its source. That same lineage that makes valuations explainable also makes exports verifiable, because you can see exactly where each record came from.
VehIQ is pre-seed and being built in the open, so this is a description of how the platform is designed to behave rather than a deployed track record. The wider thinking on European data sovereignty as a structural advantage is set out in EU data sovereignty as a competitive advantage. The principle is simple: portability should be a property of the system from the first day, not a clause you only discover the value of on the last.