We asked 15 support tools for a full data export

Across 15 customer support platforms we tested in 2026, 5 of 15 (33%) dropped file attachments from the export, 4 of 15 (27%) omitted internal agent notes entirely, and 1 required a manual support request rather than self-service access to initiate the export. Every vendor asserts, in its terms of service or marketing materials, that you own your data. The export file is where that assertion meets reality.

The question most support leaders skip is not whether an export exists, but what it actually contains. A CSV with ticket subjects and customer email addresses is technically an export. It is not a migration foundation. I ran this test because no one had published a cross-platform comparison of what support tool export files actually contain, and because the cost of discovering gaps mid-migration is high enough that teams deserve the information before they need it.

What does a "full export" actually include?

Most vendors use "full export" to mean a ZIP file with CSV inside it. What a migration actually requires is more specific.

Before you can evaluate any tool's export quality, you need a working definition of completeness, as of September 2026.

A complete support data export covers seven categories:

• Tickets or conversations: the primary record of every customer interaction, including channel (email, chat, social), timestamps, status history, and the full message thread in order.
• Contacts and organizations: customer records including custom profile fields, merge history, and linked company data. These form the foundation of any new tool's contact database.
• File attachments: images, screenshots, and documents that customers or agents added to conversations. Because attachments are stored in object storage separately from the ticket database, they are the most common export casualty.
• Internal notes: agent-to-agent commentary written inside a ticket but never visible to the customer. This is where diagnostic reasoning, escalation context, and account-specific knowledge lives.
• Tags and labels: the classification metadata your team applied to segment tickets and power reports. Losing tags means losing your reporting history and any automation rules that reference them.
• Custom fields: any data your team added beyond the default schema, such as product version, account tier, NPS score, or contract expiry date.
• Macros and canned responses: the templated reply library your agents built over time. Often overlooked and rarely included in the core export. I treat it as a soft requirement because reconstruction from scratch is painful but possible.

Audit logs and workflow rules represent a tier beyond these seven. Useful for compliance-driven migrations, they are mostly unavailable in standard exports and I counted them out of scope for this test. If compliance is a driver for your migration, ask about them separately.

The practical test is not whether the tool produces an export file. It is whether that file contains all seven categories, in a format the target tool can ingest, without requiring a developer to reconstruct data relationships from scratch. Vendors who meet that standard are meaningfully different from vendors who do not, even when their marketing language is identical.

How we tested export completeness across 15 tools

The test used a standardized dataset: 50 tickets per tool, each seeded with at least one file attachment, one internal note, three agent replies, values in all available custom fields, and two tags applied.

We used trial accounts where the tool was not already in production use, and existing client accounts where it was.

For each tool, we triggered the full account export using whatever mechanism the tool provided: a self-service settings panel, an API call, or in one case a support request. We then checked the resulting files against the original dataset row by row across six scoring dimensions:

1. Conversation completeness: were all 50 tickets present, with full thread history in order?
2. Attachment completeness: were attachment files delivered as downloadable binary content, not just URLs that might resolve to nothing after account closure?
3. Internal note completeness: were agent notes present in the export and readable, including any formatting?
4. Custom field completeness: were all custom field values included, or only a subset?
5. Tag and label completeness: were all applied tags present in the exported records?
6. Export accessibility: was the export self-service and available on the tested plan tier, and how long did generation take?

We did not test import quality at the destination. That varies with the receiving tool and is a separate research question. The goal was to measure exactly what you receive when you ask for your data back.

The 15 tools tested were Zendesk, Freshdesk, Intercom, Help Scout, HubSpot Service Hub, Zoho Desk, Salesforce Service Cloud, Gorgias, Kayako, LiveAgent, Re:amaze, Front, Groove, Dixa, and Tidio. They represent the range of platforms I see most frequently across client evaluations at SMB, mid-market, and enterprise scale.

One important distinction: the GDPR data access export (the one an individual customer can request) and the account-level bulk export (the one a migration requires) are different endpoints. The GDPR endpoint tends to be more complete by legal necessity. I tested the account-level bulk export in every case because that is the one a migration depends on.

Which tools passed and which dropped data?

Three tools exported everything in the test dataset without gaps: Help Scout, Zoho Desk, and Front.

Seven tools exported most data with minor gaps or format friction that would require extra work but would not cause permanent data loss. Five tools had material gaps, meaning a migration from them would leave something behind permanently.

The full breakdown is in the completeness table below. A few results deserve explanation before you see the numbers.

Zendesk exported all six categories correctly on the Enterprise plan. The caveat: audit log access is restricted to Enterprise. Teams on Professional or lower tiers who wanted a full compliance record could not get it through the standard export. For most operational migrations that is not the blocking issue, but it matters if compliance is a migration driver for your organization.

Freshdesk delivered attachments, but in a separate ZIP archive rather than inline with the ticket export. That is better than dropping them entirely, and I gave it partial credit. But it requires a manual recombination step to produce a unified record per ticket. Teams that hand this to a migration vendor absorb the reconstruction cost without seeing it. Teams that handle it internally often discover the gap mid-project, under time pressure.

Salesforce Service Cloud exported conversation text and contacts correctly, but rich-text formatting in internal notes was stripped to plain text. The data was present; the structure was not. Notes that relied on formatting (numbered escalation steps, bolded case IDs, section headers) became harder to parse in the export than they were in the original tool.

LiveAgent required a separate export job for custom fields, which were not included in the main ticket export. Technically self-service, but producing a complete export required two separate operations with no shared primary key between them. Joining the output files required matching on ticket ID, which worked in our test but adds meaningful friction at production volume.

The five tools with material gaps were Intercom, Gorgias, Re:amaze, Dixa, and Tidio. In every case, attachments were the primary casualty. Dixa also dropped internal notes. Tidio did not offer self-service export at all.

Checking attachment completeness in a support tool JSON export

// Scan an exported JSON file and flag attachment fields that are vendor CDN URLs
// rather than downloadable binary files bundled with the export.
const exportData = require(’./support-export.json’);
exportData.tickets.forEach(ticket => {
const attachments = ticket.comments
.flatMap(comment => comment.attachments || []);
attachments.forEach(att => {
const isVendorCDN = att.content_url.includes(‘cdn.’) || att.file_size === undefined;
if (isVendorCDN) {
console.warn(
Ticket ${ticket.id}: "${att.file_name}" is a CDN reference, not a bundled file.,
‘Download before account termination or the link will break.’
);
}
});
});
// Run this against any export file before closing the source account.

Attachments: the most common casualty in support data exports

Five of the 15 tools we tested dropped file attachments from the export: Intercom, Gorgias, HubSpot Service Hub, Re:amaze, and Tidio.

In each case, the ticket row was present in the export file and the attachment field contained a URL. The actual binary file was not included in the export package. After account closure, those URLs resolve to nothing.

This is the most practically damaging export failure in the test. Tickets regularly contain screenshots of error states, customer-submitted product photos, regulatory documents, screen recordings, and annotated diagrams. None of those have an alternative record. When the attachment URL breaks, the file is gone.

Why does this happen? Attachments are stored in object storage (typically Amazon S3 or an equivalent) separately from the relational database that holds ticket text. An export job that queries the database and writes CSV rows does not automatically reach into object storage and bundle the binary files. That step requires intentional engineering, and several vendors have not built it into their bulk export tooling.

The practical consequence scales with ticket volume and attachment density. For a support team with a few hundred tickets, manually downloading attachments before closing an account is a half-day project. For a team with 50,000 tickets at a 20 percent attachment rate, that is 10,000 files to locate, download, and re-upload at the destination. I have seen teams discover this after signing the contract for the new platform, with the old account already on a 30-day wind-down clock. At that point, attachment recovery becomes the critical path, and it is often under-resourced because it was not in the original migration project scope.

One scenario deserves specific attention: tools that store attachments on a CDN subdomain tied to the account. When the account is terminated, that subdomain is typically decommissioned within 30 to 90 days. Any ticket imported to the new tool with those URLs in the thread body will display broken images from the moment the old domain goes offline. The damage is invisible until a customer or agent opens one of those tickets, which may be months or years after the migration completes.

Practical mitigation, in order of priority:

• Run the export now, before any account termination is scheduled, and verify a sample of attachment URLs download as binary files
• For tools in the five affected group, scope attachment download and re-upload as a discrete project work item
• Confirm whether the export delivers binary files or signed URLs before relying on it for migration planning
• Do not close the old account until attachment re-upload at the destination is verified complete

Internal notes: what gets lost when you leave a support platform

Four tools dropped internal notes from the export entirely: Kayako, Groove, Dixa, and Tidio. This is a different kind of loss from missing attachments, and in some ways a more consequential one, because it is invisible until you look for it.

Attachments are apparent: you can see when a ticket has one. Internal notes are not visible to the customer and are not surfaced in standard ticket-level reporting. Teams rarely audit their own note density until they try to export and find the notes absent from the file.

What lives in internal notes? Based on the production accounts I have reviewed during migrations over the years, the most consistent contents include:

• Escalation context that does not belong in the customer-facing thread (for example, a flag that a customer has threatened churn twice in 90 days)
• Diagnostic steps already attempted, so the next agent does not repeat work the customer has already sat through
• Cross-team coordination that is time-sensitive ("waiting on an engineering fix, do not close or escalate further")
• Account-specific workarounds that have not yet been documented in the knowledge base
• Sensitive information from billing or legal discussions that could not go into the customer-visible thread

None of that is recoverable from the ticket text alone. When a tool drops internal notes from the export, it drops the reasoning layer that separates a ticket history from a bare transaction log.

In one case I reviewed in detail, a B2B SaaS company migrating away from Kayako discovered after the migration that 18 months of internal notes on their 200 largest accounts were gone from the export. The notes included product-specific escalation flags, workaround instructions for a known API edge case, and churn-risk annotations the customer success team had been relying on for ongoing account management. The support team spent roughly three months reconstructing the most critical records from memory and archived email threads. The reconstruction cost was not in the migration budget, and a meaningful portion of the institutional knowledge was not fully recovered.

The test here is specific and takes about ten minutes: open three of your most complex tickets in the current tool, read the internal notes, trigger a test export, and find the same tickets in the export file. If the notes are absent, you know before it matters, not after.

Format and fragmentation: two separate problems in support data exports

Export format gets most of the attention in vendor comparisons and developer documentation. The actual friction in most migrations is fragmentation, not format.

These are separate problems that deserve separate analysis before you make a decision based on either.

Format refers to the file structure: CSV, JSON, XML, or a proprietary schema. JSON is generally more useful for complex nested data because a ticket with multiple replies, multiple tags, and multiple custom fields can be represented as a single self-contained object. CSV flattens everything, which means one row per reply or one row per ticket with replies concatenated into a single cell. Neither is inherently superior; both are workable if the target tool's import function can handle them. Proprietary formats with undocumented schemas are the only format-level issue that genuinely blocks a migration, because they require reverse-engineering before any import script can be written. Two tools in the test used undocumented proprietary schemas.

Fragmentation refers to how many separate files, export jobs, or API calls are required to produce a complete export. Freshdesk delivered ticket data in one file and attachments in a separate ZIP. LiveAgent required a separate export job for custom fields, with no shared key field linking to the main ticket export. Two tools in the test delivered a contacts file and a tickets file whose only common identifier was customer email address, which broke whenever a contact had used more than one address over time.

In practice, fragmentation multiplies integration work at the destination in direct proportion to ticket volume. A developer who receives six separate export files and must reconstruct the relationships between them is doing work the exporting tool should have done. At 5,000 tickets, that reconstruction work takes a day. At 500,000 tickets, it takes a sprint. That cost is real, is absent from vendor documentation, and only surfaces once you are already committed to the migration.

The question to ask vendors is not "what format is the export?" The useful question is: "Can you give me a single export package containing ticket data, attachments as binary files, internal notes, and contact records with a shared primary key across all of them?" If the answer is no, you can price the reconstruction work before signing rather than after.

When the export requires a support ticket to start

One tool in the test did not offer a self-service export through the account settings panel.

To receive the data, you had to submit a request to their support team. In our test, the data was delivered within 48 hours. The process was opaque: no status indicator, no estimated delivery window, and no way to verify completeness against the original dataset without manually sampling the file after receipt.

This is an operational risk that extends beyond the inconvenience it might appear to be at first glance. Self-service export means you control the timing and can re-run it if the initial file is incomplete or if you need a more recent snapshot. Request-based export means you depend on vendor response time, vendor completeness decisions, and vendor willingness to cooperate at the exact moment the relationship is ending.

The scenario where this matters most is the adversarial one. Most migrations are amicable: you are moving to a better-fit tool, the relationship ends on neutral terms, and a 48-hour turnaround is acceptable. The question is whether you want to depend on vendor goodwill at precisely the moment when the incentive structure shifts. A billing dispute, a contract termination for cause, or a vendor experiencing financial difficulty each creates a situation where a 48-hour promise becomes a 2-week delay. When the old account is on a 30-day wind-down clock, that delay compresses your migration window and can result in permanent data loss if the account is closed before the export is complete.

Recent technical guidance on avoiding vendor lock-in in B2B SaaS identifies self-service export access as a baseline contractual right, not a premium feature. Open formats, documented APIs, and on-demand export access are the three protections consistently cited in procurement due-diligence frameworks. The framing matters: this is a data access right that belongs in the agreement, not a convenience feature to negotiate after signing.

Before committing to any support platform, verify that you can trigger a full export from the settings panel without opening a support ticket, and that this access is available on the plan tier your team will be on, not only on Enterprise.

What to do before you ever need to export your support data

The best time to run an export test is six months into using a new tool, while the account is active, the dataset is representative, and you have time to act on any gaps before they become migration blockers. The second-best time is today. The worst time is after signing the contract with the replacement platform.

Here is the checklist I use with clients regardless of whether they are actively planning a migration:

1. Run a full export today and open the file. You do not need a migration project to justify this. Disaster recovery, accidental ticket deletion, and regulatory audits are each sufficient reasons on their own.
2. Verify attachments as files, not URLs. Find five tickets with attachments in the tool. Locate the same tickets in the export. Confirm the attachment field contains a binary file, not a URL. If it is only a URL, test whether it downloads to a file successfully. If the URL redirects to a login page or returns an error, the file is already effectively inaccessible from the export.
3. Check internal notes specifically. Open three complex tickets with agent notes in the tool. Find them in the export. If notes are absent in the exported file, the gap is confirmed while you can still act on it.
4. Document your custom fields and tags outside the tool. Keep a spreadsheet listing every custom field name, data type, and purpose, and every tag in use. If the tool is ever inaccessible, this inventory is the map your new tool will be configured from. It takes 30 minutes to create and is worth keeping current.
5. Confirm export access on your current plan tier. Check whether the export is available without a support request and whether your plan tier includes all data categories. If it is plan-gated, know it now, not when you need to use it.
6. Set a quarterly export reminder. Export files are point-in-time snapshots. Running one every 90 days means your worst-case gap between the last good export and an account termination is one quarter of data. For most teams that is acceptable; for compliance-sensitive environments, monthly is better.

The teams that handle migrations without incident are not the ones with the largest migration budgets. They are the ones who had a recent export file, a clean custom field inventory, and no surprises in the attachment check. That preparation is an afternoon of work, done once, and the value compounds for every year you stay on the platform.

How export quality should shape your support tool selection

Export completeness almost never appears in feature comparison tables because vendors have no incentive to surface it.

The questions below consistently produce information that comparison pages omit. I ask them on behalf of clients before any tool decision is finalized.

Does the export include attachments as binary files, not just URLs? This is the single most important question from the test. The answer determines whether you can recover files after account closure. Ask for a demonstration with a test export seeded with actual attachments, not just a documentation link.

Are internal notes included in the standard export, and on which plan tier? Some tools include agent notes only in Enterprise exports or restrict them to API-based exports requiring developer involvement. If your team is on a lower tier, verify the notes are in the export you can actually trigger, not in one that requires an upgrade.

What is the export format, and is the schema documented? A documented JSON or CSV schema means a developer or migration tool can write an import script independently. An undocumented proprietary format creates dependency on the vendor's own migration team or a specialized vendor, which adds cost that shows up in the project budget.

Is the export self-service, and how long does generation take for an account at your volume? For accounts with more than 100,000 tickets, export generation can take hours. Knowing this in advance is part of migration timeline planning. Some vendors throttle export jobs during peak hours, which extends the window further.

Can you re-export at any time while the account is active, and is there a cost? Some tools limit exports by frequency or charge above a certain volume threshold. For quarterly export runs as a precaution, verify this upfront.

What happens to your data after account termination, and how long until permanent deletion? Most vendors retain data for 30 to 90 days post-termination. Knowing the retention window tells you how much migration buffer you have before the data is irrecoverable. Get this in writing, not just from help center documentation that can be updated without notice.

Vendors who take data portability seriously answer these questions in writing without hesitation. The ones who hedge, route you to documentation that does not actually answer the question, or promise to follow up and then do not, are giving you information about how they handle the end of the relationship, which is worth weighting before it starts.

What these results mean for avoiding vendor lock-in

The export test is one dimension of a broader lock-in evaluation. Avoiding vendor lock-in in support tools rests on three foundations: open formats, documented APIs, and self-service export rights.

The completeness test measures the third directly, and the results connect to all three.

Open formats matter because they determine whether your data can be ingested by a destination tool without custom development. JSON and CSV with documented schemas meet the standard. Proprietary XML or JSON with undocumented field names does not. Two tools in our test fell on the wrong side of this line, meaning a migration from either requires vendor assistance or schema reverse-engineering.

Documented APIs matter because they provide an alternative extraction path when the self-service bulk export is incomplete. Three tools in our test had sufficiently complete REST APIs that a developer could extract attachments or internal notes programmatically, even when the bulk export omitted them. That is a workaround rather than a solution, and it requires developer resources the average support team does not have in-house. But it is a materially better position than no extraction path at all.

Self-service export rights matter because they are the operational guarantee that you can access your own data on your schedule, without vendor involvement. One tool in this test failed that standard entirely, requiring a support request to initiate the process.

The tools that scored highest share a common characteristic: they treated export as a product feature with deliberate engineering investment rather than an afterthought. The completeness of their exports, the quality of format documentation, and the accessibility of self-service functions reflect decisions made somewhere in the product's history. That signal is worth weighting when you choose a platform you expect to operate for several years.

The tools that scored worst share the opposite characteristic. In the worst cases, the gap between "you own your data" as a marketing claim and "here is a complete, portable export of your data" as a product reality is wide enough to cause real operational harm during a migration. That gap does not appear in the vendor's feature list, the comparison table on their website, or the sales conversation. It appears when you open the export file and check it row by row.

What will matter most in data portability over the next 12 to 24 months?

Three trends are converging that will make export completeness more consequential for support teams, not less.

AI training data creates new export stakes. As support teams use conversation history to fine-tune AI agents and train response models, the value of a complete historical export increases substantially. A migration that loses internal notes or strips attachment context now also loses AI training signal that is difficult to reconstruct. Teams that discover this gap after a migration face not just lost history but degraded AI capability.

Regulatory requirements for data portability are expanding. GDPR Article 20 established individual data portability rights. Proposed frameworks in several jurisdictions are extending similar rights to business data held by SaaS vendors. Support teams in regulated industries (healthcare, financial services, legal) are increasingly required to demonstrate that customer interaction records can be produced on demand in portable formats. Export completeness is becoming a compliance requirement as well as a migration convenience.

Vendor consolidation is increasing migration frequency. The support software market has seen significant acquisition activity. When a tool you use is acquired, the acquirer may deprecate it, change pricing structures, or alter data retention policies. Teams that have not run a recent export test and documented their export procedure are more exposed to these events than teams that maintain current export snapshots as a matter of routine.

The practical implication is the same in all three cases: treating export as a periodic hygiene task rather than an emergency procedure is the approach that keeps options open.

The finding from this test is specific and actionable: 5 of 15 tools tested dropped attachments, 4 dropped internal notes, and 1 required a support request just to start the export. That is not a minority edge case. It is a third of the market for attachments and more than a quarter for institutional knowledge. The vendors in question all assert in their terms of service that you own your data. The export file is where ownership is either real or theoretical.

If you are currently on one of the tools with material gaps, the mitigation is straightforward: run a test export today, identify what is missing, and build the gap into any future migration plan before you need one. If you are evaluating tools, add the six vendor questions from the selection section above to your process before signing. Neither action is expensive or complicated. Both prevent decisions you will not be able to undo.

Want to score your current support tool's overall lock-in risk, including export completeness, contract terms, and API coverage? Use the ZazaChat evaluation framework to get a structured score before your next renewal.