Support data migration

A support data migration succeeds when agents can find the right customer, read the relevant history and continue unresolved work in the new system. Start with what the team must be able to do on the first day, then decide which records and relationships must move.

Decide what needs to move

Separate cases that still need action from history agents regularly consult and older material that can remain in a controlled archive. For each active case, capture its requester, owner, next action, latest customer message and any promised follow-up. Historical cases may still need their conversations and attachments even if they will not enter a live queue.

Inventory tickets, public replies, internal notes, files, customers, organisations, custom fields and the links between them. Include channel-specific material, such as messaging transcripts, where relevant. A ticket record alone does not establish that its conversation travelled with it.

Export methods differ, and the records and fields available can depend on the method used. Check the source documentation and inspect sample output to confirm what is included.

Freshdesk says its ticket-list export does not contain the full conversation or archived history; those require an account export. Check the method and permissions available in the source account, then inspect sample output.

Data Migration Compliance & Governance (Australia)

Check export access and coverage

Confirm export access before scheduling the migration. In Zendesk, account data exports are not enabled by default; the account owner must ask Zendesk Customer Support to enable them. Export access can also be restricted to certain administrators or deactivated, so verify the required permissions with the source account team.

Zendesk account exports can be produced as JSON, CSV or XML. Its documentation recommends JSON for accounts with more than 200,000 tickets, and notes that exported records are not guaranteed to appear in a particular order. Plan to use IDs and relationships, rather than file order, to associate records during reconciliation.

Freshdesk’s ticket-list export requires an Admin or Supervisor role, and export permissions must be enabled. Its filters determine which tickets appear, while the time range on the ticket list must be wider than the range selected in the export window. Check the export details and history so the team can confirm the selected period and fields.

Export Methods: Zendesk vs Freshdesk

Map the destination

Record how each source field and relationship will be represented. Keep the old ticket ID as a searchable reference if the destination assigns a new one. Map statuses by the work they represent, including who acts next, rather than by matching labels.

Resolve customer identities before attaching tickets. A name or email address may be unreliable when people change addresses, share an inbox or use several channels. Use a trusted customer identifier where one exists, and set aside conflicting matches for review.

For every open case, specify its destination owner, next action and reply route. Decide which platform receives new messages during the switch. If both routes remain active briefly, record how staff will identify duplicates and which case is authoritative.

Rehearse and reconcile

Test a varied set of cases, including a long conversation, an internal note, an attachment, an archived case, a customer with multiple addresses and a case awaiting a reply. Compare the source and destination for message order, authorship, visibility and file access. Have an agent continue an unresolved case in the destination and check what a customer can see.

Record the final export point and capture changes made afterwards. Compare ticket counts by status and channel, then investigate mismatches at record level. Reconcile comments and files separately; matching ticket totals alone do not prove that history is complete.

Assign an owner to each exception, including a missing conversation, wrong customer, lost file, incorrect status or unowned case. Preserve any source field or metric the destination cannot reproduce as labelled history. Zendesk, for example, says its metrics and SLAs are not supported for imported tickets.

Complete the handover when the receiving team can work the active queue, find the agreed history and account for exceptions. Retain the source export and ID mapping under the organisation’s access and retention rules.

Use a small rehearsal export to verify the import path as well as the records themselves. For Zendesk, an account export arrives as a ZIP file after completion, and its download link is valid for at least three days. Allow time to download and inspect the files, particularly when the export is large and contains multiple files.

Plan the import and cutover

Check which source timestamps the destination can preserve. Zendesk’s ticket import supports created, updated and solved timestamps, but created or updated timestamps earlier than 1970 are rounded up to 1970; comment timestamps cannot be in the future or earlier than 1970. Identify records affected by these limits during rehearsal, rather than assuming their chronology will remain unchanged.

Agree how historical closed cases will enter the destination. Zendesk imports can send closed tickets directly to the archive, an option its documentation suggests considering for large historical imports of 750,000 or more tickets to avoid affecting active-ticket performance. Archived tickets have restrictions, so verify that this treatment suits the history agents need to consult.

Build destination behaviour into the cutover checks. Zendesk does not run triggers when a ticket is imported with a status other than closed, but triggers resume if the ticket is updated later. It also sends no notifications to users copied on imported tickets; notifications can be sent on subsequent updates. Tell agents what to expect before they resume work.