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

How to maintain data integrity during Jira Cloud migrations

This guide explains how to maintain data integrity during Jira Cloud migrations, and Jira migration in general, using Jira Cloud Migration Assistant (JCMA) with OpsHub Migration Manager (OMM). It covers what moves, where integrity breaks, the checks that keep data accurate, and how the two tools work together.

← Back to blog

ServiceNow to Jira Service Management migration: the end-to-end guide

A guide to moving a service desk from ServiceNow to Jira Service Management, from the first scope decision to the final switch. It covers whether the move can be direct, what the project involves, how to handle an on-premise instance, whether to copy or redesign, what drives the timeline, and how to run both systems in parallel through a controlled cutover.

Muskaan Pathak

October 23, 2026

share this post:

TL;DR

Moving a service desk from ServiceNow to Jira Service Management is a project, not a single copy. A ServiceNow instance holds years of incidents, problems, change requests and request items, along with work notes, SLAs, assignment groups and CMDB data. This guide walks through the whole move in plain terms: whether it can be done directly, what the work involves from start to finish, how an on-premise instance changes things, whether to copy or redesign, what drives the timeline, and how to switch over without a hard stop.

Is a ServiceNow to JSM migration direct, or does the data have to be exported and re-imported

There are two ways to move the data. The first is a manual export and re-import: ServiceNow records are exported to files, cleaned up in a spreadsheet, and loaded into Jira Service Management. This works, but flat files lose the line between internal work notes and public comments, and they record the import date instead of the original date. The second is a direct move with a migration tool. The tool connects to both systems through their APIs and moves records across with field mapping, so there is no manual export step in the middle.

A direct move is also what makes a controlled switch possible. A dedicated migration tool such as OpsHub Migration Manager (OMM) connects to ServiceNow over its API and can offer reverse sync, so ServiceNow and Jira Service Management can run side by side until the team is ready to switch. That option is covered later in this guide.

What a ServiceNow to Jira Service Management migration involves from start to finish

A migration is best read in two parts: the stages the project runs through, and the data that moves within them. The stages are the same whichever route is taken. What changes from one project to the next is how much data there is, and how much of it has to arrive intact.

The stages, in order

Scope and audit. Decide what moves: which ticket types and custom tables are in scope, and how far back the history should go.
Set up Jira Service Management. Create the projects, issue types, request types, workflows and SLA goals that the records will land in.
Map the data. Match ServiceNow tables and fields to Jira Service Management issue types and fields, and match users and assignment groups to their JSM equivalents.
Run the move. Migrate a small, representative set first, check it, then run the full move.
Validate. Compare record counts and spot-check tickets, comments, attachments and the links between records.
Cutover and monitor. Move day-to-day work to Jira Service Management, and keep ServiceNow available as a fallback for a short period.

What moves across

Each stage works towards the same result: ServiceNow records landing in their Jira Service Management equivalents. The table below maps the main ones. It is a high-level summary for planning and does not go field by field.

ServiceNow data	Where it lands in Jira Service Management
Incidents, problems, changes and request items	Issue types and request types
Assignment groups	Jira Service Management projects
Work notes	Internal comments, kept out of the customer view
Comments and @mentions	Issue comments
Inline images and rich text	Formatting inside issue descriptions and comments
Attachments	Attachments on issues
Links between records, such as incident to change	Linked issues
SLAs	SLA goals, with their own targets and calendars
Workflows	Jira Service Management workflows, as statuses and transitions
Customers and contacts	Customers in Jira Service Management

Each item in this table has a Jira Service Management equivalent to land in. How completely it carries across depends on the route chosen, which is where the rest of this guide goes next.

Migrating from an on-premise or network-restricted ServiceNow instance

A migration tool reads ServiceNow records through the Table API, so the instance has to be reachable and the account used has to have read access to the relevant tables. A ServiceNow instance that sits behind a firewall, on a private network, or on-premise can still be migrated, but the connection has to be arranged first. That usually means allowlisting the tool’s access, opening a secure route to the instance, or running the move from inside the network. The access given can be a dedicated, read-only service account rather than a full administrator, which keeps the footprint small. The exact setup depends on how the instance is hosted and secured, so it is worth confirming the connection method early in the project.

Copy as is, or redesign processes in Jira Service Management

A migration is a chance to decide what to keep and what to improve. Some data maps straight across: ServiceNow tables become Jira Service Management issue types, and assignment groups become projects. Other things are set up fresh in Jira Service Management rather than copied, because the two systems model them differently. Workflows are built in Jira Service Management, and SLAs are set up there as SLA goals with their own targets and calendars.

Because those parts are rebuilt anyway, a move is a natural point to simplify. Carrying every old workflow and rule across as is can bring old complexity into the new system, while rethinking them can make day-to-day work simpler. The right balance depends on how well the current setup serves the team. Records and history can move across in full, while the processes around them are redesigned to fit Jira Service Management.

How long a migration takes and what drives the duration

A migration’s length depends on the work involved, not on a fixed number. The main things that drive it are the volume of records, the number of ticket types and custom tables in scope, how much the data needs cleaning first, and how much of the process is being redesigned rather than copied. Technical limits also play a part, since reading from ServiceNow and writing into Jira Service Management both work within API rate limits, and large moves are usually run in batches. A small, clean move with few custom tables is far quicker than a large instance with heavy customization and years of history. The most useful planning step is to size the data and the number of ticket types early, because those set the shape of everything that follows.

Planning the cutover: running both systems in parallel

The safest way to switch is a controlled cutover, where ServiceNow and Jira Service Management run in parallel for a period rather than stopping one system the moment the other starts. Running both side by side gives the team time to validate the move and keep working while the switch is prepared. Reverse sync supports this, by keeping ServiceNow up to date with changes made in Jira Service Management until the team picks the moment to go live.

Within that approach, open tickets can move first, so active work carries on in Jira Service Management straight away, with older history brought across in a later pass. The cutover itself can be run in one of two ways. A single cutover moves everyone at once, which is simpler to plan but puts more on one day. A phased cutover moves one department or region at a time, which spreads the risk and lets each group settle in, but means the two systems run together for longer. The right choice depends on the size of the service desk and how much change the team can take at once.

Conclusion

A ServiceNow to Jira Service Management migration is manageable when it is taken in order: scope the data, set up Jira Service Management, map and move the records, validate, and switch over. A direct move with a migration tool avoids the losses of a manual export, and a controlled cutover with both systems running in parallel keeps the service desk working throughout. OpsHub Migration Manager moves tickets, workflows, SLAs, attachments and customer data from ServiceNow to Jira Service Management, and offers reverse sync so the team can run both systems side by side and switch over when ready.

Frequently asked questions

How long should both systems run in parallel?

There is no fixed number. Both systems should run in parallel for as long as validation needs, and the period should end on clear exit criteria, such as record counts matching and the team working comfortably in Jira Service Management, rather than on a set date. A larger move, or one with more customization to check, usually means a longer parallel period.

What happens to tickets still open at cutover?

Open tickets move first, so the team keeps working on them in Jira Service Management from the switch. Remaining history can be brought across in a later pass. Keeping ServiceNow available as a read-only fallback for a short period after cutover gives the team a safety net while the move settles

Get a migration timeline scoped against a real Azure DevOps inventory

See how a controlled cutover fits your teams

Bring your Azure DevOps setup and talk through the mapping and a pilot plan.

Evaluation Toolkit