How does OpsHub Integration Manager help integrate your tools of choice?

Siloed tools severely hinder cross-team collaboration and create compliance challenges. Break free from data siloes and easily maintain cross-system traceability across tools. Provide full context to make informed decisions that drive innovation.

How does OpsHub Migration Manager migrate data across platforms?

Risky, disruptive tool modernization is not an option for the future-ready enterprise. Undertake tool transition painlessly, with zero downtime and high data fidelity. Scale effortlessly to meet evolving business needs. Modernize without compromising on productivity.

How does OpsHub Data Bridge extract insights from your data?

Most analytics are not actionable and not grounded in data. Unify multiple data sources with history and domain-aware analytics. Leverage data-backed decision making to consistently exceed expectations.

Discover our story, vision, and impact.

Get Started wIth 30 Days Free Trial

Blog

ADO to ADO Migration in 2026: A Guide to Cross-Tenant Moves, Mergers, and Splits

Moving between Azure DevOps organizations or tenants? This guide covers moves, merges, and splits, what migrates, your options, and the five stages to run it. OpsHub Migrator for Microsoft Azure DevOps (OM4ADO) supports it with history, user identity mapping across tenants, and delta migration, so teams keep working.

← Back to blog

ServiceNow to Jira Service Management migration: Complete tool guide

Teams moving a service desk from ServiceNow to Jira Service Management have four ways to do it: Atlassian's own import tools, manual export and import, custom scripts, and dedicated migration tools. This guide compares what each way moves, from ticket types and work notes to SLAs and attachments, and what each one tends to leave behind.

Devang Rathod

October 23, 2026

share this post:

TL;DR

OpsHub Migration Manager (OMM) is built to move a whole ServiceNow service desk into Jira Service Management (JSM) in one mapped run. It moves tickets with their comments, work notes, attachments and links, and offers reverse sync so both systems run side by side until a cutover the team chooses. The other routes each leave work behind: Atlassian’s import tools handle one part of the data at a time, a CSV import makes every comment public, and custom scripts must be built and maintained in-house.

Introduction

Moving from ServiceNow to Jira Service Management takes more than copying tickets from one system to the other. A service desk holds years of incidents, problems, change requests and request items. Each record also has comments, internal work notes, attachments, SLAs and links to other records. So the right tool depends on what each option moves and what it leaves behind. The sections below group the options into four approaches and compare them on the data that matters most.

What approaches are available for ServiceNow to JSM migration

There is no single obvious tool for this job, so the options fall into four groups. They are as follows. Atlassian’s own import tools bring in one part of the data at a time from files that have already been exported. A manual export and import moves records as plain files cleaned up in a spreadsheet. Custom scripts read ServiceNow through its APIs and write the data into Jira Service Management. Dedicated migration tools are built to move a whole service desk in one mapped run. The rest of this guide takes them in this order.

What data has to move from ServiceNow to JSM

Before comparing the tools, it helps to list what a good move has to cover. The list below is the standard the rest of this guide measures each option against. It also shows how ServiceNow and Jira Service Management each store the same information.

Ticket types: incidents, problems, change requests and request items in ServiceNow. In Jira Service Management these become issue types and request types.
Work notes and comments: in ServiceNow, internal work notes are kept apart from customer-facing comments. Jira Service Management does the same, with internal comments and public replies to the customer. Keeping that line between internal and public is one of the main things to check.
Original dates and authors: who created each record and when, and who wrote each comment. These are the hardest details to keep and the easiest to lose.
SLAs, attachments, and images placed inside descriptions and comments.
CMDB and configuration items. These belong in Jira Service Management Assets as objects, not as issues, so they are a separate import on their own.
Service catalog items, knowledge articles, users, and assignment groups.
The record history, and where the ticket data is handled while the move runs.

Can Atlassian's native import tools migrate ServiceNow to JSM?

Atlassian does not offer one tool that moves a whole ServiceNow service desk into Jira Service Management. Its native options are general import tools that work on files already exported from ServiceNow, and each one handles only one part of the data.

Jira’s own CSV import tool brings in work items and their fields, more than one comment per item, attachments linked by a working URL, parent and child relationships, and users matched by email or account ID. It also has real limits. The statuses it uses must already exist in the target workflow, backlog order is not kept, and any comments on Jira Service Management items become public after the import, so the internal work note line is lost. Jira Service Management Assets has its own import tools, which bring configuration items in as objects in an object schema. On Data Center, Atlassian also offers an Assets integration app that imports ServiceNow CIs directly. Because the tickets and the configuration items come in through two different tools, the service desk and the CMDB arrive as two separate jobs, not one.

What does a manual ServiceNow export and import keep?

The manual route exports ServiceNow list data to CSV, Excel, or XML, cleans it up in a spreadsheet, and then imports it into Jira Service Management. It needs no extra software and is fine for a small or archive-only move, but it keeps the least. Work notes and comments turn into plain text and lose the internal and public split. Attachments have to be imported as a separate step. Links between records are not carried over at all. Original dates and authors can be kept, but only through the admin-level external system import, and only when the original values are supplied in the format it expects. A project-level import, or any import that does not map those values, records the date of the import and the account that ran it instead of the original. So the original history survives only if the move is set up for it.

How do custom scripts migrate ServiceNow to JSM with the Table API and Jira REST APIs?

A scripted move reads ServiceNow records through the Table API, pulls files through the Attachment API, and then writes everything into Jira and Jira Service Management through their REST APIs. The script needs an account that can read the relevant tables. This can be a dedicated service account with read-only access rather than a full administrator. Written carefully, a script can keep work notes internal by setting the comment visibility as it writes, so the internal line is kept.

The catch is everything the team then has to own. The Jira Cloud REST API does not let a script set an issue’s original created date when the issue is made. This has been an open request to Atlassian for years, and the suggested workaround is a CSV import. So a scripted issue gets the import date unless the date is handled some other way. A script can set the reporter if its account has permission to modify it, but every comment it writes is shown under the script’s account. Rate limits, retries, checking for duplicates, and ongoing upkeep all fall on the team. A script is precise and flexible, but it is something the team has to build and keep running, not a finished product.

What should a ServiceNow to JSM migration tool move?

Dedicated tools are one group, but there are two kinds inside it, and the difference matters. A one-time migration tool moves records across once. A sync, or integration, tool keeps two systems matched on an ongoing basis, and some teams use one to run a move in stages. The two do different jobs. A migration moves data one way and one time. A sync keeps data matched both ways as long as both systems are used. For a move, the question to ask is simple: how much does the tool move in a single run?

These questions help tell a full migration tool apart from a partial one:

Which ticket types does it move?
Does it keep work notes internal instead of making them public?
Does it keep the original dates and authors?
What happens to SLAs, attachments and inline images?
Does it move the CMDB and the links between records?
Where is the ticket data handled while the move runs?

OpsHub Migration Manager is a one-time migration tool built to move ServiceNow records into Jira Service Management. It covers the items the other approaches in this guide lose or leave to the team:

Work notes stay internal. They arrive as internal comments, not public replies, so agent-only notes stay hidden from customers.
Links between records come across, including incident-to-problem and parent-child links, so related records stay connected.
Inline images and rich text formatting are kept, so descriptions and comments read the same as they did in ServiceNow.
System and custom tables move across, including incidents, problems, change requests and request items, each mapped to a Jira Service Management issue type.
Assignment groups can map to projects or to teams, so tickets land with the right queues.
Comments, @mentions and attachments move in the same run, along with tags as a field and status and priority mapping.

During the move, OpsHub Migration Manager:

Maps and transforms fields, so values that differ between the two systems are converted instead of dropped.
If a record fails to move because of a passing problem, such as a network timeout, OMM tries it again on its own, so that record is not quietly skipped and left out of the move.
Checks what has already moved, so a re-run does not create duplicate records.
Offers optional reverse sync, so ServiceNow stays up to date while both systems run side by side.
Can move data from Jira Service Management back to ServiceNow if needed.

That way the team picks when to switch over, instead of freezing ServiceNow for a single cutover. This is where a CSV import or a hand-built script usually falls short.

What each approach moves, and what it misses

The table below compares the four approaches on the data a service desk depends on. It only lists the items that are confirmed for OpsHub Migration Manager, so its column is complete. Where an approach’s own documentation does not mention an item, the cell says not documented rather than not supported, because a missing mention is not proof that the approach cannot do it.

Entity or data point	Atlassian native import	Manual export and import	Custom scripts	Other third-party tools	OpsHub Migration Manager
Incidents, problems and other ServiceNow tables as JSM issue types	Comes in as plain issues	Comes in as plain issues	Mapped in the script	Depends on the tool	Yes
Assignment groups as JSM projects	Not documented	Mapped by hand	Mapped in the script	Not documented	Yes
Work notes kept internal in JSM	No, comments become public	No, the internal and public split is lost	Yes, if visibility is set	Not documented	Yes
Comments and @mentions	Yes, but made public	Comes in as plain text	Mapped in the script	Supported by some tools	Yes
Inline images and rich text formatting	Not documented	Lost, or redone by hand	Only if coded for it	Not documented	Yes
Attachments	Only by a working link	Done as a separate step	Through the Attachment API	Supported by some tools	Yes
Links between records (incident-to-problem, parent-child)	Not carried over	Not carried over	Only if coded for it	Not documented	Yes
Status and priority mapping	Not documented	Mapped by hand	Mapped in the script	Supported by some tools	Yes
Tags carried as a field	Not documented	As plain text	Mapped in the script	Not documented	Yes
Field mapping, transformation, retries and duplicate checks	Only column-to-field mapping	By hand, re-run manually	Built into the script	Supported by some tools	Yes
Reverse sync to run both systems until the switch	Not documented	No	Only if custom-built	Only sync tools do this	Yes

Reading the columns, the pattern is clear. The native and manual routes move only parts of the data and lose internal notes and the original history. Scripts can keep more, but only if the team builds them to. A dedicated migration tool is the one made to move everything together in a single run.

Which ServiceNow to JSM migration approach fits which move?

Choosing between these four approaches comes down to one question: what has to be kept? For a quick archive copy, an Atlassian import tool or a manual export will move the records, but the internal work notes and the links between records will need rebuilding. For a move that has to keep that detail intact in one run, a dedicated migration tool is built for the job. OpsHub Migration Manager moves ServiceNow records into Jira Service Management, maps and transforms the fields, retries records that fail, checks for duplicates, and offers reverse sync so both systems can run side by side through a controlled switch.

Frequently asked questions

What access does a migration need in ServiceNow?

To read records, a migration needs access to the right tables through the ServiceNow Table API. This is usually a dedicated service account. It does not need full administrator rights just to read records, so read-only access is the safer choice.

Is a sync tool the same as a migration tool?

No. A migration tool moves records one way, one time, from the old system to the new one. A sync tool keeps two systems matched in both directions for as long as both are in use. OpsHub offers both. OpsHub Migration Manager is the migration tool, and it includes optional reverse sync so ServiceNow stays up to date until the final switch. OpsHub Integration Manager is the sync tool, built for teams that want to keep ServiceNow and Jira Service Management running together long term with bidirectional sync.

Can work notes stay internal after the move?

Only if the method keeps the comment visibility. A flat CSV import makes comments public, so the internal line is lost. Custom scripts can set the visibility as they write, and dedicated migration tools built for ServiceNow and Jira Service Management can keep work notes internal.

Does a migration keep original dates and authors?

It depends on the method. A CSV import can keep the original created date, reporter, and comment author and date, but only through the admin-level external system import, with the values supplied in the format it expects. Scripts and tools that write through the Jira Cloud REST API cannot set an original created date, because Jira does not accept a past created date or another person’s name through the API. OpsHub Migration Manager works within that limit: the original authors of comments can be kept inside the comments, while a record’s created and updated dates follow Jira’s rules rather than the original. For any tool, confirm how it handles original dates and authors for the specific move.

Is a migration partner or consultant required, or can a team run this alone?

Any of the four approaches can be run in-house or with a partner. The right choice depends on how many records are moving and how much detail has to be kept. A small archive move can be handled in-house, while a move that has to keep work notes, SLAs, and links is often faster with a tool or a partner.

See what moves across, before the move from ServiceNow to JSM

Plan a ServiceNow to Jira Service Management move

Walk through what OpsHub Migration Manager can move across for a specific ServiceNow instance.

Evaluation Toolkit