Methodology: built from Atlassian and ServiceNow docs, licensing and pricing pages, plus one attributed industry source, checked on 5 Oct 2026. No vendor reviewed or paid for this article. We did not run hands-on tests.
A Jira to ServiceNow migration moves Jira Service Management (JSM) incidents, requests, problems, changes, comments, attachments and Assets objects into ServiceNow tables through import sets, transform maps and the Attachment API. Workflows, automation rules and SLA definitions do not move; you rebuild them. If you run JSM Data Center, Atlassian's end-of-life dates set the clock. If you are consolidating, the hard part is keeping comment visibility, CIs and ticket links intact.
Key takeaways
- Atlassian makes Data Center products read-only on 28 Mar 2029, JSM Data Center included (Atlassian Data Center end-of-life page, as of 5 Oct 2026).
- Jira Cloud's CSV export stops at 10,000 work items, and Jira Cloud backups leave out Assets (Atlassian support docs, as of 5 Oct 2026).
- JSM internal notes belong in work notes, because in ServiceNow "all users who can view incidents see additional comments" (ServiceNow incident docs, as of 5 Oct 2026).
- ServiceNow's Attachment API takes one file per request, 1,024 MB by default (ServiceNow API docs, as of 5 Oct 2026); Jira Cloud allows files up to 2 GB (Atlassian support docs, as of 5 Oct 2026).
Why teams move from Jira Service Management to ServiceNow in 2026
Two kinds of trigger drive a Jira Service Management migration to ServiceNow: a dated Atlassian event, or a decision to consolidate.
| Atlassian trigger | Date | Source (checked 5 Oct 2026) |
|---|---|---|
| Data Center: no new-customer sales | 30 Mar 2026 | Atlassian end-of-life page |
| Data Center: last purchases for existing customers | 30 Mar 2028 | Atlassian end-of-life page |
| Data Center: read-only | 28 Mar 2029 | Atlassian end-of-life page |
| Cloud list price update, JSM included | 13 Oct 2026 | Atlassian pricing FAQ |
| Confluence Cloud XML export end of life | 1 Dec 2026 | Atlassian knowledge base |
| Opsgenie shutdown | 5 Apr 2027 | Atlassian Opsgenie page |
Consolidation is the second driver: a separate JSM instance means a second CMDB, change calendar and reporting stack. ServiceNow puts Service Catalog, Incident and CMDB in ITSM Foundation and adds Change and Problem in ITSM Advanced. Its pricing page shows "Get Custom Quote" instead of list prices (ServiceNow ITSM pricing page, as of 5 Oct 2026).
What moves, what gets rebuilt, what's at risk
A Jira to ServiceNow migration moves data, not behavior.
| Moves (as data) | Gets rebuilt on ServiceNow | At risk if unplanned |
|---|---|---|
| Incidents, requests, problems, changes | Workflows and status transitions | Internal vs public comment visibility |
| Comments with author and timestamp | Request types, as catalog items or record producers | Running SLA timers and elapsed time |
| Attachments | Automation rules, SLA goals and calendars | Files above ServiceNow's size limit |
| Assets objects, as CIs | Queues, dashboards and reports | Ticket-to-CI links |
| Assets references, as CI relationships | Priority matrix, as impact and urgency rules | Assets object history |
| Users, groups, organizations, knowledge | Approvals, notifications and portal | Knowledge article formatting |
Workflows, automations, business rules, SLA definitions, macros and running SLA timers are rebuilt on the target, not migrated.
Jira Service Management to ServiceNow field mapping
Each JSM work type needs a ServiceNow target table before field mapping starts.
| Jira Service Management | ServiceNow target |
|---|---|
| Incident work items | Incident |
| Service request work items | Requested item or record producer task |
| Problem and change work items | Problem and Change Request |
| Request type | Catalog item or record producer |
| Status | State |
| Priority | Impact and Urgency |
| Internal note / reply to customer | Work notes / additional comments |
| Reporter, assignee, team | Caller, Assigned to, Assignment group |
| Organization | Company or group |
| Linked work items | Problem, Change Request, Caused by Change |
| Assets object field | Configuration item, affected CIs |
Request types, statuses and resolutions
ServiceNow defines a record producer as "a specific type of catalog item that allows end users to create task-based records, such as incident records" (ServiceNow catalog docs, as of 5 Oct 2026). Map request types that raise incidents to record producers and fulfillment request types to catalog items, keeping the old name in a field.
Jira groups statuses into three categories: To do, In progress and Done. ServiceNow incidents use six states: New, In Progress, On Hold, Resolved, Closed and Canceled (Atlassian and ServiceNow docs, as of 5 Oct 2026). Map each status by name, not category, and route Jira's Done, Won't do and Duplicate resolutions to Closed or Canceled on purpose.
Priority: impact and urgency
Jira ships five default priorities, Highest to Lowest (Atlassian support docs, as of 5 Oct 2026). ServiceNow derives priority from impact and urgency, and the field is read-only by default (ServiceNow incident docs, as of 5 Oct 2026). Map each Jira priority to an impact and urgency pair and test it against your lookup rules.
Comments: internal notes to work notes
JSM stores each comment as internal or public; Atlassian's Data Center knowledge base shows internal comments carry the property value {"internal":true} (as of 5 Oct 2026). In ServiceNow, every user who can view an incident sees additional comments. Work note notifications go only to the work notes list (ServiceNow incident docs, as of 5 Oct 2026). Read the flag on every comment and write it to the matching journal field.
Users, attachments and links
Atlassian calls JSM organizations "groups of customers who can request help from you" (Atlassian support docs, as of 5 Oct 2026). Choose companies or groups early. Load users and groups before tickets: a missing reference sys_id may land as a display value (ServiceNow transform map docs, as of 5 Oct 2026).
List every Jira file above ServiceNow's attachment limit during discovery. Jira links become reference fields: the incident form carries Problem, Change Request and Caused by Change (ServiceNow incident docs, as of 5 Oct 2026), so load problems and changes first.
SLA history
JSM displays remaining SLA time by default; Atlassian's workaround copies elapsed time into fields with automation so it can be exported (Atlassian knowledge base, as of 5 Oct 2026). ServiceNow's SLA repair "uses the history from the Task" (ServiceNow SLA docs, as of 5 Oct 2026), so store closed-ticket SLA outcomes as data and test repair on imported records before trusting it.
Assets to CMDB: moving CIs and relationships
Object types become CI classes, objects become CIs and references become relationship rows. These steps draw on Atlassian's Assets docs and ServiceNow's CMDB docs, checked 5 Oct 2026.
- Export each object type in "data consistent" format, which stores referenced objects as keys, users as account IDs and dates as Unix timestamps.
- Map object types to CMDB classes. Pick the most specific class: a laptop class extends computer, which extends the base CI class.
- Load CIs through the Identification and Reconciliation Engine. ServiceNow says IRE "prevents duplicate CIs," can run on import set data and can identify CIs by source_name and source_native_key. Use the Assets key as the native key.
- Rebuild references as relationships. Each Assets reference becomes a cmdb_rel_ci row with a parent CI, child CI and relationship type.
- Relink tickets to CIs. Affected CIs are a many-to-many relationship between Task and CMDB tables, so the Assets object field becomes a Configuration item plus affected CI rows.
On Data Center, an object schema export excludes object history and comments and connected Jira tickets (Atlassian Data Center docs, as of 5 Oct 2026). If auditors need CI change history, archive it before the source goes read-only.
Export from Jira Service Management, import into ServiceNow
Atlassian has no tool for this direction: the Jira Cloud Migration Assistant is for "migrations from Server or Data Center to Cloud" (Atlassian support docs, as of 5 Oct 2026). You read JSM through exports and REST APIs and write into ServiceNow through import sets.
| Side | Mechanism | Documented limit or behavior | Source (checked 5 Oct 2026) |
|---|---|---|---|
| Jira Cloud | CSV export | 10,000 work items per export; split by JQL | Atlassian knowledge base |
| Jira Data Center | Filter export | 1,000 issues by default | Atlassian knowledge base |
| Jira Cloud | Site backup | 25 GB data; 48 hours between backups with attachments; no Assets | Atlassian support docs |
| ServiceNow | Table API | sysparm_limit default 10,000; paginate with sysparm_offset | ServiceNow API docs |
| ServiceNow | Import Set API | Staging table, then transform map; insertMultiple asynchronous by default | ServiceNow API docs |
| ServiceNow | Attachment API | One file per request; 1,024 MB default | ServiceNow API docs |
| ServiceNow | Knowledge import | Word files; heading numbers and table borders dropped | ServiceNow knowledge docs |
Set a coalesce field on the Jira key in every transform map. A match is updated and no match creates a record, but if several records match, only the first is updated (ServiceNow import set docs, as of 5 Oct 2026). Reruns and delta loads stay safe only while the key is unique.
Knowledge takes its own path, because the JSM knowledge base is built by linking Confluence spaces (Atlassian support docs, as of 5 Oct 2026).
What really drives effort and cost in this pair
No neutral public price exists for this migration. These drivers set the effort, and ticket count is only one.
- Files, not tickets. The Attachment API moves one file per request, so file count sets the load window more than work item count does.
- Data Center export caps. Filter exports return 1,000 issues by default, and Atlassian warns that raising the limit risks an OutOfMemoryException (Atlassian knowledge base, as of 5 Oct 2026). More batches mean more files to merge and reconcile.
- Configuration, not migration. Every request type becomes a catalog item or record producer with its own variables, and every automation rule and SLA goal is rebuilt. Give it its own owner.
- CMDB depth. The number of Assets object types and reference types sets the class-mapping and relationship work.
- History scope. itsm.tools author Brian Parks describes three options (full history, active work only, or archive the past and migrate what matters) and recommends the third (itsm.tools, as of 5 Oct 2026).
- Licensing overlap. Atlassian cloud list prices change on 13 Oct 2026 for renewals (Atlassian pricing FAQ, as of 5 Oct 2026). Line up cutover with your renewal date.
On day one, agents stop setting priority directly, Jira keys give way to ServiceNow numbers (keep the Jira key searchable), and requesters meet catalog items instead of request types.
The migration plan in phases
1. Discover
Count work items, comments, attachments, Assets objects and references per project. Agree the history scope with audit and reporting owners.
2. Map
Turn the tables above into a signed mapping document: table, state, priority, comment visibility, organization and CMDB class.
3. Test migration
Load a full copy into sub-production and open records by hand for every work type. A ServiceNow employee's Community article says staging data older than seven days is cleared (as of 5 Oct 2026), so review each load promptly.
4. Cutover with delta sync
Run the bulk load before the freeze window. At cutover, export only work items updated since the bulk load, run them through the same coalescing transform maps, then hold the go/no-go.
5. Reconcile
Compare counts per table and state, comments by visibility, attachments and CI relationships. Table API reads with sysparm_display_value=all return actual and display values (ServiceNow API docs, as of 5 Oct 2026), which exposes references stored as text.
6. Hypercare
Keep JSM read-only and fix missing comments or wrong CIs with targeted reruns.
Pair-specific failure points
- Internal notes go public when every comment lands in additional comments.
- Priority changes on load because ServiceNow derives it from impact and urgency.
- References stored as text when users or groups load after tickets.
- Duplicates after a rerun when the coalesce key is not unique.
- Large files missing when Jira attachments exceed ServiceNow's limit.
- Lost staging evidence when nobody reviews import rows in time.
- Data Center exports cut short by the default export cap.
- CIs without history because Data Center schema exports leave it out.
Jira to ServiceNow migration checklist
- Confirm your Atlassian dates and next renewal.
- Agree the history scope and where the archive lives.
- Count work items, comments, attachments and Assets objects.
- List files above ServiceNow's size limit.
- Map work types to tables and request types to catalog items or record producers.
- Map statuses to states, resolutions to Closed or Canceled, and priorities to impact and urgency pairs.
- Map internal notes to work notes, public replies to additional comments.
- Load users, groups and companies before tickets.
- Load Assets through IRE and rebuild references in cmdb_rel_ci.
- Set a unique coalesce key on every transform map.
- Run and reconcile a full test migration before booking the freeze window.
- Run the delta sync, reconcile again and hold the go/no-go.
FAQ
Methodology
We built this guide from Atlassian and ServiceNow documentation, knowledge base, pricing and licensing pages, one ServiceNow employee community article and one attributed industry source (itsm.tools), checked on 5 Oct 2026. We read top-ranking pages for the keyword to find gaps but did not cite them, and we did not run hands-on tests. Disclosure: MigrateX, the publisher of this article, runs ITSM data migrations, including between platforms named here. No vendor reviewed or paid for this article.