JSM-to-ServiceNow migration is a data-model translation: map issue types to ITSM tables, convert semantic statuses to numeric states, preserve SLA timestamps via task_sla, and rebuild automations in Flow Designer.
There is no native migration path from Jira Service Management to ServiceNow; the migration is fundamentally a data-model translation between two architecturally distinct platforms. JSM stores all work as Jira issues differentiated by issue type labels with semantic, project-specific statuses, while ServiceNow separates ITSM processes across dedicated ITIL-aligned tables (incident, problem, change_request) using numeric state machines. Custom extraction, routing, and mapping logic must be built to split JSM issues into the correct ServiceNow tables, translate status strings to table-specific integer states, and reconstruct queue logic as assignment group routing rules.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Quick Answer
A Jira Service Management (JSM) to ServiceNow migration is a data-model translation, not a file transfer. JSM uses semantic, project-specific statuses on an issue-centric engine; ServiceNow uses numeric state machines on ITIL-aligned tables. No native migration path exists. The biggest risks are broken SLA history, lost Confluence KB formatting, status values that don't map 1:1, and internal comments exposed to customers.
Critical edge case
One JSM project may contain mixed issue types (incidents, changes, problems) in a single backlog. You need to split these into separate ServiceNow tables during migration. Any script that dumps everything into the incident table will corrupt your ITSM process data — and will break ServiceNow reports, dashboards, and Performance Analytics indicators that assume table-level process separation. (support.atlassian.com)
Failure mode
If you import tickets without their SLA history, ServiceNow's SLA engine will attach new SLA records based on current SLA definitions — starting the clock from import time, not from the original creation date. This makes all historical SLA compliance data meaningless. A 50,000-ticket migration without SLA preservation will show 0% historical SLA compliance in ServiceNow dashboards.
License consideration
ServiceNow's CMDB is included in ITSM Professional and Enterprise tiers. ITSM Standard includes basic CI storage but not Discovery, Service Mapping, or the full CSDM framework. Verify your ServiceNow license tier supports the CMDB features you need before designing the migration.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope the service model, not just the ticket table.
Objective Agreed scope across incidents, changes, problems, requests, CMDB and knowledge, with the CAB bought in.
Keep these open
-
Inventory every record type in Jira Service Management
Count incidents, service requests, changes, problems, releases, knowledge articles and CI records. ITSM migrations fail on scope more than technique: the CMDB and the request catalogue are usually far larger and more entangled than the incident table everyone focuses on.
Data Profiler Get real record counts instead of estimating from memory -
Document the CMDB and its relationships
Map CI classes, attributes and — critically — the relationships between them. CI relationships carry your impact analysis, and they are the hardest thing to migrate faithfully because ServiceNow almost certainly models them differently.
CI relationships rarely map one-to-one between ITSM tools. Losing them silently breaks impact analysis and change risk scoring.
-
Capture SLAs, OLAs and their calculation rules
Record every SLA target with its business calendar, pause conditions and escalation path. The rules matter more than the numbers: an SLA that counts pending time differently in ServiceNow will report different compliance on identical data.
-
Review the request catalogue and its fulfilment workflows
Each catalogue item is a form plus an approval chain plus a fulfilment workflow. These are rebuilt, not migrated, and they are usually the longest lead-time item in the whole project.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Take the migration through change management
The migration is itself a major change and needs CAB approval, a risk assessment and a documented rollback plan. Start this early — CAB cycles are measured in weeks and will otherwise set your go-live date for you.
Helpdesk Migration Planner Turn ticket volume into a dated Jira Service Management → ServiceNow timeline -
Build the business case and set the window
Model licence delta, implementation effort and the operational risk of running degraded. Choose a window that avoids change freezes, month-end and any regulatory reporting deadline.
Helpdesk Evaluator Sanity-check that ServiceNow is the right target before you commit
Jira Service Management → ServiceNow specifics
- ITIL governance requirements
- JSM supports ITIL practices, but ServiceNow enforces them structurally. ServiceNow's out-of-box incident module ships with ITIL-aligned workflows, impact-urgency matrices (a 3×3 priority lookup that auto-calculates priority from impact and urgency fields), and major incident management processes with dedicated major_incident_state tracking. JSM gives you flexibility; ServiceNow gives you compliance guardrails. Organizations subject to SOX, HIPAA, or FedRAMP audits frequently cite this as the primary driver.
- CMDB as the source of truth
- JSM's Assets feature (Premium/Enterprise tiers, ~$44.27+/agent/month) provides a schema-free configuration database. ServiceNow's CMDB — backed by the Common Service Data Model (CSDM) — is a normalized, relationship-driven system with over 400 out-of-box CI classes organized across five CSDM domains (Foundation, Design, Build/Manage, Sell/Consume, Detect/Correct). It powers service mapping, impact analysis, and change risk scoring across the enterprise. JSM Assets has no equivalent to ServiceNow's Discovery or Service Mapping modules for automated CI population.
- Enterprise-wide service management
- JSM can extend to HR and facilities via project templates, but ServiceNow was built to unify IT, HR, SecOps, legal, and facilities on a single platform with shared workflows. ServiceNow's domain separation feature allows multi-tenant configurations that JSM cannot replicate.
- Automation depth
- JSM's no-code "when-if-then" rules cover common scenarios and support up to 500 rules per project in Premium plans. ServiceNow's Flow Designer, Business Rules, and IntegrationHub provide multi-layer automation that can span departments and integrate with SAP, Salesforce, Slack, and custom systems. IntegrationHub ships with 900+ pre-built spokes, compared to JSM's reliance on Forge apps and webhooks.
Don't move on until
- Counts confirmed across every ITSM record type including CMDB
- Change-management implications reviewed with the CAB
- SLA and OLA targets documented with their calculation rules
02 Data Audit Audit the service data and the configuration data separately.
Objective Profiled exports for every record type, with CMDB integrity and audit-trail requirements resolved.
Keep these open
-
Export and profile every record type
Profile incidents, changes, problems, requests, knowledge and CIs separately — they have different shapes and different defects. Reconcile each export against the API count to catch pagination truncation.
Data Profiler Profile the Jira Service Management export for nulls, outliers and type drift -
Audit CMDB integrity
Find CIs with no owner, no class, or relationships pointing at deleted CIs, plus duplicates from overlapping discovery sources. A CMDB is usually the least-maintained data in the estate and migrating its decay wastes the one chance you have to clean it.
Duplicate CIs from multiple discovery sources will multiply on load unless you dedupe before migrating.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Resolve audit-trail and retention requirements
Confirm with compliance how much history and which audit fields must be preserved, and whether a read-only archive of Jira Service Management satisfies the requirement. In regulated environments this often changes scope materially.
Regulated environments frequently require the immutable original audit trail, which no migration can recreate — plan for an archive.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Validate structure and encoding of the exports
Check delimiters, encoding and embedded newlines. Incident work notes and change implementation plans contain long multi-line text and pasted logs, which is exactly what breaks CSV parsing.
CSV Validator Catch broken headers and ragged rows in the raw export -
Scan for PII and secrets in ticket text
ITSM tickets contain credentials, connection strings, internal hostnames and personal data pasted into work notes. Scan for both regulated data and secrets, and treat found credentials as a security incident in their own right.
Work notes commonly contain passwords and connection strings. Migrating them propagates the exposure into a new system.
-
Clean, normalise and produce masked test data
Normalise timestamps to UTC, standardise CI naming, trim whitespace, and generate a masked copy for the sandbox. Business-hours SLA calculations make timezone consistency non-negotiable here.
PII Masker Generate a safe copy for sandbox and vendor testing
Don't move on until
- Every record type exported and profiled against API counts
- CMDB orphans and broken relationships quantified
- Audit-trail retention requirements confirmed with compliance
03 Field Mapping Map record types, state models, CI classes and approvals.
Objective A signed mapping covering record types, state machines, CI classes and relationships, and approval chains.
Keep these open
-
Map record types before fields
Establish how Jira Service Management record types land in ServiceNow — service requests may become a different object entirely, and incident/problem separation is modelled differently across tools. Get this wrong and every field decision downstream is built on sand.
Schema Mapper Opens pre-loaded with the Jira Service Management → ServiceNow field pair -
Map the state model and the impact/urgency matrix
Enumerate every state and transition, plus how priority is derived from impact and urgency. Tools derive priority differently, so a straight priority copy will disagree with the target's own calculation and confuse everyone reading a report.
If ServiceNow derives priority from impact and urgency, migrating priority directly will produce records whose priority contradicts their own inputs.
-
Map CI classes, attributes and relationship types
Match each CI class and relationship type to a ServiceNow equivalent and document every gap explicitly. Where no relationship type exists, decide whether to approximate, flatten, or park the data in an attribute — and record the impact on change risk scoring.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Map assignment groups, roles and approval chains
Build the group and user map including leavers, and map each approval chain to its ServiceNow equivalent. Historical approvals usually cannot be recreated as live approval records — decide how you preserve the evidence.
-
Plan knowledge article migration
Decide how article bodies, categories, permissions and linked-incident references translate. Confirm whether internal links between articles and attachment references survive, or need rewriting after load.
-
Set load order and freeze the spec
Sequence users and groups, then CIs, then CI relationships, then tickets, then knowledge — CI relationships need both endpoints to exist. Version and sign off the spec before the pilot.
Don't move on until
- State and priority models mapped, including impact/urgency matrices
- CI classes and relationship types mapped with gaps documented
- Approval chains and assignment groups mapped to target equivalents
04 Test Migration Pilot the whole service model, including a change with approvals.
Objective A sandbox pilot where tickets, CI relationships, SLAs and approvals all behave correctly.
Keep these open
-
Build the ServiceNow sandbox to match the target service model
Configure record types, states, SLAs, business calendars, assignment groups, CI classes and approval workflows before loading anything. In ITSM the configuration is the product, so an unconfigured sandbox tests nothing.
-
Pick a pilot slice spanning every record type
Include incidents at every priority, a change with a full approval chain, a problem with linked incidents, a catalogue request, connected CIs, and knowledge articles with cross-links. Coverage of types matters more than volume here.
-
Load in dependency order with full logging
Users and groups, then CIs, then relationships, then tickets, then knowledge. Log each request against its source ID so you can trace any failure without a full re-run.
-
Verify CI relationships and impact analysis
Confirm relationships survived and then run an actual impact analysis on a pilot CI, comparing the result to Jira Service Management. Relationship counts matching while impact analysis returns something different means the relationship types mapped wrongly.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Reproduce SLA compliance on migrated records
Compare calculated SLA compliance on the pilot records against Jira Service Management. Differences trace to business-calendar or pause-condition mapping and must be resolved before full load, since compliance reporting is often contractual.
SLA compliance is recalculated from loaded timestamps. Any approximation in timestamp or pause-state mapping shows up directly as a compliance variance.
-
Run a change through approvals and reconcile
Raise a change in the sandbox, take it through its full approval chain and implementation states, and reconcile the pilot batch on counts and fields. Then let service-desk agents work sample incidents before you sign off the pilot.
Don't move on until
- CI relationships verified intact for the pilot slice
- SLA calculations reproduce source compliance figures
- A change record runs end to end through its approval chain
05 Cutover Switch the service desk without losing an incident.
Objective All in-scope service data live in ServiceNow, monitoring and email integrations repointed, desk operating normally.
Keep these open
-
Pre-load history and the CMDB ahead of the freeze
Load closed tickets, knowledge and the CMDB while Jira Service Management stays live. The CMDB load in particular is slow and benefits enormously from happening outside the window.
Helpdesk Migration Planner Size the freeze window from ServiceNow's real API limits -
Publish the runbook with CAB-approved abort criteria
A timed sequence with named owners, plus the rollback conditions the CAB signed off. In ITSM the rollback plan is a formal deliverable, not a verbal understanding.
-
Freeze Jira Service Management and take the final delta
Stop new ticket creation, let the desk finish in-flight work, then export everything changed since the pre-load. Communicate the freeze across the whole organisation and staff a manual intake path for genuine P1s during the window.
A P1 incident raised during the freeze needs a documented manual path, or it will be worked in the old system and lost.
-
Load open tickets and the delta, then reconcile
Load open incidents, changes and requests, then verify counts and open-state accuracy before repointing anything. Open-state accuracy matters more than history here — it is what the desk works from at 9am.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint monitoring, email and integrations
Switch monitoring-tool integrations, email intake, self-service portal links and any orchestration or discovery connectors. Then fire a real alert through monitoring and confirm the incident it creates routes correctly.
Monitoring integrations still pointing at the old tool will create incidents nobody is watching.
-
Go/no-go and switch the service desk
Call the decision against the exit criteria with the change manager present, then move the desk with elevated support for the first shift. Keep Jira Service Management read-only as the archive and rollback path.
Jira Service Management → ServiceNow specifics
- Before migration
- Export a full baseline of ServiceNow target tables using sys_export_set or Update Sets for configuration changes.
- During migration
- Use a u_migration_batch_id field on all imported records so you can identify and delete a failed batch without affecting pre-existing ServiceNow data.
- After failed migration
- Delete records by batch ID, restore configuration from Update Sets, and re-run from the failed batch.
- JSM remains operational
- throughout — never decommission JSM until ServiceNow is fully validated and in production.
Don't move on until
- Historical load complete and reconciled before the freeze
- Monitoring, email and integration inbound paths verified live
- CAB-approved rollback point passed explicitly
06 Validation Prove service continuity, compliance and reporting.
Objective Evidence that records, CMDB, SLAs and workflows all survived, plus signed acceptance and a retained archive.
Keep these open
-
Reconcile every record type and the CMDB
Compare counts per record type and per state, CI counts per class, and relationship counts per type. Produce one report acceptable to both the CAB and your auditor.
Migration Validation Tool Reconcile Jira Service Management and ServiceNow record-for-record -
Re-verify CMDB relationships and impact analysis
Re-run impact analysis on a sample of critical CIs and compare with the pre-migration result. This is the CMDB equivalent of a field-completeness check and it is routinely skipped.
Data Profiler Prove field completeness held up through the load -
Tie SLA and service reporting to baseline
Rebuild SLA compliance, MTTR, first-time-fix and volume reporting, and compare to pre-migration figures for the same period. Explain every variance in terms of a specific mapping decision.
Business-calendar differences between tools will shift MTTR and compliance even when the underlying data is identical.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Test the full workflow layer
Fire every escalation, approval chain, notification, catalogue fulfilment workflow and automation with live records. Workflow is rebuilt from scratch, so nothing is proven until it has been observed running.
-
Confirm compliance evidence and audit archive
Re-scan for PII and secrets in loaded records, confirm retention configuration in ServiceNow, and formally retain the Jira Service Management archive that satisfies your immutable audit-trail requirement.
-
Close the change and sign off
Close the migration change record with actual outcomes, get written acceptance against the Discovery criteria, and schedule decommission after the agreed read-only retention period.
Don't move on until
- Reconciliation complete across all record types and CIs
- SLA and service reporting tie to pre-migration baselines
- Audit archive retained and acceptance signed
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
How Do You Migrate Jira Cus m Fields to ServiceNow
| Jira Service Management field | ServiceNow field | Notes |
|---|---|---|
| Text (single line) | String field (max 255 chars default) | Direct map; adjust max length in dictionary if needed |
| Text (multi-line) | String field (max 4000 chars) or Journal field | Journal fields (journal_input) for audit-tracked entries; journal entries are stored in sys_journal_field, not on the record itself |
| Select List (single) | Choice field | Must pre-populate choice values in sys_choice table before import |
| Select List (multi) | List collector or Glide List | Different storage model — Glide List stores comma-separated sys_ids |
| Date / DateTime | Date / Date/Time field | Timezone conversion required; ServiceNow stores all datetimes in UTC internally |
| Number | Integer / Decimal / Float | Match precision; Jira numbers are IEEE 754 doubles |
| User Picker | Reference to sys_user | Must resolve by email or employee ID, not by display name |
| Checkbox | True/False field | Direct map |
| URL | URL field | Direct map |
| Labels | Tags (via label table) | Different tagging architecture; ServiceNow labels are per-table |
| Cascading Select | Dependent choice fields | Requires parent-child choice configuration in sys_choice with dependent_value |
| Components | Reference to cmdb_ci_service or choice field | No direct equivalent — map to category/subcategory or CI reference |
| Sprint / Story Points | No equivalent | Drop or store in custom fields for historical reference |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Incidents | medium | Incidents must be routed to ServiceNow's dedicated incident table with numeric state mapping, caller_id population, and correct priority recalculation using ServiceNow's impact-urgency matrix. |
| Service Requests | high | JSM request types are presentation layers over issue types, but ServiceNow catalog items are full workflow objects with variables, execution plans, and approval policies, requiring significant redesign rather than direct mapping. |
| Change Requests | high | ServiceNow enforces distinct change types (Normal, Standard, Emergency) with separate approval flows and a unique state integer range (−5 to 4), making direct status translation from JSM's flexible workflow highly error-prone. |
| Problems | medium | Problem records require mapping to a different state model than incidents, and ServiceNow's problem-to-incident linking via problem_id reference fields must be reconstructed from JSM's issue link data. |
| SLA History | high | Broken SLA history is a top migration risk because JSM's SLA clock behavior tied to request types and project configurations does not directly translate to ServiceNow's task_sla record model with different pause and completion triggers. |
| Custom Fields | medium | JSM custom fields must be mapped to ServiceNow dictionary entries on the correct table, and field types (multi-select, cascading select, user pickers) may not have direct equivalents without custom configuration. |
| Configuration Items (Assets) | high | JSM's schema-free asset model must be translated to ServiceNow's normalized CMDB class hierarchy with enforced relationships, requiring class selection, attribute mapping, and relationship reconstruction across CSDM domains. |
| Comments and Work Notes | medium | JSM's internal vs. customer-visible comment distinction must be correctly mapped to ServiceNow's work_notes (internal) and comments (customer-visible) fields to prevent accidental exposure of sensitive information. |
| Attachments | low | Attachments can be transferred via ServiceNow's attachment API, though file size limits and storage quotas should be validated, and association to the correct target table record must be maintained. |
| User and Agent Data | medium | JSM agent and customer accounts must be mapped to ServiceNow sys_user records with correct roles and group memberships, and assignment group type must be set to 'itil' for ITSM task assignment to function. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Issue Type to Table Routing
JSM stores incidents, service requests, problems, and changes as issue types within a single project backlog, but ServiceNow requires each to be routed to separate ITIL-specific tables that extend the base task table.
Status to State Translation
JSM uses human-readable, project-configurable status strings while ServiceNow uses table-specific numeric state integers with distinct valid ranges and transition rules per table (e.g., incident, problem, change_request each have different state schemas).
Queue to Assignment Group Conversion
JSM queues are dynamic JQL-based filters where a ticket can appear in multiple queues simultaneously, whereas ServiceNow assignment groups are strict user-membership entities with a single-reference field on each record.
Asset and CMDB Model Gap
JSM Assets uses a flat, schema-free object model while ServiceNow's CMDB enforces a normalized class hierarchy with over 400 CI classes, enforced relationships, and the Common Service Data Model (CSDM) structure.
SLA History Preservation
JSM SLA tracking is tied to request types and project-level configurations, and translating elapsed SLA timers and pause conditions into ServiceNow's task_sla records without data loss requires careful timestamp reconciliation.
Internal Comment Visibility Control
JSM distinguishes between internal comments (agent-only) and customer-visible comments, and incorrect mapping during migration can expose sensitive internal notes to end users in ServiceNow's customer-facing portals.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How long does a Jira Service Management to ServiceNow migration take?
Most migrations take 3–6 weeks covering discovery, ServiceNow configuration, data migration, Confluence KB transfer, and UAT. Simple environments with under 10K tickets and no knowledge base can complete in under 2 weeks. The main variables are KB article count, SLA complexity, and number of automation rules to rebuild.
Can I migrate SLA history from JSM to ServiceNow?
Yes, by extracting SLA cycle timestamps from Jira's API, inserting them into ServiceNow's task_sla table with ISO 8601 datetime values, and running the SLA Repair utility. Skipping the Repair step means ServiceNow creates new SLA records from import time, destroying historical compliance data.
Will Confluence articles keep their formatting in ServiceNow Knowledge Base?
Not with native tools. ServiceNow's Easy Import loses images and formatting; Import from External Sources brings content as attachments. The proper method is API-based: extract Confluence HTML, strip macros, re-host images as ServiceNow attachments, and insert into kb_knowledge via the Table API.
Do Jira automation rules transfer to ServiceNow Flow Designer automatically?
No. There is no automated conversion path. Each JSM automation rule must be manually documented and rebuilt in ServiceNow — as a Business Rule for simple field updates, or as a Flow Designer flow for multi-step workflows involving approvals, notifications, or cross-table logic.
How do Jira queues map to ServiceNow assignment groups?
They don't map directly. JSM queues are JQL-based filters where one ticket can appear in multiple queues. ServiceNow assignment groups are strict user-membership entities with a single assignment per ticket. Migration requires translating queue filter logic into assignment groups with the correct itil group type, plus routing rules or Flow Designer flows.