Data Portability Standards: Owning Your Business Data

Data portability standards are the set of legal frameworks, technical specifications, and industry norms that govern your ability to move your data from one system to another. The short answer to whether they work: not well enough. The longer answer is a story about power, incentive structures, and what it means to actually own something in the age of SaaS.

The Illusion of Ownership#

There's a quiet lie embedded in every SaaS contract you've ever signed. You "own your data." It says so in the terms. The vendor makes it sound almost generous — of course you own it, they're just storing it for you.

But ownership without portability is not ownership. It's tenancy.

If I own a house, I can take the furniture when I leave. If I own my business data, I should be able to take it — completely, cleanly, in a format I can use — when I leave a vendor. In practice, this almost never happens smoothly. Exports are incomplete. Formats are proprietary. Relationships between records are severed. The data you receive back bears only a passing resemblance to the data you built.

This is not an accident. Friction in data portability is a retention mechanism. The harder it is to leave, the longer you stay. Every SaaS company in the world understands this at some level, even if they never say it out loud.

What the Law Actually Says#

Data portability has become a genuine regulatory priority over the last decade, and the landscape is now complex enough to warrant a quick map.

GDPR Article 20 (EU) grants individuals the right to receive their personal data in a "structured, commonly used and machine-readable format" and to transmit it to another controller. This is powerful for consumer data — it's why you can download your Google Takeout archive or your Facebook data. For business data (B2B CRM records about your customers), the picture is murkier. The regulation focuses on personal data about natural persons, which means your customer contact records qualify, but the aggregate sales pipeline data and custom objects may not be covered by portability provisions.

DMA Article 6(9) (EU Digital Markets Act) goes further, requiring "gatekeepers" (large platforms) to provide real-time data portability via open APIs. This has practical teeth for the Googles and Metas of the world, but most SMB SaaS vendors don't qualify as gatekeepers.

CCPA/CPRA (California) gives consumers rights similar to GDPR for personal data of California residents. Again, covers personal data, not necessarily the business logic and relational structure your team built.

Sector-specific rules exist in finance (Open Banking), healthcare (HIPAA data portability requirements), and increasingly in telecoms. But enterprise software for sales and marketing has largely escaped meaningful regulation.

The result: you have strong legal rights to your customers' personal information, weaker rights to the business context you've built around it, and almost no rights to the workflow configurations, AI model fine-tuning, and institutional knowledge your team embedded in the system.

The Technical Standards Gap#

Even where legal rights exist, the technical standards for exercising them are poorly developed.

The CSV export is the lowest common denominator. Every SaaS tool offers it. It's also the most lossy format imaginable — flat, untyped, relationship-free. Exporting a CRM to CSV is like exporting a relational database to a spreadsheet. You get the data cells, you lose everything else.

JSON and API access are better. Many vendors offer API access to your data, and tools like DenchClaw are built around structured, queryable formats. But API access requires engineering resources to use, rate limits cap how fast you can extract, and API access can be revoked when a subscription lapses.

The IETF's "jCard" and vCard formats exist for contact portability but cover only a fraction of CRM data. Deal pipelines, activity histories, custom fields, and AI-generated insights have no standard representation.

Open Data Protocol (OData) has seen some adoption in enterprise software (Microsoft Dynamics uses it) but hasn't achieved broad cross-vendor adoption.

The honest assessment: the standards ecosystem is fragmented, underpowered, and years behind the complexity of the data it's meant to protect.

Why Local-First Changes the Equation Entirely#

The debate over data portability standards presupposes a world where your data lives on someone else's server. Local-first software challenges that presupposition.

When your data is stored in DuckDB on your own machine — as it is with DenchClaw — data portability stops being a rights issue and becomes a file copy. You don't need to invoke GDPR Article 20. You don't need to submit a data export request and wait 30 days. You don't need to hope the vendor's export function actually works. You open a file manager, copy the .duckdb file, and your data is somewhere else.

This is a category shift. The question changes from "how do I get my data out?" to "how do I use my data directly?"

DuckDB is an open-source format. It's documented. It's readable with free tools. It will be readable in 20 years. If DenchClaw as a company ever ceased to exist, your data would still be accessible with any DuckDB-compatible client. This is not a feature — it's an architectural guarantee.

What Good Data Portability Actually Looks Like#

Whether you're evaluating a new vendor, auditing an existing one, or building internal policy, here's the standard to hold software to:

1. Complete exports, not selective ones All objects. All fields, including custom ones. All relationship links preserved. Timestamps. Audit logs. Not just the "primary" records.

2. Open formats CSV for basic interoperability is fine as a floor, not a ceiling. JSON with schema documentation, SQL dumps, or open binary formats like DuckDB are much better.

3. No time pressure Exports should be available after subscription cancellation for a reasonable period (90 days minimum). Your data shouldn't disappear because you forgot to export before your trial ended.

4. Machine-readable schema documentation A human-readable export is useful. A machine-readable one is necessary. What does this field mean? What are the possible values? What does this ID reference?

5. Relational integrity If contact 12345 is linked to deal 67890, that link should survive export and import. This is table stakes and most vendors fail it.

6. Programmatic access An API that's actually usable for bulk extraction, with rate limits appropriate for migration (not just operational queries), documented error handling, and no artificial throttling.

Building Your Own Portability Posture#

Waiting for vendors or regulators to solve data portability is a poor strategy. Here's what you can do now:

Audit your current vendor exposure. List every SaaS tool that contains data you'd need to recover if they went offline tomorrow. For each, answer: Can you export everything? In what format? How long would re-import take?

Establish a regular export cadence. Treat data exports like backups. Weekly automated exports of your most critical systems, stored in your own cloud storage or on-premises. Most enterprise CRMs offer scheduled exports or API access for this.

Prefer open-source when the alternative is comparable. Open-source software cannot hold your data hostage. The code is public, the formats are documented, and you can always fork. This is especially true for tools at the center of your operations — CRM, customer data platform, analytics.

Negotiate portability into contracts. For enterprise agreements, data portability should be a named requirement, not an assumption. Define format requirements, timelines, and transition assistance in the contract, not after you've decided to leave.

Consider local-first architecture for critical systems. If the data in a system is truly mission-critical — customer relationships, pipeline, transaction history — the safest thing is to store it locally. The DenchClaw setup guide walks through this in practical detail.

Frequently Asked Questions#

Does GDPR guarantee I can get my CRM data back? GDPR Article 20 provides portability rights for personal data processed with consent or on a contractual basis. This covers your customer contact data. It may not cover custom business logic, AI training data, or aggregate pipeline data. The right also applies to individuals (your customers can request their data), not just your company.

What format should I request when exporting data? At minimum, request CSV with all fields and all relationship IDs preserved. Better: request JSON with schema documentation. Best: ask whether the vendor supports open database formats or provides a full SQL dump.

How does local-first software address data portability? Local-first tools like DenchClaw store your data in open formats on your own hardware. There's nothing to "request" — the file is yours and always has been. Portability is a property of the architecture, not a feature the vendor grants you.

What should I do if a vendor refuses to provide a complete export? In the EU, this may be a GDPR violation you can report to a supervisory authority. Outside the EU, your leverage is contractual. For future contracts, include data portability requirements explicitly. For existing situations, escalate to a legal review if the data is business-critical.

Is DuckDB a stable long-term format for storing business data? DuckDB is actively maintained, open-source (MIT license), and has seen strong adoption in the analytics community. Its file format is documented and stable. Tools like DenchClaw build on it precisely because it provides long-term readability without vendor dependency.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →