Helpdesk migration: what happens to your old ticket history?

What actually moves when you switch helpdesks?#

What moves in a helpdesk migration is whatever the new tool's data model can hold, which is rarely everything the old one recorded. Whether you are leaving Zendesk, Freshdesk, Help Scout or a homegrown system, each helpdesk structures tickets, comments, users and events differently, so a migration maps fields from one model to the other and drops or flattens anything without a home.

The table shows the usual pattern. It varies by migration tool, by vendor and by the options chosen, so treat it as a list of things to confirm in your own field mapping rather than a promise either way.

Why internal notes and audit events matter most#

Internal notes and audit events matter most because they record how a problem was solved, not just what the customer asked and what they were told. Notes hold the diagnosis, the escalation reasoning and the workaround tried first. Audit events show who changed the priority, when the ticket moved to tier two, and how often it bounced between groups.

Without them, a ticket reads like a question and a final answer with nothing between. That is enough for a customer looking back at an old conversation. It is not enough for a support leader studying why some issues take repeated touches, or for anyone training an AI support agent on how good agents work a hard case.

There is also a privacy risk. If a migration maps internal notes as public comments, frank internal discussion can become visible to customers in the new portal. Check a sample of migrated tickets with internal notes before go-live, from the customer's view as well as the agent's.

What gets lost that nobody notices until later#

The losses nobody notices until later are the small structural ones, because a migrated ticket still looks complete on screen. They surface long afterward, when someone searches for an old escalation and cannot follow it.

• 1Deactivated agents replaced by a placeholder user, so you can no longer see who handled a ticket.
• 2Created and solved timestamps reset to the import date, which breaks any reporting on resolution time.
• 3Merged tickets imported as separate records, or the merge trail dropped entirely.
• 4Links to Jira or other trackers lost because the integration stores IDs the new tool does not read.
• 5Closed tickets older than a cutoff left behind to reduce migration cost, with no separate archive.
• 6Side conversations, linked problem and incident tickets, and follow-up tickets flattened into plain comments.
• 7Satisfaction ratings detached from the tickets they rated.

The keep-a-full-export checklist#

A full export is a separate copy of the old helpdesk, taken by your team, that does not depend on what the new tool chose to import. Run it while the old subscription is still active and the API still answers. Built-in exports often cover tickets and fields but not every comment, attachment or event, and some depend on the plan, so check the vendor's documentation and test the export on a small date range first.

• 1Export every ticket with all comments, marking which are public and which are internal.
• 2Export the audit or event log for each ticket, including status, assignment and priority changes.
• 3Download attachments separately and keep a manifest that links each file to its ticket and comment.
• 4Export users, organizations, groups and deactivated agents, so names and teams can be resolved later.
• 5Save custom field definitions, tag lists and picklist values with their meanings.
• 6Save macros, triggers, automations, SLA policies and help center articles as they stood.
• 7Record every link to engineering trackers, such as Jira issue keys stored in integration fields.
• 8Export satisfaction ratings and their comments with ticket IDs.
• 9Verify counts against the old system, store the export in company-controlled storage and write down what could not be exported.

Who should own the archive once the old tool is gone?#

The archive should have a named owner, usually support operations with IT, because an export in a shared drive with no owner tends to be deleted in the next cleanup. The owner decides who can access it, how long it is kept and how it is documented.

The archive still contains customer names, email addresses and whatever customers wrote, so the same privacy obligations apply as in the live helpdesk. Restrict access, follow your retention policy and keep a short readme describing the schema, the date range and the known gaps.

Decide the format with the owner too. A raw API export in JSON keeps the most structure, including comment visibility and event order, while CSV files are easier to open but usually flatten comments into one cell. Keep the raw export as the record of truth and generate readable copies from it, never the other way round.

Illustrative: a field service software vendor switches helpdesks#

Illustrative: a fictional vendor of scheduling software for landscaping companies moves its support team from its original helpdesk to a platform bundled with its CRM. The migration partner proposes importing only recent tickets and rebuilding macros by hand.

The VP of customer support asks for a full export first. The test migration reveals two problems: internal notes are mapped as public replies, and the Jira issue keys stored by the old integration have no destination field. The team fixes the note mapping, adds a custom field for the old issue keys, and keeps the complete export, with audit logs and attachments, in company storage.

The old history later proves useful twice. Product managers use it to trace a recurring sync problem back through years of escalations, and leadership describes the archive in a metadata-only fit check to see whether its linked ticket-to-fix records could be licensed.

What old ticket history is still good for after the switch#

Old ticket history is still good for three things after a switch: improving internal support, documenting product problems over time, and, in some cases, licensing. Each use depends on the export being complete enough to show how tickets were actually resolved.

Inside the company, archived resolutions help write knowledge base articles, onboard new agents and ground an AI support agent in how the team really solves problems. For outside AI developers, the most useful archives link tickets to resolution codes, engineering issues and the final customer reply.

SourceX reviews support archives using the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Nothing is shared at the fit check beyond a description of the archive: the helpdesk used, the years covered and the links that exist. If a package proceeds, preparation removes customer names, contact details and other personal and confidential information, and the company approves each step. Large archives stay in the company's own storage or ship on encrypted drives; SourceX does not host them. The company keeps ownership of the archive and licenses it rather than selling it.