Switching help desks? What to do with your old ticket history

What are the options for old ticket history?#

The options for old ticket history when switching help desks come down to four paths, and each one keeps different parts of the record. The table compares them by what moves and which links usually break.

Many companies combine the second and third paths: recent tickets in the new help desk and a full export of everything, indexed by the original ticket ID. The fourth path sits on top of the others and changes how carefully the archive is built.

Which links break when tickets move?#

The links that break when tickets move are the ones that give old tickets meaning beyond the conversation itself. A migrated ticket that kept its text but lost its links tells an engineer far less than the original did.

Check each of these in a test migration before approving the full run.

• 1Issue tracker links: Jira or Linear keys stored in integration fields the new tool does not recognize.
• 2Merged and follow-up tickets: parent and child relationships often flatten into separate, unconnected records.
• 3Ticket events: status changes, reassignments, SLA timers and escalation steps, which many imports drop.
• 4Internal notes and side conversations: sometimes imported as public replies, sometimes skipped.
• 5Satisfaction ratings and tags: dependent on matching field definitions in the new tool.
• 6Attachments: links that point to the old domain and stop working when the account closes.
• 7CRM references: account and opportunity IDs from Salesforce or HubSpot that tie tickets to revenue.

How to choose between the options#

Choosing between the options is easier with decision rules tied to how the company actually uses its history. The rules below cover the common situations; where two apply, take the more conservative one.

Whatever the choice, take the export while the old account is fully active. Export APIs, attachment links and admin access can narrow once a subscription is downgraded or in its final billing period, and recovering history after cancellation may not be possible. HubSpot's Product Specific Terms, for example, strongly recommend retrieving customer data before the subscription term ends and say that for hubs such as Service Hub it will not provide access after termination or expiration.

Old tickets can also be harder to see than new ones. Zendesk automatically archives tickets 120 days after they are closed, sooner for very high-volume accounts; archived tickets remain reachable through search, direct links and the API but do not appear in views. An export or migration built from views alone can quietly skip years of closed history, so confirm counts against the API.

What a review for value looks like#

A review for value looks at the ticket history as an asset before deciding its format, asking what the records show rather than how much storage they use. It takes a support lead, an engineering lead and a few queries against the old help desk.

Measure the years covered, how many tickets link to issues or pull requests, how many carry internal notes with real troubleshooting, and which product areas and customer segments they span. Note what is sensitive: payment details, attachments with identity documents, and health or financial information.

The result is a short memo. If the history is long and linked, the archive should preserve events, internal notes and issue links in a structured format such as JSON with a ticket-ID index, not a flat CSV of subjects and public replies.

Illustrative: a restaurant inventory software company switches help desks#

Illustrative: a fictional restaurant inventory software company is moving to a new help desk to combine chat and email support. The migration vendor proposes moving everything, and the COO asks for a review for value before signing off on the scope.

The review finds years of escalations about supplier catalog imports and recipe costing, most linked to Jira issues through an integration field the new tool cannot read. Internal notes hold the troubleshooting. The COO chooses to migrate open and recent tickets for active restaurants and to take a full API export of the old account with events, internal notes, attachments and the Jira link field.

Engineering builds a mapping table from old ticket IDs to Jira keys and new ticket IDs. The archive stays in the company's own storage under its retention schedule, and the old subscription is cancelled only after ticket counts match.

Who should own the decision and the archive?#

The COO should own the decision and the archive, because the choice affects support operations, engineering, privacy and cost at once. Each function signs off on its own part.

After the switch, someone must keep owning the archive: its location, access list, retention reviews and responses to deletion requests. An archive with no owner is the one that gets deleted by accident or kept long past its purpose.

• 1Head of support: what agents need in the new tool, and the migration cutoff.
• 2CTO or engineering lead: issue link preservation, export format and the mapping table.
• 3Counsel or privacy lead: retention schedule, deletion obligations and archive access.
• 4Finance: the old contract's end date and any read-only or downgrade options.
• 5Security: where the archive is stored and who can open it.

How SourceX views an old help desk archive#

SourceX views an old help desk archive as a possible licensing asset when tickets are resolved, linked to engineering work and well preserved. The archive stays in the company's own storage, since SourceX never hosts multi-terabyte datasets, and the first fit check asks only for metadata such as the system, years covered and how tickets link.

If the company decides to go ahead, the work runs through the SourceX five-step transaction of Supply, Rights, Preparation, Approval and Delivery, and nothing is released until personal and confidential details are stripped and the supplier signs off.