Methodology: built from ServiceNow, Atlassian, Freshworks and Ivanti documentation, plus two named third-party sources, all checked on 29 Sep 2026. No vendor reviewed or paid for this article. We did not run hands-on tests.
An ITSM migration, often called a help desk migration, moves your service history from one platform to another: incidents, service requests, problems, changes, knowledge articles, CIs and the links between them. It runs in six phases: discover, map, test migration, cutover with delta sync, reconcile and hypercare.
Workflows, automations, business rules, SLA definitions and running SLA timers do not move. They are rebuilt on the target. A new platform has been chosen, and you now own moving years of tickets without breaking reporting. This guide is that plan.
Key takeaways
- In Jira Service Management spaces, every comment in a CSV import becomes public, so internal notes need a different route (Atlassian, as of 29 Sep 2026).
- Jira Service Management calculates SLAs from issue history. CSV-imported issues have no history beyond creation, so SLAs on closed tickets keep counting (Atlassian, as of 29 Sep 2026).
- ServiceNow's default export limit and Freshservice's ticket export cap are both 10,000 per export, so full history usually comes out through the API (ServiceNow; Freshservice, as of 29 Sep 2026).
- Priority numbers run in opposite directions: in ServiceNow 1 is Critical, in the Freshservice API 1 is Low (ServiceNow; Freshservice, as of 29 Sep 2026).
Why teams start an ITSM migration in 2026
Three vendor retirements and the renewal cycle push teams toward an ITSM migration in 2026:
| Trigger | What the source says |
|---|---|
| Atlassian Data Center end of life | No sales to new customers after 30 March 2026, no expansion for existing customers after 30 March 2028, and Data Center products, Jira Service Management included, go read-only on 28 March 2029 (Atlassian, as of 29 Sep 2026) |
| Cherwell end of life | Ivanti lists Cherwell under "Cherwell products, now discontinued" (Ivanti, as of 29 Sep 2026). StrataCom, an ITSM consultancy, reports an end-of-life date of 31 December 2026 (StrataCom, as of 29 Sep 2026) |
| Opsgenie shutdown | End of sale 4 June 2025; shutdown 5 April 2027, with alerting and on-call moving into Jira Service Management (Atlassian, as of 29 Sep 2026) |
| Renewal and rightsizing | A renewal prompts a check on whether the platform still fits the service desk's size and process maturity. What drives the bill differs by platform, as Jira Service Management pricing shows |
Confirm the Cherwell date with Ivanti. Its public page does not give one.
Before you start: scope and inventory
Settle three things before any data moves: the kind of migration, the record counts and how much history comes across.
Know which job you are doing
A cross-platform ITSM migration is not a hosting move within one vendor. Atlassian's Jira Cloud Migration Assistant carries SLAs, workflows, queues and request types from Jira Data Center to Jira Cloud (Atlassian, as of 29 Sep 2026). Between different platforms, configuration models do not match, so data moves and the process layer is rebuilt. The platform-specific guides go deeper on two routes: a ServiceNow migration and a Zendesk to Jira Service Management migration.
Count everything
Inventory every record type: incidents, service requests, problems, changes, knowledge articles, CIs and relationships, users, groups, attachments and notes. Count per state as well as totals, and date the counts. Reconciliation compares against them later. The same pass is the time to audit legacy help desk data for duplicates, orphaned records and fields nobody uses.
Decide how much history moves
This is the biggest scope decision, and it belongs to your audit, compliance and reporting owners as much as to IT. itsm.tools describes three options (itsm.tools, as of 29 Sep 2026):
| Option | What it means | Trade-off (per itsm.tools) |
|---|---|---|
| Full history | Every incident, change, problem and asset moves | Expensive and risky, and the copy is "almost, but not exactly like the original" |
| Active work only | Open incidents, unfinished changes, active assets, live knowledge | Audit and look-up questions about old records have no answer |
| Archive plus selective migration | Keep a full archive of the old system, migrate the records that matter | itsm.tools recommends this; you then report across two sources for a while |
Whichever you pick, name who needs old records and how they will reach them.
What moves, what gets rebuilt, what's at risk in an ITSM migration
The one-sentence rule: records move, configuration is rebuilt, and anything computed from history is at risk.
| Moves as data | Gets rebuilt on the target | At risk in transit |
|---|---|---|
| Incidents, service requests, problems and changes, with their field values | Workflows and state models | SLA history, because targets recalculate it from record history |
| Comments and work notes | Business rules and automations | Internal vs public visibility of notes |
| Attachments | SLA and OLA definitions, calendars and running SLA timers | Inline images and very large files |
| Knowledge articles | Notification templates and assignment rules | Original created and resolved timestamps and authors |
| Users, groups and customer organizations | Forms, portal and service catalog items | Links between incidents, problems, changes and CIs |
| CIs and their relationships | Integrations, reports and dashboards | Meaning of states and priorities after mapping |
SLA history is at risk because targets recalculate it. ServiceNow's SLA repair deletes and recreates task SLAs and "uses the history from the Task" (ServiceNow, as of 29 Sep 2026). Jira Service Management also calculates SLAs from issue history, which CSV imports do not carry (Atlassian, as of 29 Sep 2026). Keep historic SLA results as imported fields, an archive, or both.
Help desk migration mapping essentials
In a help desk migration, mapping gives every source value a documented home on the target. Build one mapping sheet per record type and get it signed off before any test run.
States and statuses
Map every source state, including rare ones, to a target state. Jira CSV import can only map to statuses that already exist in the target workflow (Atlassian, as of 29 Sep 2026), so build the workflow first. Freshservice's API uses status codes 2 Open, 3 Pending, 4 Resolved and 5 Closed (Freshservice, as of 29 Sep 2026).
Priority matrix
Map impact and urgency, not only the final priority. ServiceNow derives priority from impact and urgency, with sample values from 1 Critical to 4 Low (ServiceNow, as of 29 Sep 2026). Freshservice's API runs the other way, 1 Low to 4 Urgent (Freshservice, as of 29 Sep 2026). A numeric one-to-one copy would turn your critical incidents into low ones.
Users, groups and assignment
Load users and groups before tickets, and decide how leavers appear: an inactive account, a placeholder user, or the name as text. Freshservice's bulk migration APIs require dependent entities such as users and workspaces to exist first (Freshservice, as of 29 Sep 2026).
Notes: public vs internal
Platforms separate what requesters see from what only agents see. In Freshservice, private notes are visible only to agents with access to the ticket (Freshservice, as of 29 Sep 2026). In Jira Service Management, a CSV import makes all comments public (Atlassian, as of 29 Sep 2026). Test visibility on a sample before any bulk load.
Attachments and links
Attachments move after their parent records exist, so plan them as their own workstream to prevent a lost attachment flood at cutover. Links between incidents, problems, changes and CIs are rebuilt from a cross-reference of old and new record IDs, so keep that table for the whole project. CI relationships need the same treatment, and how the ServiceNow CMDB stores CIs and relationships shows how much depends on them.
Platform limits to plan around
Each platform caps something: export size, API calls per minute or work items per import file. If the target is still open, ServiceNow vs Jira Service Management and Freshservice vs ServiceNow cover the platform choice; this table covers the data.
| Platform | Getting data out | Getting data in | Watch for |
|---|---|---|---|
| ServiceNow | UI exports stop at 10,000 records per format by default (ServiceNow, as of 29 Sep 2026). The Table API pages with sysparm_limit (default 10,000) and sysparm_offset (ServiceNow, as of 29 Sep 2026) | Import sets with coalesce fields: a match updates, no match inserts (ServiceNow, as of 29 Sep 2026) | If several target records match, only the first is updated (same source) |
| Jira Service Management Cloud | Cloud backups exclude automation flows, Assets, Opsgenie-powered features and app data (Atlassian, as of 29 Sep 2026) | CSV import, about 1,500 work items per file recommended (Atlassian, as of 29 Sep 2026) | CSV-imported comments become public; SLAs calculate from issue history |
| Freshservice | Ticket exports capped at 10,000 per export; full conversations need the API or an account-wide XML export (Freshservice, as of 29 Sep 2026). API limits run from 100 to 500 calls per minute by plan (Freshservice, as of 29 Sep 2026) | Bulk migration APIs for data migration partners: tickets and notes, 50 per request, 10 requests per minute, 40 MB of attachments per entity (Freshservice, as of 29 Sep 2026) | Approved migrations can run at 700 calls per minute for a scheduled future window (Freshservice, as of 29 Sep 2026) |
The ITSM migration plan in six phases
An ITSM migration plan runs in six phases, and each ends with an exit criterion. Do not start the next phase until it is met.
1. Discover
Inventory records, configuration and integrations. Agree the history option, the freeze window and who signs off, and name one project lead who owns the migration end to end. Exit: a signed scope with baseline record counts.
2. Map
Write the mapping sheets and build the target workflows, SLA definitions and automations in parallel, because the mapping needs targets to point at. Exit: mapping signed off by the process owners.
3. Test migration
Run a full or representative load into a non-production target. Check counts, open samples in each state, and have agents confirm that notes, attachments and links look right. Exit: a test run that passes reconciliation without manual fixes.
4. Cutover with delta sync
Load the historical bulk ahead of cutover. In the freeze window, stop changes on the source and run a delta sync for records created or updated since the bulk load. The load must be safe to re-run, updating records instead of duplicating them, as ServiceNow's coalesce fields do (ServiceNow, as of 29 Sep 2026). Hold a go/no-go with named criteria before switching intake channels. Exit: go decision recorded; email, portal and integrations point at the target.
5. Reconcile
Compare target counts with source counts per record type and state. Spot-check samples end to end: fields, notes and their visibility, attachments, timestamps, and links to problems, changes and CIs. Log every difference with a cause and a fix. This is where data fidelity is proven, record by record, rather than assumed. Exit: reconciliation report signed off.
6. Hypercare
Keep the migration team on call while agents settle in. Watch for SLA breaches on migrated records, missing attachments and broken links, and fix each pattern at its cause. Keep the old platform read-only or archived, as the phase 1 history decision says. Exit: hypercare closed and source retirement approved.
Common service desk migration failure points
Each is cheaper to catch in the phase shown than after go-live. For the wider risk register, including deal-stage and budget risks, see help desk migration risks to plan for.
| Failure point | How it shows up | Phase that should catch it |
|---|---|---|
| Unmapped states or priorities | Closed tickets reopen, critical incidents land as low | Map |
| Internal notes exposed | Requesters see agent-only work notes | Test migration |
| SLA clocks running on closed records | Breach reports fill with historic tickets | Test migration |
| Duplicates after re-runs | Delta sync inserts instead of updating | Test migration |
| Missing links | Incidents lose their problem, change or CI | Reconcile |
| No home for old records | Auditors ask for a ticket nobody can open | Discover |
ITSM migration checklist
- Name a migration owner, and sign-off owners for audit, reporting and each process.
- Record baseline counts per record type and state on the source.
- Choose full history, active only, or archive plus selective migration, in writing.
- Confirm export and API limits on the source and import limits on the target.
- Build target workflows, SLA definitions and automations before mapping is final.
- Map states, priorities (impact and urgency), categories and custom fields.
- Decide how inactive users and deleted groups are represented.
- Define how internal and public notes keep their visibility.
- Keep a cross-reference table of old and new record IDs.
- Run test migrations until reconciliation passes without manual fixes.
- Confirm the load can be re-run for delta sync without duplicates.
- Agree the freeze window, go/no-go criteria and rollback point.
- Plan hypercare coverage and the date the source becomes read-only or archived.
ITSM migration FAQ
Methodology
We built this guide from ServiceNow, Atlassian, Freshworks and Ivanti documentation, plus two named third-party sources: itsm.tools for history-scoping options and StrataCom for the Cherwell date. All sources were checked on 29 September 2026. We did not run hands-on tests. We quote no migration durations or costs, because they depend on your volumes, history decision and freeze window.
Disclosure: MigrateX, the publisher of this article, runs ITSM data migrations, including between platforms named here. No vendor reviewed or paid for this article.