How to export your data from Zoho Desk before the contract ends
Zoho Desk's built-in backup gives you a ZIP of CSV files that covers tickets, threads, contacts and knowledge base articles. It does not include attachment files or forum topics, so those need a separate plan before you give notice. Whether you are facing a renewal, a price change, a data residency requirement or a decision to leave, the first task is to know exactly what the backup holds. This guide covers only the export paths Zoho documents. Where Zoho does not describe a behavior, it tells you what to confirm with Zoho in writing.
The backup runs on a 30-day interval, and the download link expires 7 days after it is generated. That means one backup may not be enough. Schedule the first backup early enough to leave room for a second run if the file is incomplete or the link lapses. Download the ZIP, extract it, and check that each CSV has the record count you expect from the Zoho Desk admin console. Confirm with Zoho whether the backup is available on your current plan and which role can trigger it, since access may depend on administrator rights.
Attachments and forum topics are the gaps that cause the most trouble at exit. Keep a list of every ticket type that depends on attachments, such as contracts, screenshots or logs, and decide whether you need those files outside Zoho before the account closes. Attachment retrieval has to be planned as a separate workstream, which usually means working through the Zoho Desk API. Ask Zoho in writing how long your data stays available after cancellation, and keep that date next to your notice deadline so the export finishes while you still have access.
Which Zoho Desk data you can export and in what format
This table lists each Zoho Desk data type, how it leaves the account, its file format and the limits to check. Tickets, threads, contacts and knowledge base articles come through the backup ZIP of CSV files, while forum topics and attachment files fall outside it. Read the limits column as the list of points to confirm with Zoho Desk before your renewal date.
| Data type | Export method | Format | Documented limit |
|---|---|---|---|
| Tickets | Backup ZIP | CSV | Included. Confirm which ticket fields and closed ticket history the file contains. |
| Threads (replies and comments) | Backup ZIP | CSV | Included. Confirm whether internal notes and message attachments are referenced in the file. |
| Contacts | Backup ZIP | CSV | Included. Confirm whether organizations and agent accounts are also covered. |
| Knowledge base articles | Backup ZIP | CSV | Included. Confirm whether embedded images and article attachments are exported. |
| Forum topics | Not in backup | Not applicable | Excluded from the backup. Plan a separate capture before renewal. |
| Attachment files | Not in backup | Not applicable | Excluded from the backup. Confirm the retrieval route with Zoho Desk and budget time to fetch them. |
| Backup schedule | Backup manager | ZIP of CSV files | Backups run on a 30-day interval. Schedule the final backup well ahead of the contract end date. |
| Download link | Emailed backup link | ZIP of CSV files | Links expire after 7 days. Download and store the archive promptly in your own environment. |
How the Zoho Desk backup works and what the 30-day and 7-day limits mean for planning
The Zoho Desk backup is a ZIP of CSV files, so the data arrives flat. Tickets, threads, contacts and knowledge base articles each sit in their own file, and the relationships between them, such as ticket to thread or ticket to contact, survive only as IDs. Whoever imports the data must rebuild every link by ID, matching each thread and contact back to its parent ticket before anything reads correctly in the new system. The backup also leaves out forum topics and the attachment files themselves, so those need a separate route. Open the first export before you commit to a migration date. Check that the IDs are present and complete, and compare row counts with the Zoho Desk views, because a missing key found late forces a second export.
Treat the 30-day interval and the 7-day link expiry as scheduling constraints that shape the whole export. A complete export needs three things in sequence: a backup generated recently enough to hold the data you need, a download inside the 7-day link window, and a stored copy your team controls. If the latest backup is close to 30 days old, every change made since then is missing, so plan a final backup shortly before cutover and run the import against it. Put the download date on the project calendar and assign one named owner, because an expired link means waiting for a new backup. Store the ZIP in your own encrypted storage, record its checksum, and keep it until the migrated data has been checked against the source.
Two points need confirmation with Zoho Desk before you build a plan around this. First, ask whether a backup can be requested on demand or only runs on the 30-day cycle, since on-demand generation changes how you schedule the final cutover. Second, ask how the backup is scoped by department: whether one backup covers every department, or whether each department needs its own run and which records each one includes. Also ask whether the link expiry can be extended for large files. Get the answers in writing, record them in the migration plan as assumptions with a named source and date, and do not rely on memory when the renewal date arrives.
What the Zoho Desk backup leaves out and how to recover it
The Zoho Desk backup is a useful starting point, but it does not give you everything a replacement needs. Each gap below has a different owner, a different recovery path and a different risk, so inventory them before the renewal date and assign each one a method and a person.
Attachment files
The backup lists attachments in the ticket data but does not contain the files themselves. Without them, Zammad imports tickets that point to documents you can no longer open, which breaks audit trails for refunds, disputes and access requests. Ask Zoho which attachment download methods your plan supports, and confirm in the Zoho Desk API documentation whether attachments can be fetched by ticket. Count total attachment storage early, because it sets the transfer time and disk size for the new server.
Forum topics
Forum topics and their replies are outside the backup contents. If your customers use the community forum for product questions or workarounds, those threads disappear at cancellation. Decide whether the forum content must be kept as searchable history, moved into a knowledge base article, or simply archived. For a small set of topics, an agent can copy the content manually. For a large set, confirm with Zoho whether an export or API route exists before you plan the work.
Knowledge base media
Knowledge base articles appear in the backup, but images and files embedded in them may need separate handling. Broken images in migrated articles look like content loss to customers, even when the text is complete. Sample several articles that contain screenshots, diagrams or downloads, check whether those assets are present in the export, and plan to fetch them from the knowledge base interface if they are not.
Automation and configuration
The data backup holds records, not the rules that shaped them. Assignment rules, macros, SLA definitions, departments, custom fields, views and email templates usually have to be documented and rebuilt in Zammad. Export or screenshot each configuration area now, while the Zoho Desk admin console is still available. Map each rule to the Zammad feature that replaces it, and note any rule with no direct equivalent so the support lead can decide how to handle it.
Changes after the last backup
Zoho Desk creates backups on a fixed interval, so tickets, replies and status changes made after the latest backup are not in your copy. If you cancel or stop writing to Zoho Desk without a final backup, that gap becomes permanent. Plan a final export on the last working day before cutover, freeze agent edits for that window, and run a reconciliation that compares ticket counts and latest update times between Zoho Desk and the import.
What is the sequence for a complete Zoho Desk export, and how do you verify it?
This sequence turns a Zoho Desk backup into a verified, stored and signed-off record of tickets, threads, contacts and knowledge base articles, with the gaps that the backup does not cover documented separately. Each step ends with a check that someone can review before the live account changes.
Inventory tickets, contacts and content before exporting
Before generating anything, list what the help desk holds: ticket counts by status and by date range, departments, agents, contacts, threads and knowledge base articles. The support operations lead builds this inventory from the live Zoho Desk reports, and the data owner confirms which categories are in scope. Forum topics and attachment files are not in the standard backup, so record them as separate items now. The step is complete when every category has a count, an owner and a note on whether it is covered by the backup.
Confirm an administrator can run the backup
Check that the person who will run the export holds an administrator role in Zoho Desk and can open the backup settings. Record the date of the most recent backup, because Zoho Desk creates backups on a 30-day interval and a fresh backup may be needed before the export is useful. Confirm the backup route with your Zoho Desk administrator before the renewal window opens. The step is complete when the administrator confirms access in writing and the last backup date is on file.
Generate and download the ZIP within the link window
Generate the backup and download the ZIP while the link is active, because the download link expires 7 days after it is created. Record the file name, file size and a SHA-256 checksum computed on the downloaded file, so later copies can be compared with the original. Open the archive once to confirm it contains CSV files for tickets, threads, contacts and knowledge base articles. The step is complete when the checksum and file inventory are written into the export log.
Store the archive in a controlled location
Move the ZIP into encrypted storage that your organization controls, such as an access-restricted bucket or file share in your own infrastructure. Limit read access to the migration team and the data owner, and record who holds access. Do not send the archive by email or leave it in a personal download folder, because it contains customer names, contact details and conversation history. The step is complete when the storage location, access list and retention rule are recorded and the checksum matches the stored copy.
Export attachments and forum content separately
The backup excludes attachment files and forum topics, so these need their own export route. Ask your Zoho Desk administrator and Zoho support which route supplies attachment files and forum content for your plan, and confirm the format and any rate limits in writing. Download attachments in batches, keep each file linked to its ticket ID, and store forum content with its source reference. The step is complete when each excluded category has a documented route, a file count and a storage location.
Verify counts and IDs against the live system
Compare the row counts in each CSV with the counts taken from the live system in step one, grouped by status and date range. Pick a sample of ticket IDs across several departments and confirm that each appears in the export with the same status, owner and thread count. Repeat the check for contacts and knowledge base articles. Differences should be explained before the next step, such as tickets created after the backup was taken. The step is complete when every mismatch has a recorded cause.
Record the sign-off and freeze the baseline
Compile the inventory, checksums, storage record, excluded-category routes and verification results into one export report. The data owner and the support operations lead review the report, and the security or compliance lead confirms the storage controls. Keep the archive and report unchanged until the migration is verified, and note the date the live account will be frozen or closed. The step is complete when all three named reviewers have signed the report and the baseline is labeled as the reference copy.
What to plan before the Zoho Desk renewal or termination
Most of the export risk sits in the calendar and the access list, not the file format. The cards below cover the decisions to settle before the notice date, so the export, the target platform and the archive are all ready before Zoho Desk access ends.
Confirm renewal and notice terms
Read the subscription order form and ask Zoho in writing for the renewal date, the notice period and whether the plan auto-renews. Do not rely on the date shown in the admin console alone. Record who at your organization can give notice, and whether any add-ons or modules renew on a different cycle from the base plan.
Schedule the first full export early
Plan a complete export well ahead of any deadline rather than at the last moment. Zoho Desk's backup runs on a 30-day interval and its download link expires after 7 days, so a single backup can be missed if you wait for it. Run the first export as a rehearsal, check the ZIP, and only then book the final pass.
Decide the target platform
Choose between self-hosted Zammad and FreeScout, or another target, before the export is needed. The choice decides which fields you must map, whether you need attachments through the Desk API, and which features like knowledge base, SLAs or departments must be rebuilt. Write the decision down with its reasons so the migration plan has a clear owner.
Confirm admin credentials for export
Identify which people hold the Zoho Desk administrator role needed to start a backup and download the ZIP, and make sure at least two of them can do so. Check that these accounts are not tied to a departing employee or a shared login. Also confirm who can access the Desk API later, since attachment retrieval depends on credentials too.
Plan a parallel run
Keep Zoho Desk live for a period after the new platform goes into use so agents can check old cases and customers can still reach the existing channels. Decide which mailbox forwarding changes happen on which day, and who signs off that new tickets arrive only in the target. Record the cutover date in the project plan.
Agree archive retention for compliance
Ask your compliance, legal and records teams how long closed tickets, threads, contact data and knowledge base articles must be kept, and where the archive will be stored. Zoho Desk's CSV backup omits some content such as forum topics and attachment files, so decide now whether those must be exported separately. Document the retention rule and the owner of the archive.
What Zammad's import rules mean for the Zoho Desk export you produce
Zammad has no built-in Zoho Desk migrator, so the export you take from Zoho Desk will not drop straight into Zammad. It has to be shaped for an API import or a custom import built by Zammad or your own team. Zammad's documented migrators for Freshdesk, Kayako, OTRS and Zendesk still show the rules a Zoho Desk import will probably follow: migrations are all or nothing, they work only on a new instance, and each migration accepts one source system. Plan for a clean target instance, a single load, and a rollback path if the import fails partway through.
Three more rules from those migrators shape what you export. User passwords are not migrated, so agents and customers will need to sign in again through whatever login method you configure, and that should be settled before cutover. Differential migrations are not supported, so a backup taken in week one will not be topped up later; you will need a final, complete export close to the switch date, plus a decision on how tickets created after that point are handled. Rate limits on the source API depend on the plan, so confirm your Zoho Desk plan and API allowance before you schedule a large attachment or thread pull. Zammad's own Zendesk migration guide shows the kind of preparation a source system needs, including an administrator-level API credential, and the Zoho Desk equivalent should be checked the same way.
The Zoho Desk route to Zammad is covered in the separate migration guide, so this page does not repeat its steps. What matters here is the export format decision. The backup ZIP of CSV files is a starting point, but it leaves out attachment files and forum topics, so the migration route will need to fetch what the backup omits. Decide the format with that route in mind, confirm with your implementation partner or Zammad which fields the import will map, and test the full path on a copy before you rely on it. Your renewal date should follow from that test, not the other way round.
Questions buyers ask before exporting Zoho Desk data
How much effort does a full Zoho Desk data export take?
Most of the effort is staff time, not the export itself, and storage and any outside help are the other cost lines. Downloading the backup is a single step, but the work around it includes choosing which records to keep, fetching attachments separately, checking record counts and storing the copy securely. Internal staff time is usually the largest component. Costs rise with the number of tickets and threads, the volume of attachments, the number of departments and custom fields to map, and the number of people who must sign off. Ask any provider for effort broken down by workstream, the assumptions behind each estimate and a list of exclusions.
How long does a Zoho Desk data export take to complete?
The duration depends on data volume, attachment count and how quickly your team acts inside the link window. Zoho Desk creates backups on a 30-day interval and its download link expires after 7 days, so a backup you miss means waiting for the next cycle. The backup ZIP does not contain attachment files, so retrieving them is a separate step that runs for as long as your attachment count and total size require. Measure both before you set a date. Start verification as soon as the download completes, and keep the verified copy in storage you control.
Who pays for a Zoho Desk export inside our organization?
The cost falls on the people and budgets that do each step. The Zoho Desk administrator usually runs the backup and holds the account settings. A data owner in support operations decides which queues, departments and closed tickets are kept. An engineer or IT staff member handles storage, checksums and the target system, and finance funds storage in your infrastructure and any outside help. Recurring costs stay small unless you run parallel systems for a period. Assign a named person to each role in the plan so that no step waits on an unclear owner.
What access and decisions does a Zoho Desk export require?
You need an administrator account in Zoho Desk that can run the backup, and you should record who holds that role. Name one data owner who decides retention, the handling of personal data and which departments are in scope. Define a verification plan before the export starts: compare record counts for tickets, threads and contacts, have a support lead check a sample of tickets, and confirm that every attachment is either retrieved or accounted for. Store the ZIP encrypted at rest, restrict who can open it, and remove temporary copies once verification is signed off.
Can our own team export Zoho Desk data without a consultant?
Yes, a team with an administrator and someone comfortable working with CSV files can download the backup and store it. The harder parts are retrieving attachments, mapping departments, teams and SLAs, and importing into a new help desk. Zammad's built-in migrators do not include Zoho Desk, so any import needs the API or custom development. Teams with clear data owners, a test import on a non-production instance and a plan for the 7-day link window often manage alone. Consider outside help when attachment volume is high, when custom fields are numerous or when evidence must be prepared for an audit.
What should a written scope for a Zoho Desk export include?
A written scope should state exactly what is exported, how it is verified and who approves the result. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and a quote follows from that written scope. Ask for these items in the document:
- The data sets in scope, including tickets, threads, contacts, knowledge base articles and any forum content the backup does not cover
- How attachment files are retrieved, stored and checked against ticket records
- Verification steps, the counts compared and who signs off
- Handling of personal data, retention periods and secure deletion of temporary copies
- What happens if a backup window or link expiry is missed and who repeats the step
Does the Zoho Desk backup include everything we need to keep?
No. The backup is a ZIP of CSV files covering tickets, threads, contacts and knowledge base articles. It leaves out forum topics and the attachment files themselves, so those need a separate inventory and retrieval plan. Confirm which fields and relationships survive in CSV form before you rely on the file as a record. Compare the backup against a written list of what your support and compliance teams must keep, including closed tickets and their attachments. Record every gap in writing so you can show later what was not moved and why.
How DeployOpen scopes and delivers a Zoho Desk data export
DeployOpen treats a Zoho Desk export as a planned project with a written scope, not a single download. We agree what the export must contain, check it against what Zoho Desk's backup actually includes, and hand over a verified archive your team can keep or import elsewhere.
How we scope
- Inventory which tickets, threads, contacts, knowledge base articles and forum content the business must keep.
- Record the attachment files and any data outside the standard backup that need a separate retrieval path.
- Agree the backup timing against the renewal date and the 30-day backup interval.
- Confirm who holds the Zoho Desk administrator access and the mailbox that receives download links.
How we build
- Run a test backup and check the CSV files for record counts, date ranges and field completeness.
- Script the retrieval of attachments through the Zoho Desk API where the backup leaves them out.
- Document each gap found in the export and the method used to close it.
- Test a sample of records against the live Zoho Desk account before the final export is accepted.
How we hand over
- Deliver the archive with a manifest listing files, record counts and checksums for verification.
- Provide a written record of what was excluded, why, and where that data now sits.
- Store the export in your own infrastructure with access controls agreed in the written scope.
- Walk your team through the file layout so later migration or audit work starts from known inputs.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Re-run the export on a schedule if the data must be kept current until the account closes.
- Review the export again if Zoho Desk plan terms or data retention settings change.
- Engagements are fixed-scope, so any extra work is agreed in writing before it starts.
