Skip to content
Notifications
Clear all

Guide: How to read the fine print on data export and portability.

1 Posts
1 Users
0 Reactions
2 Views
(@davidr)
Estimable Member
Joined: 1 week ago
Posts: 116
Topic starter   [#5939]

I've reviewed over two dozen CRM contracts for clients migrating off-platform, and the single most consistent point of catastrophic failure isn't the per-seat cost—it's the assumption that you can get your data out in a usable form when you need to. The marketing materials talk a good game about "ownership," but the implementation details in the service appendix will gut you if you're not prepared. This isn't about backing up contacts; it's about preserving the relational integrity, audit history, and metadata of your commercial operations.

The critical clauses are never under "Termination." Look for these sections instead:
* **Data Export & Portability:** Defines formats, frequency, and volume limits.
* **API Usage & Throttling:** Your programmatic access for extraction will be governed here.
* **Professional Services:** Where they list the exorbitant fees for "custom" export assistance.
* **Data Retention Post-Termination:** The shockingly short window they'll hold your data after contract end.

You will see language like "standard export functionality" or "commercially reasonable efforts." These are red flags. Demand specificity. A "standard CSV export" is useless if it flattens related records into a single, unjoinable file. Your 10-year deal history is meaningless without the associated opportunity stages, custom object links, and user audit trails.

Here is a concrete example from a recent Salesforce Health Cloud migration. The client assumed their data was portable. The contract allowed for "full data export via API." The reality was a series of gotchas:
1. The API concurrent call limit was throttled to 2,000 requests per hour. Extracting their 4TB of data would have taken 47 days of continuous, perfect operation.
2. The `DataExport` API object does not include all custom field history tracking data. That requires a separate, slower `FieldHistoryArchive` object.
3. The relational integrity between `Account`, `Contact`, and custom `Patient__c` objects was not maintained in the bulk data dump. We had to reconstruct it using foreign keys, which were not consistently populated.

The solution was to negotiate these terms *before* signing the initial agreement. We added an exhibit that stipulated:
* A biannual, full-fidelity export to a client-owned S3 bucket, delivered as a compressed set of normalized Parquet files.
* A defined schema manifest (like a protobuf or Avro schema) for all custom objects.
* A post-termination "data bridge" period of 90 days with full API access at non-throttled rates for extraction.

Without this, your migration cost can easily double, and you risk losing historical data that underpins your analytics. The vendors bank on your inertia. Your leverage is highest during the initial sale and at renewal when they fear churn. Use it to get these terms in writing.

—davidr


—davidr


   
Quote