Ticket history and data retention: what to keep when you switch tools

Every helpdesk migration forces a question most teams have deferred for years: what is all this history actually for? Ten years of tickets feels like an asset until you have to move it — then it becomes a bill, measured in export hours, import time, storage and search noise. The honest answer is that ticket history does three jobs, each with a different shelf life, and once you name them the keep-or-archive decision mostly makes itself.

The three jobs old tickets do

Job 1: agent context. "Has this customer written before? What did we promise them?" This is the everyday use, and it is intensely recent-weighted. Look at your own tool's data before trusting anyone's rule of thumb: check when an agent last opened a ticket older than a year. In most teams, lookups concentrate overwhelmingly in the last six to twelve months, with a thin tail for active enterprise accounts and open disputes.

Job 2: reporting and trends. Volume curves, topic mixes, seasonal patterns. Reports need aggregates, not raw conversations — and aggregates can be computed once, exported as numbers, and kept forever at negligible cost. You do not need ten years of raw tickets to remember that January is your peak.

Job 3: AI grounding. The newest job and the most misunderstood, so it deserves its own section.

Notice what's missing from the list: nothing requires raw, decade-deep history inside your working tool. Job 1 wants recency, Job 2 wants numbers, and Job 3 — as we're about to see — wants curation. The instinct to migrate everything comes from loss aversion, not from any job the data actually performs.

What your AI actually needs (less than you think)

A tempting intuition says: more history, smarter AI. The way modern support AI works points the other way.

AI agents answer from your knowledge base — current, curated articles — not by digging through years of raw conversations. Where past tickets help at all, it's the recent, well-resolved ones: they show how your team phrases things today, for the product you ship today. Old tickets describe products you've changed, policies you've replaced and workarounds you've fixed. Feeding them in doesn't add wisdom; it adds contradiction, and contradictions surface as confidently wrong answers.

There's a second-order effect teams miss: stale history pollutes agent-facing search too. When an agent looks up "refund policy" and gets hits from three policy generations, the AI-drafted reply built on that search inherits the confusion. A pruned, recent corpus is not a compromise for AI quality — it is AI quality. This is why a migration is quietly the best AI-readiness event a support team gets: it forces the corpus cleanup that nobody schedules otherwise.

The keep / archive / delete framework

Three buckets, decided per data class rather than per ticket:

• Keep (migrate live): the last 12–24 months of conversations, all contacts with their custom fields, the full knowledge base, and open or recently closed disputes regardless of age. This covers nearly all real lookups and everything the AI benefits from.
• Archive (export, store, don't import): everything older, as a read-only export in a structured format — JSON with an index beats CSV for anything you might ever need to search — plus attachments, held in storage you control. Archives are for the rare audit, dispute or nostalgia query; they don't belong in your working tool's search index.
• Delete: spam-closed tickets, one-word exchanges, bounced-email debris and test tickets. This is not risky minimalism; it's noise removal. Nobody has ever needed the archive of autoreplies.

The framework has a pleasant side effect: your new helpdesk starts fast and stays fast, because its search index carries signal instead of sediment.

Retention obligations, in plain terms

This is where teams either overpromise or freeze, so let's keep it plain and honest. Retention rules are real, they vary — and this article is not legal advice.

A few general shapes worth knowing:

• Some records carry mandated minimum retention in some sectors and jurisdictions — commonly things like billing-adjacent correspondence, complaints in regulated industries, or records tied to contracts. The mandate usually attaches to the record type, not to the helpdesk as a whole.
• Privacy regimes push in the opposite direction: data-minimisation principles expect you to keep personal data no longer than needed for a stated purpose. "We kept everything forever because migrating was easier" is not a purpose.
• Archiving does not exempt data from privacy obligations. A ticket in cold storage is still personal data: deletion requests, access requests and breach duties reach it there too.

The practical move: before the migration, have whoever owns legal or compliance in your company write down retention periods per data class — tickets, contacts, attachments, CSAT — even if the answer is a simple table with three rows. The migration then implements the table. That's the whole relationship between the two: counsel decides, migration executes.

Handling personal data in the archive

If you follow the framework, the archive is where old personal data concentrates — so treat it deliberately:

• Restrict access. The working helpdesk has role-based access; your archive should too. A world-readable bucket of ten years of customer conversations is a liability, not a backup.
• Keep a manifest: what the archive contains, date ranges, format, and who approved its retention period. Future-you, handling a deletion request, will search the manifest instead of the raw dump.
• Design for deletion. Store per-customer data in a way that lets you remove one person's records without unpacking everything. An archive you cannot delete from is an obligation you cannot meet.
• Set an expiry. Decide when the archive itself gets reviewed or destroyed, and calendar it. Retention without an end date is just hoarding with a policy document.

What this means for your migration plan

The retention decision reshapes the migration itself, in a good way: the live import shrinks to a fraction of the naive "move everything" plan, which means shorter import windows, cleaner search from day one, and an AI corpus that starts sharp instead of muddy. Teams that pick 12–24 months plus disputes routinely find the import finishing in hours instead of days.

MoveDesk's migration lets you choose the history depth at import time — and because the white-glove migration is free and both tools can run in parallel, you can start with 12 months, live with it for a month, and import deeper history later if reality ever asks for it. In our experience it rarely does.

Write the three-bucket table this week — keep, archive, delete, with a retention period per class. It's one page, it makes the migration smaller, and it upgrades your data posture on the way through.