CRM data portability: an export is the start of an exit plan.

What this note can establish

An exit decision needs more than the presence of an export command. This note uses only the three official documentation pages listed below, with a retrieval date of 2026-11-01. Vendor-documented means the supplier describes a capability within that page’s scope; it is not independent verification. We have not performed hands-on CRM tests. The checklist is an editorial proposal for a buyer’s own trial, not evidence of results, a ranking or an endorsement. Documentation does not prove completeness for your account or destination.

Separate records from the context that makes them useful

Treat record export and operational reconstruction as separate acceptance questions. A row containing a contact’s current properties may answer a different question from a timeline explaining how a deal changed. Relationships connect records; activity history, attachments and ownership can carry additional context. For your evaluation, list which of these your team needs after departure. An exported association is not, by itself, evidence that a receiving system can reconstruct the relationship. These are proposed evaluation distinctions, not claims about missing features in any of the three products.

HubSpot: current properties and associations

Vendor-documented — HubSpot’s “Export your records” describes exporting current property values and associations and requires Export permissions. This supports asking which current fields and associations your exit scenario needs and which role can initiate the export. It does not establish a complete activity-history export. Keep current values and historical changes as separate requirements in your brief. Whether your selected configuration and destination preserve the context you need remains unknown here; resolve that through a scoped trial rather than treating the documentation as a result.

Salesforce: identify the relevant service first

Vendor-documented — “Data Export and Portability Across Salesforce” is a starting point for locating guidance for the relevant Salesforce service. This note does not infer export coverage, permissions, file formats or retention periods for a particular configuration from that starting point. First record the service and configuration you intend to evaluate. Then ask the supplier which procedure applies and what evidence would answer your requirements. Until that narrower evidence is reviewed, mark those details unknown. A navigation page is not proof that a chosen workflow can be reconstructed elsewhere.

Zoho CRM: module exports and file formats

Vendor-documented — Zoho CRM’s “Export CRM Data” describes module exports in CSV and XLSX. That establishes documented format options for module exports, not inclusion of every record, relationship or attachment. For a buyer, the next question is how the required modules and their identifiers would be mapped in the receiving workflow. The availability of a spreadsheet format does not answer that mapping question. This note leaves configuration-specific coverage and reconstruction unknown; it does not infer either success or failure from the format names.

Evaluate access and readability separately

Permission to export and ability to use the resulting file are different checks. HubSpot’s Export permission requirement and Zoho CRM’s CSV/XLSX options are the narrow documented facts retained here; no equivalent permission or format claim is made for the other vendors where this evidence does not establish it. In a proposed trial, record the role used, the export procedure and the chosen format. Inspect identifiers, field meanings, date interpretation and relationships in the destination. A file that opens is only one observation, not proof that the intended workflow survives.

Keep retention and download windows explicitly unknown

This note establishes no retention window for any of the three vendors. Export download availability, source-data retention and access after account closure are distinct questions, and their applicable periods remain unknown in this evidence set. Do not convert a download deadline into a promise about how long source data remains available. Before planning a departure, request applicable written terms and a procedure for retrieving the required data while access is available. Any timing assumption should remain an unresolved dependency until supported for the chosen service and configuration.

A practical checklist for a scoped trial

Use synthetic records and a deliberately small scenario that represents your required workflow. Agree on acceptance criteria before exporting, and keep the trial’s scope visible in the decision record. These steps are proposed buyer checks; this publication has not executed them or observed vendor results.

• Define the exit scope: required record types, fields, relationships, activity history and attachments. Mark each as required, optional or outside the trial.
• Record the service, configuration, date, export procedure and authorized role. Confirm permissions without sharing credentials or private customer data.
• Create synthetic linked records with known identifiers and expected values. Write down the expected relationships and context before exporting.
• Export the bounded sample and inventory the files, formats and included fields. Compare the sample against your written expectations and record omissions or ambiguities.
• Inspect the receiving workflow: can identifiers, dates, ownership and required relationships be interpreted or reconstructed? Record manual mapping separately from preserved data.
• Check required history and attachments separately from current properties. Do not mark them covered merely because the record itself appears in a file.
• Ask about export download deadlines, source retention and post-closure access separately. Keep unsupported periods unknown and document who must resolve them.
• Record the result as supported, unresolved or outside scope for each requirement. Keep sample observations separate from vendor documentation; neither proves universal completeness.

Make exit readiness a bounded decision

For each requirement, retain the source URL and retrieval date, the relevant documented statement, the proposed or observed trial evidence, and the remaining uncertainty. An unresolved essential relationship may justify another trial before commitment; a requirement outside the business workflow may not. Assign an owner to each unresolved item and define what evidence would close it. Decide against your team’s exit requirements, without extrapolating a small sample to all data or declaring a universal winner. The related CRM guide supplies the broader evaluation framework.