How to export your data from Freshdesk

Freshdesk states that its account export must be converted with developer help before another helpdesk can use it, so treat the XML as raw material rather than an import file. The export delivers tickets, solutions, forums and customer lists in separate XML structures, and each one has to be mapped onto the target system's schema. In practice that means deciding how Freshdesk requester records become Zammad customers, how company or organization fields are matched or created, and which custom ticket fields have a destination. Ask whoever will do the conversion to produce a field mapping document first and get your support leads to sign off on it before any code runs.

The harder work sits in conversations and files. Each ticket's replies, private notes and attachments must be linked back to the correct parent ticket, and attachment binaries need to be located and re-attached rather than assumed to travel inside the XML. Check character encodings early, because accented names, non-Latin scripts and pasted HTML from email clients are the usual source of garbled text after conversion. Status and priority values also need an explicit translation table, since a status that exists in Freshdesk may have no equivalent in the target and will otherwise fail silently or land in a default state that distorts your reporting.

Before you commit to a custom conversion, evaluate Zammad's built-in Freshdesk migrator on a fresh Zammad instance, since it avoids most of this mapping work. Its limits matter: the migration is all or nothing, it only runs on a new instance, and it accepts one source system per migration, so confirm the migrator's current behavior against the Zammad migration documentation with a test export. Keep the original XML files, checksummed and stored under your retention policy, as a fallback copy. If a migration fails or a team later needs a record that did not carry over, that untouched export is the only complete source you still control.

Three roles touch this work, and they should be named before anyone clicks Export. The Account Administrator in Freshdesk runs the export itself from Admin, Account, Account Details, Export data, which Freshdesk makes available on every plan. Because the archive contains tickets, solutions, forums and customer lists, an internal owner, usually the support operations lead or the data protection contact, should approve where the file is stored, who may open it and how long copies are kept. The third role is the person who converts the XML into something another helpdesk can load. Freshdesk's own documentation says this conversion needs developer help, so that person must be identified early, not after the file arrives.

An internal team can handle most of the preparation alone. Agents who know the ticket fields, statuses, groups and customer records can list which data must survive the move, and an administrator can confirm which solutions and forums are still in use. Internal staff can also check the export for personal data that should not be copied into a test environment. Outside help usually adds value in the places where mistakes are expensive: mapping Freshdesk fields to the target helpdesk, building and testing the conversion on a sample of tickets, and planning the cutover, including what happens to tickets still open during the switch. Ask any partner for a written scope that names these deliverables and the test evidence they will produce. Confirm with the target vendor which import path is supported before you commission a conversion, because that choice determines how much custom work is needed.

The export is most useful once you know where the data is going, because the conversion work depends on the destination. Freshdesk's account export delivers tickets, solutions, forums and customer lists as XML, and Freshdesk itself says that file must be converted with developer help before another helpdesk can load it. If you plan to move to Zammad, the first decision is whether Zammad's built-in Freshdesk migrator can read your data directly, which makes the XML a fallback copy rather than the main input. Review the Zammad migration documentation before you request the export, so you know which migrator rules apply to your case.

Next, confirm the environment fit. Zammad stores its content in PostgreSQL 15 or newer and requires Redis 7 or newer for realtime websocket communication, and it supports Nginx or Apache as the reverse proxy. Check the Zammad software requirements against the servers or cloud accounts you intend to use, and confirm the database and Redis versions your platform team can actually operate. Also check whether you will run more than one Zammad instance, since multi-instance deployments need Memcached. Ask your platform team who owns patching for each of these components, because that ownership decides whether the target is workable before any data moves.

Finally, treat the target as a go or no-go gate. If the required PostgreSQL or Redis versions are not available in your environment, or nobody is assigned to operate them, resolve that before scheduling the export and the migration. Confirm with the Zammad project or your implementation partner which Zammad release line you will deploy, since security fixes are published on more than one line in parallel. Once the target and its environment are agreed in writing, the export can be scheduled with a clear destination in mind.