Methodology: built from vendor documentation (ServiceNow, Atlassian, Freshworks, Zendesk, BMC Helix), Vendr, itsm.tools and the AICPA, checked on 9 Oct 2026. No vendor reviewed or paid for this article. We did not run hands-on tests.
ITSM data migration services move a service desk's records from one platform to another and prove they arrived intact. A good provider maps your data, runs a test migration, cuts over with a delta sync, reconciles the result and stays through hypercare. Most results for "data migration services" cover database and cloud moves. This guide covers ITSM records: incidents, requests, problems, changes, knowledge, CIs, relationships, SLA history and attachments. It is for Heads of Service Management and platform owners who need outside help and want to know how to judge a provider.
Key takeaways
- Vendor import tools are narrow by design. Atlassian says CSV import "isn't a recommended migration method," and its Jira Cloud Migration Assistant is for Server or Data Center to Cloud only (Atlassian docs, as of 9 Oct 2026).
- Platform limits shape the plan: ServiceNow's Table API returns 10,000 records per request by default (ServiceNow docs), and a Freshservice ticket export stops at 10,000 tickets (Freshservice support, both as of 9 Oct 2026).
- Configuration does not travel with data. ServiceNow update sets "exclude task or process data" (ServiceNow docs, as of 9 Oct 2026), so workflows, business rules, SLA definitions and running SLA timers are rebuilt on the target.
- There is no neutral public benchmark for price or duration. Vendor estimates for their own routes run from 4 to 12 weeks (Freshworks) to 14 to 20 weeks (BMC Helix), as of 9 Oct 2026.
What ITSM data migration services include
ITSM data migration services are a managed project that extracts service desk records from one platform, reshapes them for the target's data model, loads them with their history and links, and verifies the result before sign-off. Success means an agent opens a five-year-old incident on the new platform and sees the same notes, attachments, links and CI as before.
The scope usually covers:
- Incidents, service requests (with catalog answers), problems and changes, with work notes and public comments kept apart
- Knowledge articles, including inline images
- CIs, CI relationships and ticket-to-CI links
- Users, groups and assignment history
- Attachments, plus field history where the target can store it
- SLA history: the recorded outcomes, not the live clocks
An ITSM provider has to know what a record means on each platform. Freshservice's ticket API accepts only the incident type, while service requests have their own endpoint (Freshservice API docs, as of 9 Oct 2026). Comments imported into Jira Service Management by CSV become public (Atlassian docs, as of 9 Oct 2026).
DIY scripts vs vendor import tools vs a specialist provider
Each route can work; the choice depends on volume, history and how many relationships must survive.
| DIY scripts | Vendor-native import tools | Specialist ITSM migration services | |
|---|---|---|---|
| Who runs it | Your engineers | Your admins | An outside team, with your sign-off |
| Best fit | Small scope, strong in-house API skills | Same-vendor moves or simple flat imports | Cross-platform moves with history, links and a fixed cutover window |
| History, links, attachments | Only what you code and test | Often partial; check each record type | Should be stated per record type in the SOW |
| Test migration, delta sync, reconciliation | You design all three | Rarely built in | Should be standard deliverables |
| Main risk | Maintenance and untested edge cases | Silent gaps (public comments, open SLAs, lost links) | Choosing on price or a badge instead of evidence |
The vendor docs show why native tools rarely cover a cross-platform move alone:
- ServiceNow. The Table API defaults to 10,000 records per request and larger pulls must page (ServiceNow Table API docs, as of 9 Oct 2026). List exports stop at 10,000 records per export (ServiceNow export limits docs, as of 9 Oct 2026).
- Jira Service Management. Atlassian recommends about 1,500 work items per CSV file, each taking about an hour, and statuses can only map to existing workflow statuses (Atlassian CSV import docs, as of 9 Oct 2026).
- Freshservice. Ticket exports leave out conversations; Freshworks points to the API or an account XML export for full history, and its Data Migration help folder holds two articles, both for migration partners (Freshservice support, as of 9 Oct 2026).
- Zendesk as a source. Zendesk says Support has no full export for attachments, and private attachment links expire quickly (Zendesk help center, as of 9 Oct 2026).
Atlassian's switching advice is to "Seek migration support from a partner" (Atlassian blog, 5 Aug 2024). Vendr reports that most ServiceNow buyers "require professional services to configure workflows, integrate with existing systems, and migrate data" (Vendr, as of 9 Oct 2026).
What moves, what gets rebuilt, what's at risk
Data moves. Configuration is rebuilt. "Migrating your workflows" really means recreating them on the target, which is separate work with its own testing.
| Moves (data) | Gets rebuilt (configuration) | At risk (needs explicit handling) |
|---|---|---|
| Incidents, requests, problems, changes | Workflows and business rules | Original created and resolved dates |
| Work notes and public comments | Automations and notifications | Internal notes turning public |
| Knowledge articles | SLA definitions and priority matrix | Running SLA timers on open tickets |
| CIs and CI relationships | Assignment rules and catalog forms | Incident, problem, change and CI links |
| Users, groups, attachments | Roles, reports and dashboards | Inline images and expired attachment URLs |
Vendors document the rebuild column. Atlassian says "all migrated automation flows are disabled on the cloud by default post migration," and its migration assistant does not move canned responses, mail handlers or knowledge articles linked to service projects (Atlassian docs, as of 9 Oct 2026).
SLA history breaks quietly. Jira Service Management "calculates SLA based on the issue history," so closed issues imported by CSV can keep counting (Atlassian KB, as of 9 Oct 2026). ServiceNow's SLA repair "uses the history from the Task" (ServiceNow docs, as of 9 Oct 2026). Without history, the target cannot rebuild what it never saw.
How an ITSM data migration runs, phase by phase
A credible provider runs the move as a controlled change, with an output you can check at each phase.
1. Discover
Inventory record types, counts per year, attachments, custom fields, integrations and history in scope. Output: a scoped inventory you sign.
2. Map
Every field, state, priority, group and user gets a target value, including values with no match. Output: a mapping document you can read without a developer.
3. Test migration
Data goes into a non-production target and your service desk leads check real tickets. Output: a defect list and fixes.
4. Cutover with delta sync
The bulk load runs before the freeze; at cutover only new or changed records move. Atlassian "can't provide an exact estimation of downtime" for its own migrations (Atlassian docs, as of 9 Oct 2026), so ask how the provider sizes the window. On Freshservice, the partner Bulk API guide says workflows and business rules are not muted during migration (Freshservice support, as of 9 Oct 2026). Output: a runbook with go/no-go points and rollback.
5. Reconcile
Compare counts by type, state and year; sample links, attachments and notes. Output: a reconciliation report both sides sign.
6. Hypercare
The provider stays on call, fixing gaps before the source goes read-only. Output: closed issue log, sign-off.
10 questions to ask a data migration services provider
ServiceNow's partner workbook suggests narrowing a shortlist to "two to three partner candidates for final evaluation" (ServiceNow, Mar 2021). Ask these at that stage. MigrateX sells this service too, so apply every question to us as well.
- Security and data handling. Can we see the SOC 2 report itself? A SOC 2 examination covers controls relevant to "security, availability, processing integrity, confidentiality, or privacy" (AICPA, as of 9 Oct 2026), so check the scope and period. Where does our data sit in transit, and how is it deleted?
- Test migration. Will you run one on our real data before the full load, and who on our side reviews it?
- Reconciliation report. What does it compare, and can we see a redacted example?
- Delta sync. How do you catch records changed after the bulk load, and how long will the final delta take at our volume?
- Attachments and inline images. How do you handle inline images, files over the target's size limit and expiring source URLs?
- Relationships. Which links do you rebuild: parent and child, incident to problem, problem to change, ticket to CI, CI to CI?
- User mapping. What happens to tickets owned by leavers, merged accounts and requesters missing on the target?
- History and timestamps. Do original dates survive on our target, and where are they stored if the API will not accept them?
- Rollback. If go/no-go fails during cutover, what are the steps back, and who decides?
- Sign-off. What does sign-off mean in the contract, how long is hypercare, and what is fixed free after go-live?
Warning signs when choosing a provider
A provider that cannot show evidence before you sign will not produce it after.
| Warning sign | What to ask for instead |
|---|---|
| "Zero data loss" or "no downtime" with no conditions | The conditions, plus a sample reconciliation report |
| No test migration in the plan | A test load on real data with your reviewers |
| Workflows and SLAs listed as "migrated" | A separate rebuild scope and test plan |
| A badge instead of a report | The security report and a data handling summary |
| Fixed price before discovery | A discovery phase, then a priced statement of work |
| No rollback step | A written rollback with a named decision owner |
What drives the cost and duration of ITSM migration services
There is no neutral public benchmark for what ITSM migration services cost or how long they take. The published durations are vendor estimates for single routes: Freshworks says ServiceNow to Freshservice "timelines typically range from 4-12 weeks," and BMC Helix lists an estimated 14 to 20 weeks for its Remedy to hosted BMC Helix ITSM service (both as of 9 Oct 2026).
What moves the number:
- Volume and history depth: years of tickets, notes and attachments in scope
- Relationships: linked tickets and CIs need more mapping and testing than flat records
- Platform limits: paging, rate limits and export caps on both sides
- Customization: source fields, states and catalog items with no target equivalent
- Rebuild scope: whether workflows, SLAs and automations are included
- Testing and cutover: test cycles, freeze window length and hypercare
Some teams archive older records. itsm.tools recommends a searchable archive of the old system plus migrating only what the new platform needs, and calls full historical migration "expensive, risky" (itsm.tools, 20 Apr 2026). Weigh that against audit, reporting and AI needs.
ITSM data migration services checklist
- Count every record type in scope, by year.
- Decide how much history moves and where the rest is archived.
- Name an internal owner for mapping decisions and sign-off.
- Shortlist providers and request a statement of work per phase.
- Ask for the security report and a data handling summary.
- Agree field, state, priority, user and group mapping in writing.
- Confirm handling of notes visibility, attachments, inline images and links.
- Separate rebuild scope (workflows, SLAs, automations) from data scope.
- Run a test migration on real data and log defects.
- Mute automations and notifications on the target before loading.
- Agree the freeze window, delta sync, go/no-go points and rollback.
- Sign off on a reconciliation report, then start hypercare.
FAQ
Methodology
We read the top three results for "data migration services" and vendor documentation from ServiceNow, Atlassian, Freshworks, Zendesk and BMC Helix on 9 Oct 2026. Vendr and itsm.tools views are attributed. We did not run hands-on tests or contact providers. Disclosure: MigrateX, the publisher of this article, runs ITSM data migrations, including between platforms named here. No vendor reviewed or paid for this article.