Switching helpdesks: how to keep a complete archive of old support tickets

Why does a helpdesk migration lose old ticket history?#

A helpdesk migration loses history because migration tools move only what the new system has a place for. Anything without a matching field, object or permission model gets flattened, renamed or dropped, and nobody notices until someone searches for an old case.

The losses follow a pattern. Internal notes may arrive as public comments or not at all. Ticket events such as reassignments, priority changes and SLA breaches rarely carry over, so the new system shows what was said but not how the case moved. Agents who left years ago can appear as a generic user, which breaks any later analysis by team or skill.

Scope decisions cause the rest. Many teams migrate only open and recent tickets to keep the project small, then cancel the old subscription with the remaining history still inside it.

What belongs in a complete support ticket archive?#

A complete support ticket archive is one you can read, search and explain without the old helpdesk. That means raw records with their structure intact, the files they reference, and enough configuration to show how agents worked.

Prefer raw API output in JSON over report-style CSV files. Reporting exports tend to flatten comments into one cell and leave attachments out, which makes the archive harder to verify and much harder to reuse.

• 1Every ticket with all comments in order, each with author, timestamp and a public or internal flag.
• 2Attachments and inline images saved as files, with a manifest linking each file to its ticket and comment.
• 3Ticket events: status changes, assignments, merges, priority changes and SLA timers.
• 4Custom field definitions, ticket forms, tags, groups, brands and products.
• 5Users and organizations, including deactivated agents with their former team and role.
• 6Macros, triggers, automations and help center articles, which explain why replies look the way they do.
• 7Outbound references: Jira or Linear issue keys, CRM account IDs and links to Slack threads.
• 8Satisfaction ratings and survey comments.

Which export route should you use?#

The right export route is usually a combination: the vendor's API for structure, a file pull for attachments, and the old system's own reports to check counts. Few teams get a complete archive from a single button.

Many help desks limit how far back exports go, which plan tiers can run full exports and how fast the API can be called, so check your plan and the vendor's documentation before you sign with the new provider. If a full export needs a higher tier, a short upgrade for the export window may be better than losing the history.

Zendesk shows how specific these limits get. Its account data exports are not switched on by default; the account owner has to ask Zendesk support to enable them. They are not available on Team plans, although every plan can export through the REST API, and Zendesk says AI agent tickets cannot be exported. Closed tickets are archived automatically after 120 days and drop out of views, but stay reachable by search and API, so a migration scoped from views can quietly miss years of history.

Give one person ownership. A support operations lead working with IT usually knows both the data and the tools, and the COO should see a written sign-off before the old contract ends.

How do you keep the links to engineering issues?#

Links to engineering issues survive only if you capture them on purpose, because they usually live in an integration rather than in the ticket itself. A Jira or Linear app in the helpdesk sidebar stores its links in its own data, and that data often does not travel with a migration.

Before the cutover, copy linked issue keys into a ticket field or a separate link table that records ticket ID, issue key, link date and the issue's final status. On the engineering side, export the issues that reference ticket IDs, so the connection can be rebuilt from either direction.

Keep the old ticket ID as a field in the new helpdesk and in the archive index. Product managers, engineers and auditors will cite old ticket numbers for years. These linked chains, from a customer report through the fix to the release, are also the part of a support history that AI developers value most, because they show a problem, a decision and an outcome.

How do you verify the archive before the old account closes?#

You verify a support ticket archive by comparing it against the live system while you still have access. Once the subscription ends, missing records usually cannot be recovered.

Some exports reference attachments by URL instead of including the files, and those URLs can stop working when the account closes. Download the files themselves and spot-check that they open.

• 1Compare ticket counts by year, status and brand between the old system's reports and the archive.
• 2Sample tickets from each year and check comment counts, internal notes and attachments one by one.
• 3Open a sample of attachments to confirm they are real files, not expired links or empty placeholders.
• 4Confirm that deactivated agents and deleted end users still resolve to a name or a stable ID.
• 5Check that issue keys in the link table match real issues in Jira or Linear.
• 6Write an index with ticket ID, created date, subject, status, brand, linked issue keys and file location.

Where should the archive live, and who should open it?#

The archive should live in storage your company controls, encrypted, with access limited to support leadership, legal and IT. Support tickets contain names, email addresses, account details and sometimes sensitive information customers typed in, so privacy and security duties continue after the old helpdesk is gone.

Apply your retention policy to the archive, not just to the live system. Record why it is kept, who owns it and when it is reviewed. If counsel has placed any customers or matters under legal hold, keep those tickets regardless of the general schedule.

An archive is also the safest starting point for any later decision about reuse. Reviewing what you hold does not require sharing it, and any proposed license would still need its own rights and privacy review.

Illustrative: a property management software company changes helpdesks#

Illustrative: a fictional property management software company is moving from its original helpdesk to a platform bundled with its CRM. The migration vendor proposes moving open tickets and the most recent history, and the COO approves that scope for daily work in the new system.

Separately, the support operations lead pulls the full history through the old vendor's API as JSON, downloads every attachment, and exports the Jira link data from the sidebar integration into a link table. Comparing yearly counts against the old reports reveals that one brand's tickets were missing from the first pull, so the team reruns it before cancelling.

Later, an engineer investigating a recurring rent-ledger bug finds the original customer reports and the earlier fix through the archive index. When leadership asks what support records the company holds, the answer comes from the same index, without reopening a cancelled account.

How SourceX looks at a helpdesk archive#

SourceX treats a well-indexed helpdesk archive as a strong starting point for the Supply step of the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The first fit check uses metadata only, such as the source system, years covered, record families and whether tickets link to engineering issues. No files are shared.

If a company chooses to proceed, the archive stays in its own storage. Rights review covers customer contracts and vendor terms, preparation removes personal and confidential details, and the SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization for anything the company approves.