Migrating from ServiceNow to Jira Service Management (JSM) is a structured and predictable process when you understand what data can be transferred, what limitations to expect, and how to prepare your target environment. With the right migration approach, organizations can move historical records, users, knowledge base content, and workflows while minimizing disruption to support operations.
Many companies are migrating from ServiceNow to Jira Service Management to reduce licensing costs, simplify administration, and leverage the broader Atlassian ecosystem. JSM integrates seamlessly with Jira Software, Confluence, and hundreds of marketplace applications, making it an attractive option for teams seeking greater flexibility and faster service management processes.
This guide covers the entire migration journey — from understanding what data can and cannot be transferred to preparing Jira Service Management, executing the migration, and validating the results. You'll also learn how automated solutions such as Help Desk Migration simplify the process with data mapping, customizable migration options, Free Demo migrations, and secure automated transfers. As a result, most organizations can complete a ServiceNow to JSM migration without the cost and complexity of a professional services engagement.
Why Teams Switch from ServiceNow to Jira Service Management
Licensing and Cost Comparison
For many organizations, cost is one of the primary drivers behind a ServiceNow to JSM migration. ServiceNow is a powerful enterprise platform, but its licensing, implementation, customization, and ongoing administration costs can be significant. While pricing varies based on modules, users, and negotiated contracts, ServiceNow is generally positioned for large enterprises with complex IT service management requirements.
Atlassian Ecosystem Integration
Another major advantage of Jira Service Management is its native integration with Atlassian products. Teams can connect JSM directly with Jira Software for development collaboration, Confluence for knowledge management, and Bitbucket for source code management.
These integrations help eliminate information silos, improve visibility between support and engineering teams, and streamline incident, problem, and change management workflows. Organizations already using Atlassian products often find that JSM fits naturally into their existing technology stack.
Agility for Mid-Size and DevOps-Adjacent Teams
Many teams find Jira Service Management easier to configure, maintain, and adapt to changing business requirements. Its flexibility supports agile methodologies, DevOps practices, and cross-functional collaboration without requiring extensive platform administration.
ServiceNow remains a strong choice for organizations with highly complex enterprise requirements, particularly those relying on advanced CMDB implementations, extensive workflow automation, large-scale asset management, governance controls, or deeply customized ITSM processes. For these organizations, the additional capabilities of ServiceNow may justify the higher cost and complexity.
What Data Can You Migrate from ServiceNow to JSM?
Most structured service desk data can be migrated from ServiceNow to Jira Service Management with a high degree of accuracy. The areas that typically require additional planning are workflows, automations, knowledge base content, and platform-specific configurations that don't have direct equivalents in JSM.
Data That Migrates Automatically
Commonly migrated records include:
- Incidents
- Problems
- Change requests
- Service requests
- Contacts and requesters
- Agents and support groups (subject to user availability and permissions in JSM)
- Custom ticket fields
- Attachments
- Public and private comments
- Tags and labels
- Ticket history and timestamps
Migration tools preserve relationships between tickets, users, and related records whenever supported by the source and target platforms. Custom field mapping also allows organizations to align ServiceNow data structures with Jira Service Management projects and request types.
Data That Requires Manual Rebuilding in JSM
While ticket data transfers well, operational logic usually needs to be recreated within Jira Service Management.
Examples include:
- Workflow automations
- Business rules
- Approval processes
- SLA policies and escalation settings
- Email templates
- Customer notifications
- Integration configurations
- Custom scripts and platform-specific automations
This is not a limitation of migration tools but rather a consequence of the architectural differences between ServiceNow and Jira Service Management. Most organizations use the migration as an opportunity to simplify and modernize existing processes.
Data That Cannot Be Migrated (Current Limitations)
Certain elements either cannot be transferred directly or require alternative approaches due to platform constraints.
Common limitations include:
- CC users associated with tickets
- Inline images embedded within ticket descriptions or comments
- ServiceNow-specific modules, such as: Configuration Management Database (CMDB) records, Asset management data, and Custom enterprise applications built on the ServiceNow platform
Knowledge base content is also often treated as a separate migration scope. If your organization uses ServiceNow Knowledge Management, articles, categories, and related content can typically be migrated independently to Confluence or another knowledge base platform, depending on your target environment and migration strategy.
Before You Start — Pre-Migration Preparation
Audit and Clean Your ServiceNow Data
Before launching a migration, review the quality of your ServiceNow data. Migrating outdated, duplicate, or incomplete records can create unnecessary clutter in your new environment.
Focus on the following tasks:
- Remove duplicate contacts and requester records.
- Correct invalid or outdated email addresses.
- Archive obsolete, spam, or test tickets that no longer provide business value.
- Identify unassigned tickets and determine whether they should be reassigned, closed, or excluded.
- Review inactive users and support groups.
- Decide how much historical data should be migrated.
Not every organization needs a complete historical transfer. Some teams choose to migrate only open tickets and the last few years of support history, while others move all available records for compliance and reporting purposes.
A data audit also helps identify custom fields, ticket types, and business processes that must be recreated in Jira Service Management.
Set Up Your Jira Service Management Environment
Once the source data is ready, prepare the target JSM instance before initiating the migration.
Key setup steps include:
- Create all agent accounts in Jira Service Management.
- Ensure agent email addresses match their ServiceNow profiles exactly to preserve ticket ownership where possible.
- Grant the required permissions and ask agents to accept their invitations before the migration begins.
- Enable Public Signup to allow customer and requester records to be imported successfully.
- Create any custom fields that will receive data from ServiceNow.
- Configure projects, request types, queues, and customer portals as needed.
If you plan to use Help Desk Migration, preparing custom fields in advance simplifies field mapping and reduces the need for post-migration adjustments.
A particularly important consideration is project type. For the broadest compatibility, configure your destination as a Jira Service Management Classic project. Classic projects support a wider range of migration scenarios and customization options than Next-gen (team-managed) projects, which may introduce functional limitations during data transfer.
To avoid unnecessary ticket activity, temporarily disable:
- Email notifications
- Automation rules
- Escalation workflows
- Third-party integrations that react to ticket creation or updates
Finally, document your existing ServiceNow environment before migration starts. Capture workflow configurations, SLA policies, approval processes, email templates, business rules, and integrations. This documentation serves as a reference when rebuilding operational logic in Jira Service Management after the data migration is complete.
Field Mapping — Connecting ServiceNow to Jira
Using Help Desk Migration, you can review and customize mappings during setup to ensure ServiceNow records align with the correct Jira Service Management fields.
Here is the mapping table comparing standard ServiceNow fields to their Jira Service Management (JSM) equivalents.
| ServiceNow Field | Jira Service Management (JSM) Equivalent | Notes / Context |
| Number | Issue Key / External ID | JSM uses the project key + a number (e.g., ITSM-123). |
| Short Description | Summary | The main title of the ticket. |
| Description | Description | The detailed explanation of the issue. |
| State | Status | Tracks where the ticket is in its lifecycle (e.g., Open, In Progress, Resolved). |
| Priority | Priority | Determines the urgency/impact level. |
| Assignment Group | Team / Queue | JSM handles routing via Queues or designated Teams. |
| Assigned To | Assignee | The specific agent working on the ticket. |
| Caller | Reporter | The user who raised the request or reported the incident. |
| Category | Request Type / Custom Field | JSM relies heavily on Request Types for customer portal categorization or custom dropdown fields. |
| Comments | Public Comments | Messages visible to both the agent and the end-user. |
| Work Notes | Internal Comments | Notes visible only to agents and internal teams (hidden from customers). |
| Attachments | Attachments | Files, screenshots, or logs uploaded to the ticket. |
Groups, Custom Fields, and Status Mapping
Review assignment groups and agents before migration. If groups have been deleted or agents are inactive, decide where to reassign their tickets. Many organizations map historical tickets to a default support agent or an active team to avoid orphaned records.
Custom fields require special attention. When Jira Service Management doesn't have a direct equivalent, create a matching custom field in advance. Otherwise, valuable information may be omitted during the transfer.
Priority and status values should also be mapped carefully. ServiceNow and JSM often use different naming conventions and workflows. For example, a ServiceNow status such as Awaiting Approval may need to map to a custom Jira status rather than a default one. Defining these relationships beforehand preserves ticket history, reporting accuracy, SLA visibility, and operational continuity after migration. A thorough field-mapping review is one of the simplest ways to prevent post-migration cleanup work.
Running the Migration — Step by Step
The actual migration is usually the shortest phase of the project. The quality of your preparation and post-migration validation will have a much greater impact on success than the data transfer itself.
Step 1 — Connect ServiceNow and JSM
Start by connecting both platforms in your migration solution, such as Help Desk Migration. You'll need administrator-level access or sufficient permissions to read data from ServiceNow and create records in Jira Service Management. Verify credentials before proceeding to avoid interruptions during the migration process.
Step 2 — Select Data Types and Apply Filters
Choose the records you want to migrate. Common selections include incidents, service requests, problems, users, comments, attachments, and custom fields.
You can also apply filters to migrate only specific data sets, such as:
- Open tickets only
- Tickets from a selected date range
- Particular groups or departments
- Specific ticket types
Filtering helps reduce migration volume and improve overall efficiency.
Step 3 — Map Fields and Groups
Review how ServiceNow fields, statuses, priorities, agents, and assignment groups will be mapped to Jira Service Management. Confirm that custom fields have corresponding destination fields and define reassignment rules for inactive users or deprecated groups.
Step 4 — Run a Demo Migration
Before committing to the full transfer, run a . Help Desk Migration transfers a sample of up to 20 records, allowing you to validate field mappings, attachments, comments, user assignments, and ticket relationships.
Carefully review the results and adjust configurations if necessary.
Step 5 — Run the Full Migration
Once the demo results are approved, launch the full migration. Schedule the transfer during a low-activity period whenever possible and temporarily disable notifications, automations, and workflows that could generate duplicate actions or emails.
Step 6 — Perform a Delta Migration
Support operations can continue uninterrupted while the migration is running, enabling a Zero Downtime transition. After the full migration finishes, run a Delta Migration to transfer any tickets, comments, attachments, and updates created during the migration window. This final synchronization ensures Jira Service Management contains the latest ServiceNow data before teams fully transition to the new platform, without losing new activity or disrupting daily support operations
How to Verify Your Migration
Don't declare a migration successful on the day the data transfer finishes. The best practice is to validate the new Jira Service Management environment systematically over the next 48 hours to identify any data inconsistencies before fully retiring ServiceNow.
Start by spot-checking 20–30 tickets across multiple date ranges, priorities, statuses, request types, and assignees. Verify that ticket ownership, timestamps, comments, and customer information match the original records in ServiceNow.
Pay special attention to:
- Custom field values
- Priority mappings
- Status mappings
- Tags and labels
- Public and internal comments
- Ticket relationships and links
Next, review attachments to ensure files open correctly and remain associated with the appropriate tickets. Attachment integrity is a common validation checkpoint in any migration project.
Confirm that all agents can access their assigned tickets, queues, and projects in Jira Service Management. User permission issues are easier to resolve immediately after migration than weeks later.
As an additional safeguard, keep ServiceNow in read-only mode for at least two weeks after the migration. This provides a reliable fallback reference while teams adapt to Jira Service Management and complete final validation checks.
For a step-by-step overview of how to validate migrated data, review the Help Desk Migration Jira Service Management Guide, which covers key checks for tickets, users, attachments, field mappings, and overall data accuracy.
Post-Migration Checklist
A migration isn't complete when the data transfer ends — it's complete when Jira Service Management becomes the fully operational system of record for your support organization.
After validating the migrated data, begin transitioning daily operations to Jira Service Management.
Key post-migration tasks include:
- Redirect support channels from ServiceNow to JSM.
- Update customer-facing forms, portals, and email routing.
- Re-enable automations, notifications, triggers, and SLA rules in Jira Service Management.
- Verify integrations with other business systems.
Next, update internal documentation, training materials, and process guides that reference ServiceNow URLs, workflows, or procedures. This prevents confusion and helps accelerate adoption.
Schedule a walkthrough session for agents, administrators, and stakeholders to review the new environment, queues, request types, workflows, and reporting capabilities.
During the first two weeks, actively collect feedback from support teams. Users often identify workflow improvements and configuration adjustments that weren't visible during testing.
Finally, monitor key operational metrics, including:
- First response time
- Average resolution time
- SLA compliance
- Ticket backlog volume
- Agent productivity
Tracking these KPIs helps confirm that the migration has not negatively impacted service delivery and allows teams to optimize the Jira Service Management environment as usage grows.
Ready to migrate from ServiceNow to Jira Service Management?
