I work at Help Desk Migration, which builds a ServiceNow → Jira Service Management migration app on the Marketplace. This post is about the migration itself.
Most ServiceNow + Jira content on Community is about keeping the two systems in sync. This post is for the teams doing the opposite: switching ServiceNow off. That means moving your history once, cleanly, and then decommissioning the instance.
By the end, you should have three things: a scope decision (what actually moves), a mapping table (where each ServiceNow object lands in JSM), and a cutover plan (what happens, in what order, and who gets told).
Migration or integration? Decide before anything else
These are different projects with different goals.
Integration means both systems stay live and records sync continuously. If that’s your situation, the Exalate and ZigiWave posts on Community cover it well, and they’re the better starting point.
Migration means a one-time move of historical data, plus a second pass (a “Delta”) for whatever changed during the run. After that, ServiceNow is retired.
A hybrid is sometimes the honest answer. If you’re rolling out JSM team by team, you may sync the teams still on ServiceNow during the transition, then do a final migration once the last team has moved. Just be clear internally about which phase you’re in, because the tooling and the risks differ.
Scope it: what’s worth moving out of ServiceNow
ServiceNow is a platform, not just an ITSM tool. A Jira Service Management migration usually means the ITSM slice:
- Incidents
- Requests
- Users and contacts
- Companies
- Knowledge articles
Everything else (HR, CSM, ITOM, custom apps) is a separate conversation.
Next, decide which records you need. The options are open tickets only, the last N years, or everything. Filtering by date or status reduces both cost and runtime, and most teams discover they don’t need ten years of closed incidents in a live service project.
A question that comes up often: what happens to open tickets? They arrive as live, workable Jira Service Management requests, not as a read-only archive. Status is mapped to a JSM status plus a resolution, so agents can pick them up the day after cutover.
Finally, be clear about what lives outside the ticket and won’t come across as data:
- Business rules
- Flows
- SLA definitions
- Assignment rules
- Notifications
These are logic, not records. They get rebuilt in JSM automation (more on that below).
How ServiceNow objects land in Jira Service Management
Before you start a migration, it helps to see the whole path on one page: what you connect to, what ServiceNow data goes in, and where each piece ends up in JSM. The table below walks through the typical stages in the order you’ll hit them, from authentication to the validation run. Exact steps differ by tool.
Two things to watch. You need admin-level access on the JSM side, and the ServiceNow account only needs read access to the tables in scope. The stages most likely to need a decision from you are Status & Resolution, Groups & Teams, and Watch Lists, because ServiceNow and JSM model them differently, and there is more than one reasonable target. Settle those before the first test run.
Typical Migration Stages | ServiceNow Source | Jira Service Management Target |
|---|
Authentication | ServiceNow instance URL + account with read access to the tables in scope (incl. sys_user) | Jira instance URL + admin email + Atlassian API token |
User Setup | sys_user records | Agents & customers (Atlassian accounts) |
Ticket Mapping | incident & sc_req_item | Request types (Incident vs. Service Request) |
Status & Resolution | ServiceNow State values | JSM statuses + Resolution field |
Comments & Privacy | Public comments vs. work notes | Public comments vs. internal comments |
Categorization | Category / Subcategory | JSM components or custom fields |
Groups & Teams | Assignment group | JSM teams or custom group fields |
Watch Lists | Watch list / CC users | JSM request participants or watchers |
Validation Run | Sample batch (20 records) | Target JSM project |
The rule of thumb: if JSM has a native field, use it. If it doesn’t, create a custom field before the run, not after.
Get Jira Service Management ready before the first test run
Most failed test runs come from an unprepared target, not from the migration itself. Work through this checklist:
- Create the target service project. Company-managed is recommended if you need custom fields shared across projects. Team-managed projects have limitations here.
- Add all agents to the project, with their emails visible, so assignees and authors can be matched.
- Enable public sign-up. It’s needed to create customers during import.
- Create matching custom fields and add them to the right screens.
- Raise the attachment size limit so large files don’t get dropped.
- Disable customer notifications and automation rules for the duration of the run. Otherwise, customers get emailed about 2019 incidents.
- Confirm admin rights on both sides. On the ServiceNow side, use an account with read access to every table in scope.
- Know what won’t transfer natively:
- CC users: put them in a custom field.
- Groups: map them to a custom field or team.
- Inline images: they can come over as attachments.
- KB article dates: they reset to the migration date.
Test on a sample, then check it like an auditor
Run a small sample migration first, and choose the sample deliberately. You want one ticket of each type:
- One with attachments
- One with a long comment thread
- One with a custom-field-heavy request
- One closed ticket
- One open ticket
Then compare the source and target side by side:
- Status and resolution
- Comment order and authors
- Attachments (present, openable, right size)
- Requester → customer link
- Organization
Re-test after every mapping change. It’s tempting to assume a small tweak is safe, but a changed status mapping can quietly alter how closed tickets appear, so rerun the sample each time.
Plan the cutover around Jira’s import speed
Jira’s import speed, not your calendar, sets how long the move takes, so plan around it. That shapes the sequence:
- Migrate history first, while ServiceNow stays live and agents keep working.
- Run a Delta for records created or updated during the main run.
- Switch the portal and email channels to JSM.
Around that sequence:
- Freeze window. Pick a short one for the Delta and the channel switch, and tell agents exactly when it starts and ends.
- Agent comms. Tell agents where to work, where old tickets live, and who to ask when something looks wrong.
- The ServiceNow instance. Keep it read-only for a defined period after cutover. Export what you need for retention or compliance before the contract ends, because it’s much harder to do afterward.
What you’ll rebuild in Jira Service Management (and shouldn’t try to migrate)
These are logic and configuration, not data. Treat the move as a chance to simplify rather than copy them one-to-one:
- SLAs: rebuild the goals and calendars in JSM.
- Queues: recreate the views your agents actually use.
- Automation rules: replace business rules and flows.
- Request types and portal groups: design them around what customers ask for.
- Approval flows: rebuild them as JSM approvals.
- CSAT: switch on JSM’s customer satisfaction survey.
If you’ve done this migration (or are planning it), what was the hardest part to scope? I’d be glad to hear what tripped you up.
