Methodology: built from ServiceNow product documentation, Atlassian and Ivanti vendor pages, ServiceNow's own analyst reports page, G2 reviews and one attributed consultancy source, checked on 28 and 29 Sep 2026. No vendor reviewed or paid for this article. We did not run hands-on tests.
A ServiceNow migration moves your service history into or out of ServiceNow: incidents, service requests, problems, changes, knowledge articles, configuration items (CIs) and the links between them. Workflows, business rules, SLA definitions and running SLA timers do not move. They are rebuilt on the target.
You are probably here because a platform decision has been made and someone has to bring years of tickets across, or because a ServiceNow renewal has started a conversation about ServiceNow alternatives. This guide covers both directions and focuses on what decides the outcome: mapping, cutover and reconciliation.
Key takeaways
- Update sets move configuration between ServiceNow instances. They do not carry incidents, users or CIs (ServiceNow, as of 28 Sep 2026).
- ServiceNow caps list exports at 10,000 records per format (CSV, XML, JSON, Excel) by default (ServiceNow, as of 28 Sep 2026).
- SLA repair rebuilds task SLAs from the task's history, so SLA reporting depends on the history you import (ServiceNow, as of 28 Sep 2026).
- Coalesce fields make a re-run update existing records instead of duplicating them, which is what makes delta sync possible (ServiceNow, as of 28 Sep 2026).
Why teams start a ServiceNow migration in 2026
Most ServiceNow migrations in 2026 start with a dated vendor decision, such as Atlassian's Data Center end of life or Cherwell's discontinuation, or with renewal pressure on ServiceNow itself.
| Trigger | Direction | What the source says |
|---|---|---|
| Atlassian Data Center end of life | Into ServiceNow (or other platforms) | No new-customer sales after 30 March 2026; no expansions after 30 March 2028; Data Center products, including Jira Service Management, go read-only on 28 March 2029 (Atlassian, as of 28 Sep 2026) |
| Cherwell end of life | Into ServiceNow (or other platforms) | Ivanti says Cherwell products have been discontinued (Ivanti, as of 28 Sep 2026) |
| Analyst position | Into ServiceNow | ServiceNow says it is a Leader in the 2026 Gartner Magic Quadrant for IT Service Management Platforms (ServiceNow, as of 29 Sep 2026), a report published 27 July 2026 (ServiceNow, as of 29 Sep 2026) |
| Cost and complexity | Out of ServiceNow | G2 reviewers rate ServiceNow ITSM 4.5/5 (1,986 reviews); top cons are a steep learning curve and high licensing and implementation costs (G2, as of 28 Sep 2026) |
Ivanti's public page gives no Cherwell date. StrataCom, an ITSM consultancy and former Cherwell partner, reports 31 December 2026 (StrataCom, as of 28 Sep 2026). Confirm your date with Ivanti.
If you are leaving, ServiceNow pricing is usually part of the story. ServiceNow lists three ITSM packages (ITSM Foundation, ITSM Advanced, ITSM Prime) and quotes prices on request (ServiceNow, as of 28 Sep 2026).
Before you start: scope and inventory for a ServiceNow data migration
Data migration is not instance or cloud migration
"ServiceNow migration" can mean three different jobs: moving records between ITSM platforms, moving configuration between ServiceNow instances, or moving servers and applications to the cloud. This guide covers the first, for ServiceNow specifically. For the platform-neutral version, see our ITSM migration guide.
- Data migration between platforms. Records move from Jira Service Management, Cherwell, Freshservice or another tool into ServiceNow, or the other way.
- Configuration between ServiceNow instances. Update sets handle this, and they exclude incidents, users and CIs (ServiceNow, as of 28 Sep 2026).
- Cloud workload migration. Servers and applications move to the cloud. ServiceNow treats this as a separate topic (ServiceNow, as of 28 Sep 2026).
Inventory what you have
Count every record type before planning: incidents, requests and requested items, problems, changes, knowledge articles, CIs and relationships, users, groups, attachments and journal entries. Count per state as well as totals. Reconciliation needs both. The same pass is a good time to audit legacy help desk data before the migration, so duplicates and dead categories are not carried across.
Then decide how much history moves: all of it, everything after a cut-off, or a cut-off plus a read-only archive. Make this call with your audit and compliance owners.
Leaving ServiceNow? Plan extraction by API
To extract full history from ServiceNow, use the Table API, not list exports. List exports stop at 10,000 records per format by default, and ServiceNow advises splitting larger exports (ServiceNow, as of 28 Sep 2026). The Table API returns up to 10,000 records per request by default and pages with sysparm_limit and sysparm_offset (ServiceNow, as of 28 Sep 2026). Pull both stored and display values (sysparm_display_value=all), because choice fields store codes that mean nothing outside ServiceNow.
What moves, what gets rebuilt, what's at risk in a ServiceNow migration
In a ServiceNow migration, records and their history move as data, while the logic that acted on them (flows, business rules, SLA definitions and timers) is rebuilt on the target. Agree this table with stakeholders before anyone writes a transform map.
| What moves (as data) | What gets rebuilt (not migrated) | What's at risk |
|---|---|---|
| Incident, request, problem and change records with their field values | Flows, workflows and business rules | SLA history, because repair can only use the task history you import |
| Journal entries, kept as work notes or additional comments | SLA definitions, schedules and running SLA timers | Internal notes landing in customer-visible comments |
| Attachments, one file per API request, up to a 1,024 MB default maximum (ServiceNow, as of 28 Sep 2026) | Priority lookup rules and assignment rules | References to users or groups not yet loaded |
| Knowledge articles; Word .doc and .docx imports keep tables, lists and links (ServiceNow, as of 28 Sep 2026) | Notifications, templates and macros | Images, custom heading numbers and table styling in imported articles |
| CIs, loaded through the Identification and Reconciliation Engine (IRE) | Catalog items and record producers | Duplicate CIs when loads bypass IRE identification rules |
| CI relationships (parent, child, type) | CMDB health and data-certification rules | Incident, problem, change and CI links dropped in mapping |
| Users, groups and locations as reference data | Integrations and inbound email actions | Source statuses that have no matching ServiceNow state |
The middle column is configuration work on the target. It belongs in the project plan, not the migration scope. The right column is where reconciliation should focus, because these are the data fidelity losses that rarely raise an error. For how CIs and their relationships are modeled on the target, see the ServiceNow CMDB guide.
ServiceNow migration field mapping essentials
Inbound data usually lands through import sets: an import set stages the incoming data, and a transform map defines how each staged field maps to a target table such as Incident or User (ServiceNow, as of 28 Sep 2026). These mappings go wrong most often.
| Area | ServiceNow target | What to watch |
|---|---|---|
| States | Incident states: New, In Progress, On Hold, Resolved, Closed, Canceled. On Hold reasons: Awaiting Caller, Awaiting Change, Awaiting Problem, Awaiting Vendor (ServiceNow, as of 28 Sep 2026) | Map every source status. "Waiting for customer" needs an On Hold reason, not just a state |
| Priority matrix | Priority is derived from impact and urgency through lookup rules, and the Priority field is read-only unless its UI policy is disabled (ServiceNow, as of 28 Sep 2026) | Import impact and urgency, then sample-check computed priority against the source |
| Users and groups | User, group and location tables | Load first. If a referenced sys_id does not exist, it can land in the target as the display value (ServiceNow, as of 28 Sep 2026) |
| Public vs internal notes | Additional comments (customer-visible) and work notes (internal) | Never merge them. Keep original author and timestamp in the entry text if needed |
| Attachments | Attachment API, one file per request (ServiceNow, as of 28 Sep 2026) | Check file sizes and extensions against target limits |
| Links and CIs | CI relationships stored in the CI Relationship table as parent, child and relationship type (ServiceNow, as of 28 Sep 2026) | Load CIs through IRE (it applies to import sets), then relationships, then task-to-CI links (ServiceNow, as of 28 Sep 2026). Align CI classes to the Common Service Data Model (ServiceNow, as of 28 Sep 2026) |
One setting decides whether re-runs are safe: coalesce. Coalesce marks the transform-map fields ServiceNow uses to match incoming rows to existing records. A match updates the existing record; no match inserts a new one. Coalesce only on unique fields, because if several records match, only the first is updated (ServiceNow, as of 28 Sep 2026). Store the source ticket ID in a dedicated field and coalesce on it.
The ServiceNow migration plan in phases
A ServiceNow migration plan has six phases: discover, map, test migration, cutover with delta sync, reconcile and hypercare. Each phase ends with something a named owner signs. Durations depend on your volumes, integrations and freeze window.
- Discover. Finish the inventory, the history-depth decision and owners per record type. Shortlist freeze windows.
- Map. Produce field and value mappings for states, priority, categories, assignment groups and notes visibility, signed by process owners. Build the rebuild list in parallel.
- Test migration. Run a full load into sub-production, not a sample, and reconcile it as you will in production. Run SLA repair on imported tickets and compare results with the source.
- Cutover with delta sync. Load bulk history before the freeze. In the freeze window, re-run the load for records changed since; the coalesce key makes it update rather than duplicate. Then hold go/no-go against agreed reconciliation thresholds.
- Reconcile. Compare counts per record type and state, sampled field values, attachments, relationships and journal entries. Spot-check SLA results. Get sign-off. If a partner provides your ServiceNow migration services, vet how they prove what moved and agree the reconciliation report format before the work starts.
- Hypercare. Watch for wrong assignment groups, priority mismatches and missing attachments after cutover. Keep the source read-only so agents can check history.
Common ServiceNow migration failure points
These failures usually do not stop a load. The migration looks finished, and the missing, duplicated or wrong records only show up in reconciliation, or later in hypercare. For risks that apply to any platform, see help desk migration risks to plan for.
- Coalescing on a non-unique field. When several target records match, only the first is updated, so the rest never receive the migrated values (ServiceNow, as of 28 Sep 2026).
- Loading tickets before users and groups. Caller and assignment group references break, because a missing referenced record can land as a display value (ServiceNow, as of 28 Sep 2026).
- Truncated extracts. A list export stops at the 10,000-record default. Always compare extracted row counts with the source count (ServiceNow, as of 28 Sep 2026).
- SLA definitions firing on historical records. If definitions are active during the load, test whether they attach to imported tickets, and decide how historical SLA results are handled.
- Dot-walked SLA conditions. SLA repair uses only the final state of dot-walked fields, not their history (ServiceNow, as of 28 Sep 2026).
- CIs loaded outside IRE. Direct writes skip the identification rules that prevent duplicate CIs (ServiceNow, as of 28 Sep 2026).
ServiceNow migration checklist
Use these 12 steps in either direction, into or out of ServiceNow.
- Confirm direction, record types, sources and target.
- Count every record type, by state, in the source.
- Get the history-depth decision signed by your audit or compliance owner.
- Write the rebuild list: workflows, business rules, SLA definitions, notifications, priority rules.
- Load users, groups and locations before any ticket data.
- Get state, On Hold reason and priority mappings signed off.
- Choose a unique coalesce key for every target table.
- Map public comments to additional comments and internal notes to work notes.
- Check attachment sizes and file types against the target's limits.
- Load CIs through IRE, then relationships, then task-to-CI links, aligned to CSDM.
- Run a full test migration on sub-production and produce a reconciliation report.
- Write the cutover runbook: freeze window, delta sync, go/no-go criteria, rollback and hypercare owners.
ServiceNow migration FAQ
Methodology
We built this guide from ServiceNow documentation (Brazil, Australia and Zurich releases), Atlassian and Ivanti pages, ServiceNow's analyst reports page and G2 reviews; one date comes from a named consultancy. Sources were checked on 28 September 2026, and the Gartner placement on 29 September 2026. We did not run hands-on tests. We quote no migration durations or costs, because they depend on your volumes 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.