What is enterprise data portability and why is it not the GDPR right?

Data portability, in the sense that matters to a business, is the real capacity to extract your own data from a system, an ERP, a SaaS platform, and bring it into a format another system can actually use, not just read. It is not the abstract right written into a contract or promised on a marketing page: it is a technical property you verify with a practical test, a real export followed by an attempted reimport, before signing or renewing, not after. It has to be kept separate from GDPR data portability, which is the data subject's right to receive their own personal data in a structured format and transfer it to another controller: that concerns the individual and their personal data, this concerns the business and its entire information asset, schemas, history, relationships, attachments, configuration. A system can be perfectly GDPR-compliant on personal data export and remain, at the same time, a total trap for the operational data of the company using it.

See also: Data migration · Moving data from one system or platform to another without breaking what depends on it: the real risk is organizational, not technical.

What separates a real export from a fake one

Many vendors offer an "export" button that produces a file, and stop there: the problem is what that file contains. A usable export requires open formats, not proprietary dumps readable only by the software that generated them, and full history, not just the current state of records but every version and change that produced them, often essential for audits or reconstructions. It requires relationships and keys between tables, without which an export is a pile of disconnected rows; it requires attachments and documents, contracts, invoices, images, which stay in the source system more often than expected; and it requires, the most overlooked point, business logic, calculation rules, approval workflows, automations, which is almost never exportable in any form and has to be rebuilt by hand in the destination system. This is also the territory the European Data Act operates on, imposing concrete switching and exportable-format obligations on cloud providers: a useful regulatory framework, but one that does not replace direct technical verification.

A concrete enterprise example

A mid-size manufacturing company decides to leave its ERP after ten years for a cloud platform. The outgoing vendor's contract states, on paper, "full data export on request." In practice the export produces one CSV per table, without the relationships between order, customer and invoice, without the history of price changes and without a single row of the discount rules configured over the years. The project, planned as a few weeks' migration, turns into a months-long reconstruction because nobody had ever tested the export before signing the new contract: the promised portability existed only in the clause, not in the system.

Why it matters for decision makers

Portability has to be verified before signing, not after, with a real export test on a data subset and an attempted reimport elsewhere, not by reading the contract clause. Whoever signs a SaaS contract or an ERP deal without ever having seen a real export is buying a promise, not a capability, and it is the same risk behind a failed cloud repatriation: a vendor that does not let your data go easily is the same one holding all the negotiating leverage at renewal time. Verifying it upfront is a data contract clause to negotiate, not a technical detail to leave to IT on cutover day.

This entry is informational and does not constitute legal advice: for regulatory obligations on switching and export, involve your legal counsel or DPO.