How to prepare Zendesk ticket exports for customer data onboarding

Zendesk ticket history often becomes part of a customer onboarding project when a SaaS team is replacing a support tool, launching a customer success workspace, or moving support context into a new product.

The export can look straightforward at first: tickets, requesters, organizations, tags, status, priority, owners, timestamps, and custom fields. The hard part is turning that export into support data the implementation team can trust.

For customer data onboarding, a Zendesk ticket export should not be treated as a raw archive. It should become a reviewed handoff package: scoped records, mapped fields, preserved relationships, clear exclusions, and import-ready files for the next system.

Decide what support history needs to launch

Start by separating “available in Zendesk” from “needed for launch.” Those are not the same thing.

Some onboarding projects need only open and recently solved tickets. Others need account-level support history, escalation context, service tiers, customer health signals, or a complete archive for reference. If the team does not define the launch scope, the export can become too large, too noisy, and too unclear to validate.

Use a simple scope question before export: what support records must work correctly in the destination product on day one?

That question helps the customer success manager, implementation lead, and customer admin agree on:

• Which ticket date range is in scope.
• Whether closed, solved, deleted, or spam tickets should move.
• Whether ticket comments and descriptions are required.
• Which tags, groups, forms, brands, custom fields, or priorities matter.
• Whether requester, assignee, and organization relationships must be preserved.
• Which historical records can be kept as an archive instead of imported into the active workflow.

The goal is not to move every possible field. The goal is to prepare the support data that affects launch, customer context, and downstream customer success workflows.

Choose the export path based on what you need

Zendesk’s own guide to exporting ticket, user, or organization data is the source to check for current account permissions, formats, and limitations before a customer starts the export.

For onboarding planning, the important point is that different export paths answer different needs. A CSV export can be useful for reviewing ticket fields in a spreadsheet, but it may not include the same history or structure as a JSON export or API-based export. A fuller export may preserve more context, but it can be harder for non-technical reviewers to inspect without preparation.

Before the customer exports anything, document the expected file package:

• Ticket records for the scoped date range.
• User or requester records tied to those tickets.
• Organization or account records tied to those requesters.
• Ticket comments or descriptions if the destination product needs support conversation history.
• Custom field definitions, not only custom field values.
• Tag definitions or tag usage notes where tags drive reporting, routing, or customer health.
• Export date, filters, and requester so the team can identify the file later.

This prevents a common handoff problem: the implementation team receives a ticket file, then later discovers that users, organizations, comments, or custom field definitions were needed to make the import meaningful.

Preserve relationships before flattening the data

Support data is relationship-heavy. A ticket belongs to a requester. The requester may belong to an organization. The ticket may have an assignee, group, brand, form, satisfaction rating, tags, custom fields, and related comments.

If those relationships are flattened too early, the import can lose the context that makes the ticket useful. The destination product may receive a row with a subject and status, but no reliable account, requester, owner, or support history.

Build a relationship checklist before mapping fields:

• Can every in-scope ticket be tied to a requester or customer identity?
• Can requester records be matched to the right account, company, workspace, or organization?
• Are assignee and group values still meaningful in the destination product?
• Do ticket forms or custom fields need to become import fields, tags, or notes?
• Are there orphaned tickets where the customer identity is missing or unclear?
• Are merged, suspended, deleted, or duplicate user records visible enough to review?

This is where import readiness becomes more than a column check. The file is only useful if the record relationships survive the move.

Map ticket fields to customer-facing meaning

Zendesk field names can be familiar to support admins and confusing to implementation teams that do not live in the source system. A field named status may be straightforward. A custom field named reason_code, plan_tier, impact_area, or customer_type may need customer explanation before it can be mapped.

A reviewable field map should include:

• Zendesk object, such as ticket, user, organization, or comment.
• Source field name.
• Plain-language meaning.
• Example values from the export.
• Import field in the destination product.
• Required or optional status.
• Cleanup rule, if values need to be standardized.
• Review owner.
• Approval status.

Example values are especially useful for tags and custom fields. A tag can mean routing, segmentation, historical process, escalation, feature area, or temporary triage. The implementation team should not infer that meaning from the tag name alone.

Validate support data before import preparation

Once the export path and field map are clear, validate the records against the import requirements. Do this before spending time on low-value cleanup.

For Zendesk ticket exports, the most common readiness checks are practical:

• Required import fields are present for every ticket that should launch.
• Ticket IDs and external IDs are unique enough for the destination workflow.
• Requester email, user ID, or customer identifier can be matched.
• Organization, company, or account relationships are complete.
• Status, priority, type, group, and tag values match allowed import values.
• Date fields use consistent formats and time zones.
• Closed, solved, deleted, suspended, spam, or test tickets are handled intentionally.
• Comments, descriptions, and attachments are either included, excluded, or planned as a separate workstream.
• Custom fields have definitions and example values, not only column IDs.
• Records excluded from launch have a reason.

The strongest validation rules are tied to launch behavior. If a missing field blocks routing, customer context, reporting, permissions, or first support workflows, it deserves priority. If a field is only historical noise, it should not distract the team from the records that affect go-live.

Treat comments and attachments as a separate decision

Ticket comments, descriptions, and attachments are often where expectations diverge. The customer may assume the entire conversation history will move. The implementation team may only be preparing ticket summary fields. The destination product may support notes but not threaded conversations. Attachments may require separate handling.

Make this decision explicit:

• Which comment types should move: public replies, internal notes, or both?
• Should comments become conversation history, notes, an archive link, or be excluded?
• Are attachments required for active tickets only, all tickets, or none?
• Are sensitive files or internal-only notes present in the export?
• Will the destination product preserve author and timestamp context?
• Who approves excluding history that will not be imported?

This avoids a painful launch surprise where ticket rows import correctly but the customer expected the support conversation history to appear with them.

Package the export as an implementation handoff

A prepared Zendesk export should be easy for the next person to trust. The handoff should explain what the files contain, how they were prepared, what was changed, and what still needs a decision.

Include:

• Export date, source account, date range, and filters.
• Files received and files used for import preparation.
• Field map with example values and approval status.
• Validation summary by issue type.
• Cleanup rules applied to statuses, tags, dates, users, organizations, and custom fields.
• Relationship notes for tickets, requesters, organizations, groups, and assignees.
• Records changed, excluded, deferred, or blocked.
• Open customer questions with owners.
• Import-ready file names and version notes.

This turns the export from a spreadsheet attachment into a customer data onboarding artifact. The customer success manager can understand the launch decision. The implementation team can see what is ready. The customer admin can review questions without decoding every column from scratch.

A simple readiness rule

Use this rule before calling a Zendesk ticket export ready:

The export is ready when the ticket scope matches the launch plan, requester and organization relationships are preserved, required import fields are present, values have been checked against allowed import values, comments and attachments have an explicit decision, exclusions are documented, and open questions have owners.

Aformity is built for this customer data onboarding work: inspecting messy customer files or exports, validating records against import requirements, mapping source fields to import fields, and preparing clean, import-ready data for implementation teams.

For Zendesk exports, that workflow matters because support history is not just data. It is customer context. Preparing it well helps the new system launch with fewer surprises and gives customer success teams a clearer handoff after migration.