ServiceNow to Jira Service Management migration for mid-market teams
Short answer
Moving from ServiceNow to Jira Service Management makes sense for mid-market companies whose engineering teams already live in Jira and Confluence, who use ServiceNow mainly for incidents, requests and basic change, and who find the platform's admin and licence overhead hard to justify. What moves: ticket records and history (via CSV or API, with new keys), users, knowledge articles (into Confluence), and CI data (into JSM Assets). What you rebuild: catalog items and variables (as request types and forms), business rules and Flow Designer flows (as Jira automation), SLAs, approvals, notifications, reports and integrations. There is no Atlassian tool that migrates ServiceNow configuration for you, so treat this as a re-implementation with a data load, not a lift-and-shift. Do not migrate if you rely on ServiceNow HR Service Delivery, deep ITOM or GRC modules, or a heavily customised CMDB that feeds other enterprise systems.
Contents
- When moving to JSM makes sense, and when it does not
- ServiceNow to JSM concept map
- What moves and what you rebuild
- Moving the CMDB into JSM Assets
- A phased migration plan for mid-market teams
- Licence pricing: what JSM costs (checked on Oct 30, 2026)
- People, training and communication
- Common failure points
- Frequently asked questions
When moving to JSM makes sense, and when it does not
Good reasons to move
- Your developers already work in Jira. Linking an incident to the engineering issue that fixes it is native in JSM. In ServiceNow, that link usually depends on an integration someone has to maintain.
- You use a fraction of ServiceNow. If your instance is mostly incident, request and a light change process, you are paying for and administering a platform built for far more.
- Admin capacity is the bottleneck. Good ServiceNow administration is a specialist skill. JSM is administered by people who already know Jira, which most mid-market tech companies have.
- Knowledge already lives in Confluence. JSM uses Confluence as its knowledge base, so articles your engineers already write can serve the portal.
- Renewal pressure. A ServiceNow renewal is a natural decision point; a migration needs the overlap window that a renewal date gives you.
Reasons to stay on ServiceNow
- HR Service Delivery, CSM, SecOps or GRC are in use. These are separate ServiceNow products. JSM can run HR or facilities request queues, but it is not a like-for-like replacement for mature ServiceNow HRSD or GRC programmes.
- ITOM and Discovery feed your CMDB. If service mapping, event management and discovery drive incident and change decisions, re-creating that in Assets is a major project in its own right.
- Heavy custom applications. Custom tables and scoped apps built on the Now Platform have no equivalent to import into. They need re-design, often outside the ITSM tool.
- Your organisation is heading to enterprise-wide ESM on one platform. If the strategy is one workflow platform for every department, moving IT out of ServiceNow may cut against it.
For a side-by-side of the platforms before you commit, read our Freshservice vs JSM vs ServiceNow comparison. If JSM is not a fit but you still want to leave ServiceNow, the ServiceNow to Freshservice guide covers the other common route.
One more test: list the five things your service desk does every day, and check that each one works in a JSM trial site before anything else. Common examples are raising a request by email, approving a software request, escalating a priority incident to an engineering team, finding a laptop owner, and reporting SLA attainment. If any of the five needs a Marketplace app or significant custom automation, factor that into the decision and the budget before you commit to the migration.
ServiceNow to JSM concept map
Most of the design work is translating ServiceNow concepts into JSM ones. This map is the starting point for every workshop.
| ServiceNow | Jira Service Management (Cloud) | Notes |
|---|---|---|
| Incident table | Service space (project) with an Incident work type | Fields map to Jira fields and custom fields. Priority and impact/urgency matrices need to be re-created, usually with automation. |
| Service catalog items and variables | Request types with forms, grouped on the portal | Catalog client scripts and UI policies have no direct equivalent; forms support conditional sections. Simplify while you rebuild. |
| Requested items (RITM) and catalog tasks | Request work types, with sub-tasks or linked work items for fulfilment teams | The three-level REQ/RITM/SCTASK hierarchy usually collapses to one request plus sub-tasks. |
| Change requests and CAB | Change work type, approvals, change calendar | Risk assessments and CAB workbench need redesign. Deployment-gated changes can link to Bitbucket, GitHub or other CI/CD tools. |
| Problem | Problem work type, linked to incidents | Straightforward, but known-error records may need a custom field or a Confluence page. |
| Assignment groups | Teams, queues and assignment rules (automation) | Group-based routing becomes queue filters plus automation rules. |
| Business rules, Flow Designer, workflows | Jira automation rules and workflow transitions (conditions, validators, post functions) | Nothing converts automatically. Inventory, simplify, rebuild. |
| SLA definitions | JSM SLA goals and calendars | Rebuild. Historical SLA results stay in the archive. |
| CMDB (cmdb_ci and child classes) | JSM Assets object schemas | Design the schema first; import through Assets CSV/JSON importers or the Assets REST API. |
| Knowledge base | Confluence spaces linked to the service space | Export articles as HTML and import into Confluence; fix links and images. |
| Service portal | JSM portal and help center | Branding and layout options are narrower than a custom Service Portal. |
| Reports and Performance Analytics | JSM reports, dashboards, Atlassian Analytics (where licensed) | Rebuild the reports you actually use; drop the rest. |
| IntegrationHub spokes | Atlassian Marketplace apps, Jira automation web requests, REST APIs | Each integration is its own mini-project. |
What moves and what you rebuild
Atlassian does not offer a ServiceNow importer, so data moves through one of three routes:
Route 1: CSV export and Jira CSV import
Export ServiceNow tables (incident, sc_req_item, change_request, problem, sys_user) to CSV, transform them, and use Jira's CSV importer. Free and controllable, but attachments and comment threads need extra handling, and large volumes must be split into batches.
Route 2: Scripted API migration
Read from the ServiceNow REST Table API, transform, and write to the Jira Cloud REST API. Best when you need comments with original authors and timestamps, attachments, links between records, and repeatable delta loads before cutover. Throttle for API rate limits on both sides.
Route 3: Third-party migration service
Several commercial services move help desk data between platforms, including ServiceNow to Jira. Ask the vendor for a free test migration on your own data and check how they handle comments, attachments, custom fields and record links before signing.
What usually migrates well
- Ticket records: summary, description, status, priority, category, reporter, assignee, dates.
- Comments and work notes (as public comments and internal notes), if scripted or tool-assisted.
- Attachments, with API-based routes.
- Users and organisations (customers and agents), ideally provisioned from your identity provider rather than imported.
- Knowledge articles, as HTML into Confluence.
- CI records and basic relationships, into Assets.
What you rebuild
- Request types, forms and portal groups.
- Workflows, approvals and automation.
- SLAs and calendars.
- Notifications and email templates.
- Dashboards and reports.
- Integrations (monitoring, identity, HR, chat, CI/CD).
- Role-based access and permission schemes.
Keep the original ServiceNow number (INC, RITM, CHG) in a custom field on every migrated work item. Searches for old numbers will be common for months after cutover.
Moving the CMDB into JSM Assets
The CMDB is where most ServiceNow to JSM projects either get simpler or go wrong. ServiceNow's CMDB has a deep class hierarchy and relationship model; JSM Assets lets you design your own object schemas with object types, attributes and references. That flexibility is useful, but it means nobody hands you a ready-made model.
- Decide what the CMDB is for. If the only consumers are incident and change forms, a schema with a few object types (business services, applications, servers, laptops, users, vendors) is usually enough.
- Audit data quality first. Stale CIs, duplicate records and relationships nobody maintains should be fixed or dropped, not migrated.
- Prefer discovery and authoritative sources over a one-time copy. Atlassian provides Assets Discovery and import options for sources such as CSV, JSON and cloud platforms; MDM and cloud inventory tools are often more accurate than old CMDB data.
- Load in the right order. Reference objects (locations, vendors, users) first, then services and applications, then infrastructure, then relationships.
- Link Assets fields on request types early. Agents and requesters should be able to pick an affected service from day one.
Check the Assets object limits for your plan on the Atlassian JSM pricing page; Premium and Enterprise include a fixed number of Assets objects, with charges above that (checked on Oct 30, 2026).
A phased migration plan for mid-market teams
This is a planning template, not a promise. Scope, data quality and the number of integrations decide the real duration.
Phase 1: Discovery
Export the ServiceNow configuration inventory: active catalog items, business rules, flows, SLAs, assignment groups, notifications, integrations and reports. Pull usage data so you know which catalog items and reports are actually used. Agree what is out of scope.
Phase 2: Design
Service space structure (one IT space or several), work types, request types and forms, workflows, SLA goals, Assets schema, permission model, and the field mapping for each ServiceNow table. Decide how much history to migrate.
Phase 3: Build
Configure JSM, Confluence knowledge spaces and Assets. Rebuild automation rules. Connect identity, email channels, chat and monitoring. Build the migration scripts or set up the migration service.
Phase 4: Test migration and UAT
Run a full test migration into a sandbox or test site. Reconcile record counts, spot-check comments and attachments, and run end-to-end request, incident and change scenarios with real agents and requesters. Fix and repeat.
Phase 5: Cutover
Freeze ServiceNow for new tickets, run the final migration (or a delta on top of an earlier bulk load), switch email routing and portal links, and announce the change. Keep ServiceNow read-only for a fixed period.
Phase 6: Hypercare
Daily triage of issues, tuning automation and SLAs on real traffic, and closing knowledge gaps. Decommission ServiceNow only after the archive is exported and verified.
Licence pricing: what JSM costs (checked on Oct 30, 2026)
Per-agent prices from the Atlassian JSM pricing page, checked on Oct 30, 2026, annual figures shown per agent per month at the page's default team size (Atlassian's per-agent rate changes with the number of agents, so price your own agent count on the page):
| Plan | Price shown | Notes |
|---|---|---|
| Free | $0 | Up to 3 agents |
| Standard | $21.50 per agent / month | Core service management |
| Premium | $55.28 per agent / month | Adds advanced Assets and configuration management features |
| Enterprise | Contact sales | Enterprise-scale controls and analytics |
Requesters (customers) who raise tickets through the portal do not need agent licences; only people who work tickets do. ServiceNow pricing is quote-only, so we do not estimate what your current ServiceNow spend is; use your own contract. For a worked comparison of licence costs at 10, 25 and 50 agents, see our pricing guide.
Other cost drivers
- Marketplace apps that replace ServiceNow features you used.
- Confluence licences for knowledge authors, if you do not already have them.
- Migration tooling or developer time.
- Implementation partner time for design, build and testing.
- Overlap: both platforms licensed during the parallel and read-only period.
- Agent and requester training, and the temporary productivity dip after cutover.
People, training and communication
ServiceNow to JSM migrations change daily work for three groups, and each needs its own plan.
Agents
Agents move from ServiceNow lists and forms to JSM queues and work item views. The concepts are familiar, but navigation, keyboard shortcuts, internal notes versus public replies, and linking to engineering work are different. Run hands-on sessions in the test site using real scenarios from your own queue: a password reset, a hardware request with approval, a priority incident with an engineering link, and a standard change. Give each agent a one-page "where did it go" sheet that maps the ServiceNow screens they used to their JSM equivalents.
Requesters
Most employees only notice the portal URL and the email address. Keep the support email address the same if you can, redirect old portal links, and make the most common request types prominent on the new portal. Send a short announcement before cutover and a reminder on the day. Avoid asking employees to learn anything that they did not need to know before.
Admins and process owners
Somebody needs to own JSM configuration after go-live. In most mid-market companies that is an existing Jira administrator plus a service desk lead who owns request types, SLAs and knowledge. Define who can create request types, fields and automation rules, and keep a change log. JSM sites get cluttered quickly when everyone can add fields.
Archiving ServiceNow
Agree with legal, security and audit teams how long ticket history must be kept and in what form. Options include migrating all history into JSM, migrating recent history and keeping an archive export (CSV or database export plus attachments) in controlled storage, or retaining read-only ServiceNow access for a period. Whatever you choose, test that the archive can actually be searched before the ServiceNow contract ends.
Measuring success
Capture a baseline from ServiceNow before cutover: ticket volumes by category, SLA attainment, backlog size, and requester satisfaction if you measure it. Compare the same measures from JSM after hypercare. Without a baseline, every post-migration debate is about opinions rather than numbers.
Common failure points
1. Treating it as a data migration
The data is the easy part. Teams that budget mostly for moving tickets run out of time rebuilding catalog items, approvals and automation. Inventory configuration first.
2. Copying ServiceNow one-for-one
Re-creating every catalog item, every field and the REQ/RITM/SCTASK hierarchy produces a cluttered JSM site that agents dislike. Use the migration to cut unused items and simplify forms.
3. Migrating a bad CMDB
Poor CI data in ServiceNow becomes poor data in Assets. Clean or re-discover rather than copy.
4. Forgetting the integrations nobody owns
Monitoring alerts, HR onboarding feeds and identity workflows quietly create tickets in ServiceNow. List every inbound and outbound integration in discovery, including email-based ones.
5. Losing the old ticket numbers
Without the ServiceNow number on every migrated record, agents cannot find history that users quote. Add the custom field from the start.
6. Cancelling ServiceNow too early
Keep read-only access, or a verified archive, until audit and legal requirements for ticket history are met.
Pre-migration checklist
- ServiceNow configuration and usage inventory complete
- Out-of-scope modules agreed (HRSD, ITOM, GRC etc.)
- JSM site structure and request types designed
- Assets schema designed and data sources chosen
- Field mapping signed off per table
- Migration route chosen and tested on real data
- Integrations listed with owners and target design
- Old ticket number field in place
- Cutover, rollback and communication plan written
- ServiceNow archive and read-only period agreed
Frequently asked questions
Can the Jira Cloud Migration Assistant move ServiceNow data?
No. The Jira Cloud Migration Assistant moves Jira Server and Data Center data to Jira Cloud. ServiceNow data moves through CSV import, a scripted API migration, or a third-party migration service.
How long does a ServiceNow to JSM migration take?
It depends on scope, data quality and integrations. Configuration rebuild, not data transfer, usually decides the timeline. Run discovery first and plan from the inventory rather than from a generic estimate.
Does the ServiceNow CMDB migrate into JSM Assets?
CI data can be loaded into Assets with its CSV or JSON importers or the Assets REST API, but you need to design the Assets schema first. Many teams re-populate from discovery and authoritative sources instead of copying an out-of-date CMDB.
Do requesters need JSM licences?
No. Only agents who work on requests need agent licences. Customers who raise and follow requests through the portal or email are not licensed as agents, according to Atlassian's pricing page.
Is JSM a replacement for ServiceNow HR Service Delivery?
JSM can run HR request queues with request types, forms and restricted access, but it is not a like-for-like replacement for a mature ServiceNow HRSD programme with case management and employee journeys. Assess HR separately.
Planning a move from ServiceNow to JSM?
We design and run ITSM migrations: discovery of your ServiceNow instance, JSM and Assets design, data migration, automation rebuild, testing and cutover.