Methodology: built from regulator and records-authority pages (eCFR, US National Archives, UK ICO, European Commission), vendor documentation from Atlassian, ServiceNow, Freshworks, Zendesk, TOPdesk and SysAid, and one attributed industry article, all checked on 13 Oct 2026. No vendor reviewed or paid for this article. We did not run hands-on tests.
You should not migrate ticket history by default, and you should not leave it behind by default either. Decide per record type and age. Migrate what people will still act on or report against, archive what you must keep but rarely open, and leave behind what no rule or report needs. This guide is for the Head of Service Management, ITSM platform owner or CIO who signs off migration scope, and ends with a decision table for the scoping meeting.
Key takeaways
- HIPAA covered entities and business associates must document security incidents and their outcomes and keep that documentation for 6 years (eCFR, 45 CFR 164.308 and 164.316, as of 13 Oct 2026).
- US federal help desk records, trouble tickets included, are temporary: destroy 1 year after resolved or when no longer needed for business use (US National Archives GRS 5.8, as of 13 Oct 2026).
- The UK GDPR "does not set specific time limits", but you must not keep personal data longer than you need it (ICO guidance, as of 13 Oct 2026).
- Jira Service Management SLAs keep counting on closed CSV-imported tickets, because imports carry no issue history beyond creation (Atlassian KB, updated 26 Sep 2025).
What does it mean to migrate ticket history?
To migrate ticket history is to load closed and past records (incidents, service requests, problems, changes, their notes, attachments, timestamps and links) into the new ITSM platform as working records. The alternatives are archiving it read-only or leaving it behind on the old platform's deletion schedule.
Whichever you pick, workflows, automations, business rules, SLA definitions, macros and running SLA timers are rebuilt on the target, not migrated. History scope is about records, not configuration.
| Option | Where history lives | What you take on | Main risk |
|---|---|---|---|
| Migrate | Target platform, as normal records | Mapping, test runs, delta sync and reconciliation per record type | Imported records behave differently (SLA clocks, created dates, comment visibility) |
| Archive (read-only) | Legacy tool in read-only mode, a target-side archive, or an exported store | License, hosting or storage, access control, an end date | Nobody can find the record when an auditor asks |
| Leave behind | Nowhere, once the deletion schedule runs | Nothing ongoing | You cannot produce a record you were obliged to keep |
How to decide: obligation, action and reporting
A record earns migration only if someone will act on it in the new platform. Everything else is a question of keeping.
Ask three questions per record type:
- Is there a retention obligation? Legal, regulatory, contractual or policy. If yes, keep it for that period. Kept does not mean migrated.
- Will anyone act on it in the new tool? Open tickets, recurring problems, known errors, changes on live CIs.
- Does reporting or AI depend on it? Trend reports, SLA baselines, training data for classification.
Yes to question 2 means migrate. Yes to question 3 for records inside your reporting lookback also means migrate, so baselines carry over. Yes to question 1 alone, or to question 3 for older records, means archive, or migrate a summary of the outcome. No to all three means leave it behind and record the decision.
Age changes the answers. A closed incident older than your reporting lookback feeds no report you run, so only a retention duty keeps it.
Retention rules for ticket history: what official sources say
Retention rules say how long to keep a record, not where. None of the rules below requires your live ITSM platform, and data protection rules cut the other way.
| Rule (as of 13 Oct 2026) | Applies to | Exact requirement | What it means for scope |
|---|---|---|---|
| HIPAA Security Rule, 45 CFR 164.308(a)(6)(ii) and 164.316(b)(2)(i) (eCFR) | Covered entities and business associates | "document security incidents and their outcomes"; retain documentation "for 6 years from the date of its creation or the date when it last was in effect, whichever is later" | Those tickets stay retrievable for 6 years. A complete archive can meet this. |
| GRS 5.8, item 010 (US National Archives, July 2017) | US federal agencies | Help desk records, including trouble tickets: destroy 1 year after resolved or when no longer needed for business use | Routine tickets carry no long federal duty. Business use decides. |
| GRS 3.2, item 020 (US National Archives, January 2023) | US federal agencies | Security incident records: destroy 3 years after all necessary follow-up actions are completed, longer if required for business use | Security incidents need a longer tail than routine tickets. |
| UK GDPR storage limitation (ICO); EU guidance (European Commission) | Organizations holding UK or EU personal data | ICO: "You must not keep personal data for longer than you need it." Commission: "Data must be stored for the shortest time possible." | Migrating every closed ticket extends the life of personal data. |
A retention duty is met by keeping a complete, retrievable record, not by migrating it. "Bring everything" is not the safe default it looks like. Your legal or data protection lead sets the periods.
Check the target's retention too. SysAid keeps service data 2 years on Professional and 7 years on Enterprise before automatic deletion (SysAid pricing page, as of 13 Oct 2026). A shorter deletion window than your duty does not meet it.
SLA history and reporting continuity
- Jira Service Management: Atlassian says CSV-imported issues have no history "except issue creation event", so SLAs keep counting on closed imports. Its fixes: exclude flagged imports from SLA goals, or bulk transition them to Done, which stops the clock at the transition date (Atlassian KB, updated 26 Sep 2025). CSV import also makes "all the comments from your import file" public in JSM spaces (Atlassian support, as of 13 Oct 2026).
- ServiceNow: SLA repair "removes the SLA record, then recreates and recalculates it from the start" using "the history from the Task" (ServiceNow docs, as of 13 Oct 2026). A migrated record has only the history the migration wrote. The Table API docs add that sys_ fields "are typically system parameters that are automatically generated and cannot be updated", so original created dates need an explicit plan.
Decide which SLA history you need before mapping starts:
- Per-ticket proof ("was ticket X breached?"): carry the final outcome as fields on the migrated record, or keep it in the archive.
- Trend history ("what was last year's compliance?"): freeze legacy reports for closed periods before cutover and store them with an owner.
- In-flight tickets: timers are rebuilt, so agree a policy, such as carrying elapsed time in a field.
If closed history stays behind, dashboards start at go-live with no year-on-year baseline. Migrating the reporting lookback, or a warehouse holding legacy and new data side by side, avoids that.
Read-only archive options vendors document
Keep the legacy platform read-only. At Data Center end of life on 28 Mar 2029, Atlassian says "your data will continue to be available in a read-only state", with no security fixes, and advises against running it online (Atlassian, as of 13 Oct 2026). For SaaS, read-only lasts only as long as the subscription. Zendesk says you lose access on cancellation and automated deletion begins after 90 days (Zendesk support, as of 13 Oct 2026). TOPdesk deletes data after termination and keeps backups for at most 90 days (TOPdesk SaaS page, updated 17 Dec 2025).
Archive inside the target. Freshservice archives closed tickets inactive for a year, read-only but searchable and reportable, for accounts with at least 500,000 tickets (Freshservice support, modified 18 Nov 2025). ServiceNow archives to "ar_" tables such as ar_incident, which "aren't optimized for ad hoc queries" (ServiceNow docs, updated 10 Sep 2026). Jira Cloud space archiving is "only available on Premium and Enterprise plans" (Atlassian support, as of 13 Oct 2026). All three archive records already in the platform: migrate first, archive after.
Export to a warehouse or archive store. Extract tickets, notes, attachments and links through the legacy API into storage you control, indexed by ticket number, requester, CI and date. It outlives the legacy contract, but someone must own its search and access.
| Archive option | Documented example | Search | Watch out for |
|---|---|---|---|
| Legacy read-only | Atlassian Data Center after 28 Mar 2029 | In the old tool | No security fixes; SaaS access ends with the subscription |
| Target-side archive | Freshservice archival; ServiceNow ar_ tables; Jira space archiving | Global search (Freshservice), limited (ServiceNow), none (archived Jira spaces) | History must be migrated first; plan and volume conditions |
| Warehouse or archive store | Built from the legacy API | Only if you build it | Exports that drop comments, attachments or links |
What partners scope out, and what leaving history behind costs
ServiceNow's 2021 implementation playbook lists "Migrate or integrate case history" as a phase 1 action item for customer service, without a method for moving historical records (ServiceNow playbook, as of 13 Oct 2026). If history is not in the statement of work, nobody owns it.
An itsm.tools article by Brian Parks calls full historical migration "expensive, risky" and recommends archiving everything while migrating what the new tool needs. That is one practitioner's view.
What leaving history behind costs:
- Proof you cannot produce once the deletion window passes.
- Lost problem context: repeat incidents lose their links to past fixes and known errors.
- Reporting from zero: no baseline for SLA compliance or volume trends.
- AI with nothing to learn from: a ServiceNow employee's Predictive Intelligence FAQ recommends 30,000 to 300,000 records to train a classification solution (ServiceNow Community, posted 7 Nov 2019).
- Paying twice: a legacy license kept alive for lookups, with no end date.
Migration cost has no neutral public benchmark. Its drivers are record types, volume, attachments, relationships, test runs and delta sync, and scope by record type and age is the biggest lever on all of them.
Migrate ticket history by record type and age: the decision table
Age bands are relative: A is inside your reporting lookback; B is past it but inside a retention duty; C is past every duty with no business use. Legal sets the actual periods.
| Record type | A: inside lookback | B: inside retention duty | C: past retention | Reason |
|---|---|---|---|---|
| Open incidents, requests and changes | Migrate | Migrate | Migrate | Still being worked. Carry elapsed SLA time as a field. |
| Closed incidents and requests | Migrate | Archive | Leave behind | Recent ones feed trends; older ones are proof only. |
| Problems and known errors | Migrate | Migrate if the service is live, else archive | Leave behind | Useful while the service exists. |
| Changes and CAB approvals | Migrate | Archive | Leave behind | Recent changes inform risk checks; older ones are evidence. |
| Security incident tickets | Migrate | Archive, complete and access-controlled | Leave behind; record the deletion date | HIPAA: 6 years for covered entities. GRS 3.2: 3 years after follow-up for federal agencies. |
| SLA results | Fields on migrated records, plus frozen reports | Archive frozen reports | Leave behind | Targets recalculate from their own history. |
| Knowledge articles | Migrate current, after review | Archive retired | Leave behind | Stale articles feed self-service and AI answers. |
| CIs and relationships | Migrate live CIs and links | Archive retired CIs that archived tickets reference | Leave behind | Live relationships drive impact analysis. |
| Attachments | With their record | With their record | Leave behind | Separated from its ticket, an attachment proves nothing. |
| Field-level audit trail | Archive | Archive | Leave behind | Imports start a new history on the target. |
| Spam, test records, alert noise | Leave behind | Leave behind | Leave behind | No obligation, no use. Remove before mapping. |
Scope sign-off checklist
- List every record type in the legacy platform, including custom tables.
- Get written retention periods per record type from legal, with the rule behind each.
- Agree the reporting lookback with the owners of SLA and trend reports.
- Fill in the decision table, with a named owner per row.
- Check the target's automatic deletion and archive features, including plan conditions.
- Decide where archived history lives after the legacy contract ends, and who can access it.
- Confirm from target docs how created dates, internal notes and attachments land.
- Write the history scope, including what is left behind, into the statement of work.
- Record a deletion date for what is left behind.
FAQ
Methodology
We read retention requirements from the eCFR, the US National Archives' General Records Schedules 5.8 and 3.2, and ICO and European Commission guidance on 13 Oct 2026. Import, SLA, archive and cancellation behavior comes from vendor documentation read the same day. The itsm.tools article is a third-party view. This is not legal advice.
Disclosure: MigrateX, the publisher of this article, runs ITSM data migrations, including between platforms named here. No vendor reviewed or paid for this article.