Export your data from Zendesk before the contract ends
A renewal, a plan change or an exit decision makes a complete copy of your tickets, users and organizations urgent. Zendesk's account exports cover tickets, users and organizations in JSON, CSV and XML, but the CSV format leaves out ticket comments and descriptions, and XML is capped at 500 MB and unavailable above 200,000 tickets. Zendesk documents two paths for getting data out: account exports and the incremental export API, and most migrations need both.
Start by checking eligibility now, not at the end of the contract. Exports are available on Suite Growth and higher and Support Professional and higher, not on Team plans, and they are not enabled by default. The account owner has to ask Zendesk support to turn them on, so confirm this early. Once enabled, JSON is the format Zendesk recommends for accounts above 200,000 tickets. Run a test export and confirm that the file contains the ticket count you expect before relying on it.
The incremental export API, documented in the Zendesk developer documentation, returns records that changed since the last request, with up to 1,000 results per page. It is rate limited to 10 requests per minute and does not return data from the most recent minute, so plan the run time with a script and keep the cursor it returns. Comments are the gap to plan for: ticket events describe comments only with Boolean properties unless the comment_events sideload is requested. Ask your Zendesk administrator or partner to confirm the current limits for your plan before the run.
Which Zendesk data you can export and in which format
This table maps each Zendesk data type to the export method, format and documented limits that apply. Read it as a checklist: account exports cover most records on eligible plans, while the incremental API and comment handling fill the gaps for full history. The main takeaway is that a complete copy usually needs more than one export method.
| Data type | Export method and format | Documented limits and plan notes |
|---|---|---|
| Tickets | Account export as JSON, CSV or XML; or incremental ticket export API | JSON, CSV and XML exports need Suite Growth or higher, or Support Professional or higher. Not available on Team plans. |
| Users | Account export as JSON, CSV or XML; or incremental user export API | Same plan requirement as ticket exports. Confirm with Zendesk support whether your export includes every user field you need. |
| Organizations | Account export as JSON, CSV or XML; or incremental organization export API | Same plan requirement. Confirm the field set in each format before relying on it as a backup. |
| Ticket comments and descriptions | Not in the CSV export. Pull through the ticket events endpoint with the comment_events sideload | Without the sideload, ticket events describe comments only with Boolean properties. Comment bodies need this extra request. |
| Ticket events and metric events | Incremental export API for ticket events and ticket metric events | Incremental endpoints allow up to 1,000 results per page and 10 requests per minute. Recent data from the last minute is not returned. |
| Custom objects and articles | Incremental export API for custom object records and articles | Confirm with Zendesk support which of these endpoints your plan and account can call before planning the export. |
| Full account in one file | Account export in JSON, CSV or XML | XML is capped at 500 MB and unavailable above 200,000 tickets. Zendesk recommends JSON for accounts above 200,000 tickets. |
What the account export leaves out and how to get it back
The account export is a useful starting point, but it does not carry everything a support team relies on. Comments, attachments, configuration and automation logic need separate handling, and each one has a different recovery path. Work through these cards before you cancel the Zendesk subscription.
Ticket comments and descriptions
The CSV export omits ticket comments and descriptions, so a CSV file alone cannot rebuild the conversation history. Comments are the part of a ticket that customers and agents actually wrote, so treat their absence as a hard gap. Pull them through the incremental API, which returns ticket events, and plan to store the results next to the tickets they belong to.
Comment events as Boolean flags
Ticket events describe comments only with Boolean properties unless you request the comment_events sideload. Without that sideload you learn that a comment happened, but not what it said or who wrote it. Request the sideload explicitly in every incremental call that feeds your archive, and check a sample ticket for the comment body before you rely on the output.
Incremental pulls under rate limits
Incremental export endpoints allow up to 10 requests per minute, so a full history of a large account takes many paced calls. Use the cursor-based endpoints that Zendesk recommends over time-based ones, and keep the last cursor so an interrupted run resumes instead of restarting. The API also does not return data for the most recent minute, so schedule a final run after the cutoff and reconcile the newest tickets.
Attachments and inline files
Attachments are a separate item from ticket text, and you should confirm how each export path handles them before assuming they are included. Check a sample ticket with an attached file and verify that the file can be downloaded and matched to its ticket ID. Record the file names, sizes and any inline images that depend on Zendesk-hosted URLs, because those links stop working once the account closes.
Settings, automations and macros
Triggers, automations, macros, views, business rules and custom ticket forms define how your team works, and the account export does not describe them in a form you can reuse. Export a written inventory of these objects from the admin interface, or through the API, and confirm with Zendesk support what each method returns. Without this record, the new help desk starts without the routing logic your agents depend on.
Anything outside the documented exports
Some data may sit outside the documented account exports, such as help center articles, custom apps, integrations and audit history. Build a list of every integration connected to the account and every data type your team uses, then check each one against Zendesk's current documentation. Where the documentation is silent, ask Zendesk support in writing and keep the answer with your migration record.
How to run a complete export in the right order
This sequence produces a complete, verified copy of your Zendesk tickets, users and organizations, including the comment history that the CSV export leaves out. Each step ends with a check so you know the copy is usable before you rely on it.
Confirm your plan and request export access
Check your Zendesk plan first. Data exports are available on Suite Growth and higher and Support Professional and higher, but not on Team plans. Exports are not enabled by default, so the account owner must ask Zendesk support to turn them on. Until that is done, the Admin Center export options will not work. Done means the account owner has written confirmation from Zendesk support that exports are enabled, and someone has tested the export page once.
Run the full account export in JSON
Start with a full account export in JSON, which Zendesk recommends for accounts with more than 200,000 tickets. XML is capped at 500 MB and is unavailable above 200,000 tickets, and CSV omits ticket comments and descriptions, so neither should be your primary copy. Download the archive when Zendesk notifies you that it is ready. Done means you have the complete archive on disk and its file list includes the tickets, users and organizations you expect.
Pull the incremental API with cursor pagination
Use the incremental export API for tickets and ticket events to capture full history, including changes made after the account export was generated. Follow the cursor-based endpoints, since Zendesk recommends cursors over time-based exports, and read up to 1,000 results per page. Build in a pause so you stay within the limit of 10 requests per minute, and retry when you receive a rate limit response. Done means the API reports that no more pages remain and every response was saved with its cursor value.
Capture comments through ticket events
The CSV export leaves out comment text, and ticket events describe comments only with Boolean properties unless you request the comment_events sideload. Request that sideload when you pull ticket events so comment content is included in the raw responses. Confirm on a sample ticket with a known comment thread that the comment text appears in the saved data. Done means the sample ticket's full conversation can be rebuilt from your files alone.
Compare record counts with Zendesk admin views
Before you trust the files, compare totals against what Zendesk shows. Count tickets, users and organizations in the archive and in the relevant admin and reporting views for the same period, then reconcile any gap. Expect small differences if records changed during the export, and note them. Done means each object type has a count you can explain, with differences documented and traced to ticket updates or deletions.
Schedule a later run to cover the newest minute
The incremental endpoints do not return data for the most recent minute, so the latest changes can be missing from any single run. Run the incremental pull again later, starting from the last saved cursor, and confirm that records changed just before your first run appear in the second run. Done means a later run has covered the window that the first run could not reach, and you have recorded the final cursor value.
Store raw files with checksums and a manifest
Store the raw JSON archive, the incremental responses and the cursor log together, unchanged, in storage you control, with a checksum for each file and a manifest listing the export date, plan, object counts and cursor values. Keep at least one copy outside the system you will migrate into. This raw set is also your backup copy if you later move to another help desk. Done means someone other than the person who ran the export can open the manifest and reproduce the counts.
Why the incremental export API gives the full ticket history
The incremental export API is the part of Zendesk's export tooling that can give you full ticket history, because it returns records that changed since your last request rather than a single snapshot. The incremental endpoints cover tickets, users, organizations, ticket events, ticket metric events, custom object records and articles. Each response is a page of up to 1,000 results, and you keep requesting pages until the end of the window is reached. Your script stores the position it reached and resumes from there on the next run, so a long-running export can be split across many calls without losing records between them.
Zendesk recommends cursor-based polling over time-based polling. A cursor is an opaque position returned by the API that marks where the previous page ended, so the next request continues exactly from that point. A time-based start value depends on your own clock and on how the API interprets timestamps, which makes gaps and repeats easier to introduce. Build the export around the cursor from the first request, store it durably after each page, and treat a lost cursor as a reason to restart the affected window rather than guess a timestamp. Zendesk also limits incremental endpoints to 10 requests per minute, so your script should back off when it receives a rate limit response.
The API does not return data from the most recent minute, so a run that stops at the current time can miss tickets updated during that minute. Plan for this by overlapping windows, so each run re-reads a short span already covered by the previous run, and deduplicate records by ID and update time when you write them. Alternatively, end each window one minute before the run starts and pick up the skipped minute in the next run. Confirm the current window behavior, page sizes and rate limits in the Zendesk developer reference before you write the script, since these details can change.
Questions buyers ask before exporting Zendesk data
How much effort does a full Zendesk export take?
The effort depends on ticket volume, your plan, the export method and how much detail you need beyond the basic fields. Account exports in JSON, CSV and XML are limited by plan: they are available on Suite Growth and higher and Support Professional and higher, not on Team plans, and the account owner must ask Zendesk support to switch them on first. XML exports are capped at 500 MB and unavailable above 200,000 tickets, and Zendesk recommends JSON for accounts above that size. Full ticket history usually means the incremental export API, which returns up to 1,000 results per page and allows 10 requests per minute. Confirm with Zendesk which limits apply to your plan before you plan the work, and ask for the account's ticket count so the method can be chosen up front.
Can an internal engineer run the export alone?
Yes, a single engineer with API access can run a basic export, but a complete one usually takes more than scripting. The CSV export leaves out ticket comments and descriptions, so comment data must be pulled separately. Ticket events only describe comments with Boolean properties unless the comment_events sideload is requested, so the engineer must know that option exists and check the output. Attachments, custom fields and deleted or archived records also need checking. Expect the engineer to write and test a script, handle pagination and the one-minute delay in recent data, and store the output in a format that can be read later. Whether to do this in house depends on who has the time and the skills to verify the result.
What does an outside partner need from our team?
An outside partner needs three things from your side: access, a named owner and a sign-off process. For access, the Zendesk admin must create an API token for a full administrator and confirm that exports are enabled, or the account owner must grant the required rights. A named data owner should decide which records, time ranges and fields are in scope, and who approves any data leaving Zendesk. A verification sign-off should confirm that record counts, comments and attachments match what Zendesk shows before the export is accepted. Agree these items, along with the fixed scope and deliverables, in writing before work starts. DeployOpen works under fixed-scope agreements, so the written scope is where these responsibilities should be recorded.
Is a Zendesk export enough to migrate to Zammad?
An export is a useful backup, but it is not the same as a migration. Zammad's built-in Zendesk migrator needs its own API token from a full administrator, and it works only on a new instance. Its migrations are all or nothing and do not support differential runs, so changes made in Zendesk during the move are not picked up later. User passwords are not migrated, and rate limits depend on your Zendesk plan. Your export helps you check what should arrive and gives you a fallback copy. Confirm with Zammad's migration documentation whether the migrator covers every object type you use, and plan the cut-over date and any data that needs custom handling.
How long should we keep the Zendesk export copies?
Retention is set by your legal, regulatory and internal policies, not by Zendesk or Zammad. Ask your compliance lead which records must be kept, for how long, and in which location. Exports contain personal data about customers and agents, so they should be stored with access controls, encryption and a documented deletion date. Keep the export files, the scripts used to create them, and the verification records together, so you can show later how the copy was made. Confirm with Zendesk how long it keeps data after you close or downgrade the account, because that date may fall before your own retention period ends.
Which data does the export miss, and how do we check?
The main gaps are ticket comments and descriptions in the CSV export, and any comment detail not requested through the sideload in the incremental API. Other items to check include attachments, custom fields, macros, triggers, views, knowledge base articles and audit history. Compare the export with a sample of tickets in Zendesk: open each one, count the comments, confirm attachments and check user and organization links. Record the counts for each object type and keep them with the export. Confirm with Zendesk's developer documentation which endpoints cover each object you need, since the supported sources differ by object type.
What does DeployOpen need to start an export engagement?
DeployOpen plans and runs export work as a fixed-scope engagement, so the first step is a written scope. To prepare a quote, we need the Zendesk plan, approximate ticket volume, the objects to export, the output format and the storage location inside your environment. We also need the API token arrangement, the named data owner and the verification steps you require. DeployOpen does not publish a price list, so the quote follows from that scope. Ask us to confirm which deliverables, timelines and checks are included before any work begins.
What to plan before the Zendesk contract renews or ends
The export itself is the easy part. The decisions that cause trouble are timing, the plan that controls export access, and who accepts the result. Each card below turns one of those decisions into a question you can answer before the renewal or end date.
Confirm plan and export access early
Check which Zendesk plan the account is on, because JSON, CSV and XML exports are offered on Suite Growth and higher and Support Professional and higher, but not on Team plans. Exports are not enabled by default, so the account owner must ask Zendesk support to turn them on. Ask for that change well before the end date, and confirm in writing that it is active.
Schedule a full test export
Run at least one complete export on the actual account and open the files. Note the format chosen, the size of the output and whether the CSV omits ticket comments and descriptions, which it does. If the account is large, check the XML cap and the recommendation to use JSON for accounts with more than 200,000 tickets before you rely on a format.
Decide retention and encryption for the archive
Decide how long the exported archive must be kept, where it is stored and who can read it. Exports contain customer names, emails and message content, so the storage location and encryption settings are data protection decisions, not file management tasks. Record the decision and the storage owner before the account closes.
List data owners and legal hold needs
Name the person who owns each data set: tickets, users, organizations and attachments. Ask legal or compliance whether any open matter, dispute or regulatory request requires specific tickets to be preserved in an unchanged form. Those requirements decide which exports must be complete and which can be filtered.
Plan the cutover window for new tickets
Decide when new tickets stop arriving in Zendesk and where they go during the gap. Incremental exports return only records that changed since the last request and do not return data for the most recent minute, so a final export must be scheduled after the cutover point. Agree who handles tickets that arrive during the switch.
Agree who signs off verification
Name one person who accepts the export as complete, with a checklist that compares ticket counts, user and organization counts, and sample comments against the live account. Put the acceptance in writing before the Zendesk subscription ends, because once access is gone, a gap cannot be checked against the source.
How to verify the copy before you rely on it
Before you retire anything in Zendesk, prove that the export is complete. The first check is record counts per type: tickets, users and organizations each need a count in the export that matches the count shown in Zendesk's own reporting for the same date range and filters. Record the Zendesk figure and the export figure side by side, with the export timestamp, so a later reviewer can see what was compared. Expect small differences for tickets created or changed while the export ran, and confirm the window with a fixed cutoff. Note that the incremental export API does not return data for the most recent minute, so any delta pull should stop at a cutoff that is at least that old.
The second check is comment completeness. The CSV export omits ticket comments and descriptions, so a CSV-only copy will look complete while the conversation history is missing. For a sample of tickets, compare the number of comments in the export against the number of comment events Zendesk reports for the same ticket. Ticket events describe comments only with Boolean properties unless the comment_events sideload is requested, so confirm with your export tooling that you are reading comment content rather than flags. Then compare a sample of tickets field by field: subject, requester, assignee, status, tags, custom field values, timestamps and time zones. Choose the sample deliberately, including old, reopened, merged and high-volume tickets, instead of only recent ones.
Third, keep a documented run log. Each run should record the export type and format, the plan and whether exports were enabled by the account owner, the account and role used, the cutoff time, the counts per type, the sample tickets checked, every mismatch and how it was resolved, and the checksums or file sizes of the stored files. Store the log next to the export in your own retention system, and have a second person sign off on the result. The same log becomes the baseline for any later migration or cost comparison. For how a verified export feeds an import, read the migration topic on this site, and for what the move costs in people and tooling, read the cost comparison.
How DeployOpen scopes and delivers a Zendesk data export
DeployOpen plans and delivers Zendesk data exports as fixed-scope engagements inside your own environment, with the scope and deliverables agreed in writing before work starts. The result is a documented, verifiable copy of your tickets, users and organizations that your team can keep, test and use for migration or backup.
How we scope
- Confirm your Zendesk plan and whether account exports are enabled, since Team plans do not include them.
- Agree which objects are in scope: tickets, users, organizations, and comments through the incremental export API.
- Record ticket volume and choose JSON, CSV or XML in writing, based on your account size and fields needed.
How we build
- Build the export scripts against the incremental export API, respecting its request limit and cursor-based paging.
- Check output against sample tickets so comments and ticket events are captured, not only the CSV summary.
- Test restores into a non-production location and log every run, error and record count for review.
How we hand over
- Deliver the export files, scripts and a runbook documenting how each export was produced and verified.
- Document the data inventory, field mappings and known gaps, so your team knows what the export does not contain.
- Hand over storage, access and retention settings for the exported data, agreed with your security team.
How we support
- Offer ongoing support, upgrades and re-runs of the export as a retainer if you need repeat or final exports.
- Re-test the export scripts when Zendesk API behavior or your plan changes.
- Coordinate with your independent auditors on evidence for retention or data handling, without issuing attestations ourselves.
