ServiceNow to Jira Ticket Migration Without Losing Records

ServiceNow to Jira migration: do it right or pay the price

Blog

No items found.

May 18, 2026

Moving your incident management, change tracking, or service workflows from ServiceNow to Jira is one of the highest-stakes operations an IT team can execute. Get it wrong and you are staring at lost ticket history, broken field mappings, orphaned records, and a support queue that no longer makes sense. Get it right and your teams hit the ground running in Jira on day one, with every comment, attachment, and status in tact.

Why Organizations Are Moving from ServiceNow to Jira?

ServiceNow is a powerhouse for enterprise ITSM. Jira, built by Atlassian, is where software delivery lives. As engineering and IT operations teams converge under DevOps and platform engineering models, the case for consolidating on Jira grows quickly.

Common drivers behind a ServiceNow to Jira migration include cost optimization, DevOps alignment, team consolidation around the Atlassian ecosystem, agile transformation, and vendor simplification. According to Gartner, organizations consolidating around integrated, developer-friendly tooling consistently report reduced IT operational costs and faster time-to-resolution for incidents.

Are You Actually Ready to Migrate?

Most migration failures are caused by inadequate preparation, not by the migration itself. Before a single record moves, your team needs honest answers to these readiness questions.

Priority	Readiness Check
CRITICAL	Have you fully inventoried all ServiceNow tables, custom fields, workflow states, and SLA configurations in scope?
CRITICAL	Is your Jira target environment fully configured - projects, issue types, custom fields, workflow statuses, and user accounts - before migration starts?
CRITICAL	Do you have a documented user mapping table matching every ServiceNow user to a Jira account?
CRITICAL	Have you mapped every ServiceNow workflow state to its Jira equivalent, including custom states?
IMPORTANT	Have you defined the migration scope clearly: date range, ticket types, assignment groups, exclusions?
IMPORTANT	Do you have a rollback plan if the migration fails at scale?
IMPORTANT	Have you identified all parent-child ticket relationships and linked Configuration Items?
RECOMMENDED	Have you run a data quality audit on ServiceNow before migrating?
RECOMMENDED	Have you confirmed API access credentials for both systems with sufficient bulk read/write permissions?

All Critical items must be complete before migrating. Important items should be addressed before full-scale migration. Recommended items will significantly improve outcomes.

"Poor data quality costs the average enterprise $12.9 million per year." — Gartner, cited in 12 Financial Data Migration Challenges and How to Solve Them, Data Ladder

What Data Is at Risk During a ServiceNow to Jira Migration?

Before you protect your data, you need to know exactly what you are moving. A complete data migration from ServiceNow to Jira touches far more than the ticket title and description.

• Core record types: Incidents, service requests, change requests, change tasks, problem records, CMDB references, and approval workflows with SLA metadata.

• Ticket attributes: Priority, severity, category, assignment groups, assignees, creation dates, update timestamps, resolution times, and custom fields unique to your ServiceNow instance.

• Relational and contextual data: Comment threads and internal work notes, file attachments, parent-child ticket relationships, CI links, and user/group associations.

As Atlassian's Jira Service Management migration documentation makes clear, proper field configuration and workflow setup must be completed before any bulk import begins.

The Field Mapping Problem: Why ServiceNow and Jira Don't Just 'Talk'

One of the most misunderstood aspects of migrating tickets from ServiceNow to Jira is that the two platforms do not share a common data language. Their APIs return data in different formats, with different fieldnames, different value types, and different workflow models. Here is a practical reference for the field translations that every ServiceNow to Jira migration must handle correctly.

ServiceNow Field	API Format	Jira Field	Mapping Notes
`short_description`	String	`summary`	Direct mapping; watch for 255-char limit in Jira
`description`	String (plain text)	`description`	Jira Cloud uses rich text (ADF); formatting may need transformation
`state`	Integer (1, 2, 6...)	`status` (transition)	Requires conditional mapping. State 1=New, 2=In Progress, 6=Resolved. Jira uses transition IDs, not strings.
`priority`	Integer (1-5)	`priority`	Conditional mapping needed; Jira uses flat labels (Highest, High, Medium, Low)
`assigned_to`	Reference (sys_id)	`assignee`	User resolution layer required; match on email or username
`comments / work_notes`	Nested journal entries	`comment`	Requires Related Records mapping; filter work_notes from customer-facing comments
`sys_created_on`	DateTime (UTC)	`created`	Date format transformation may be needed (MM/dd/yyyy vs ISO 8601)
`category / subcategory`	String	Custom field or label	No native Jira equivalent; requires custom field setup in Jira first
`number`	String (INC0001234)	Custom field (SN Reference)	Essential for correlation and traceability during parallel operation
`attachment`	Binary (API endpoint)	`attachment`	Binary transfer with size limits and retry logic required; not handled by CSV export

ServiceNow to Jira field mapping reference. Fields marked 'Requires conditional mapping' will silently fail in script-based approaches.

Watch out: ServiceNow transmits the state field as an integer via its REST API, not as a readable string. If your migration tool is not translating state values into the correct Jira transition, every migrated ticket will land in the wrong workflow state - or fail to import entirely.

Top 6 Causes of Data Loss In ServiceNow to Jira Ticket Migration

1. Mismatched Field Mappings

ServiceNow and Jira use fundamentally different data models. ServiceNow organizes work around ITSM tables, while Jira works with issue types inside projects. Without deliberate mapping for every field, data is silently dropped or corrupted on arrival.

2. Status and Workflow Incompatibility

As shown in the mapping table above, ServiceNow transmits state values as integers. Jira uses project-specific transition IDs. Without conditional mapping, tickets arrive in Jira in incorrect workflow states, or fail to import entirely. This affects every single ticket in the migration.

3. Loss of Comment History and Work Notes

Comment history carries troubleshooting steps, customer communications, escalation decisions, and the audit trail that compliance teams require. Most basic migration scripts only transfer top-level fields and ignore the comment log. The result: tickets arrive in Jira stripped of all operational context.

4. Attachment Transfer Failures

Attachments in ServiceNow require binary file transfer via the /api/now/attachment endpoint - something CSV exports and many import tools cannot handle. A failed attachment transfer is often silent: the ticket arrives in Jira, but without its supporting documentation.

5. User and Group Resolution Failures

ServiceNow user accounts do not automatically map to Jira accounts. Without a user resolution layer, assignee and reporter fields are either blank or mapped to a generic system account -destroying ownership data across all migrated records.

6. Duplicate Records from Missing 'Last Time' Logic

When a migration runs in batches or resumes after an interruption, the integration engine must know which records have already been transferred. Without a 'Last Time' expression - a mechanism that tracks the timestamp of the last successfully processed record -the platform will re-collect and re-create already-migrated records on every run, flooding Jira with duplicates. ZigiOps builds this using its Last Time expression engine, which dynamically updates after each successful batch.

Expert tip: The Last Time mechanism is especially critical for comment and changelog sync. Without separate Last Time expressions for comments and changelogs, ZigiOps will continuously re-collect already-synced comments and create duplicates on the Jira side. ZigiOps handles this with independent Last Time expressions per related record type.

Why Manual Migration Approaches Create More Problems Than They Solve?

Three conventional approaches are commonly attempted when teams need to migrate tickets from ServiceNow to Jira. All three have significant limitations:

• CSV exports handle flat, structured data only. Relational data - comments, attachments, parent-child relationships - cannot be represented in a flat file.

"83% of data migration projects either fail outright or exceed their budgets and timelines. This failure rate highlights how easily projects can derail due to underestimated complexity, poor planning, or data quality issues." - Gartner, cited in Top Data Migration Challenges & How to Overcome Them, Kanerika Inc.

• Custom API scripts offer flexibility but demand deep knowledge of both APIs. They take weeks to build, are fragile when schemas change, and almost never include rollback capabilities or duplicate prevention logic.

• One-time bulk import tools handle basic field mapping but lack configuration depth for complex enterprise environments, and provide no ongoing synchronization for phased migrations.

ServiceNow's own platform documentation acknowledges significant limitations with export sets and transform maps when transferring data to external systems, particularly around relational data integrity and custom field handling.

"If you are doing data transition, it is a tedious task to export and import data when you have a data limit. The default CSV, XML, and JSON export limit is 10,000 rows."- ServiceNow Community, ServiceNow Things to Know: System Export Sets

‍

Comparison of Manual Export, Custom Scripts, and Generic Tools showing their limitations: time consuming, error prone, high maintenance, breaking changes, limited features, and data loss risk — Why traditional integration approaches fall short

How ZigiOps Enables No-Code Data Migration from ServiceNow to Jira

ZigiOps is an enterprise-grade, 100% no-code integration platform built for IT Operations. It is not a plugin or an add-on - it is a standalone application that connects to both ServiceNow and Jira via their REST APIs, manages every aspect of the data transfer, and keeps both systems in sync throughout the migration window.

Critically, ZigiOps stores none of the data it transfers. Records are processed in real time and kept only in your source and target systems. ZigiOps is also ISO 27001 certified, meeting enterprise security standards out of the box.

Key ZigiOps Capabilities for ServiceNow to Jira Migration

• Conditional status mapping: ZigiOps translates ServiceNow state integers to the correct Jira workflow transitions. State 2maps to 'In Progress,' state 6 maps to 'Done.' Every mapping is validated against the target Jira workflow before transfer.

• Complete comment and attachment transfer: Full comment history with original timestamps and authorship. Work notes can be filtered from customer-facing comments. Attachments use secure binary transfer with retry logic.

• User mapping layer: ZigiOps resolves ServiceNow user accounts to Jira counterparts by email, username, or custom identifier. Assignee, reporter, and watcher data are preserved.

• Duplicate prevention via Last Time expressions: ZigiOps tracks the timestamp of the last successfully processed record for each operation, collecting only records created or updated after that timestamp.

• Bidirectional synchronization for phased migrations: Updates in ServiceNow push to Jira and vice versa, keeping both systems consistent during the transition window.

• Unlimited transactions: No limits on the number of records ZigiOps can process. No per-transaction pricing or artificial throughput ceiling.

• Pre-built integration templates: Ready-to-use templates for ServiceNow incidents to Jira tasks, problems to bugs, and service catalog tasks to Jira tasks. Setup time drops from weeks to hours.

Explore the full Jira-ServiceNow integration capability on the integration page.

What Does a Realistic Migration Timeline Look Like?

One of the most common questions IT Managers ask before a data migration from ServiceNow to Jira is: how long will this actually take? Here is a representative phased migration timeline fora mid-to-large enterprise environment.

Week 1	Week 2	Week 3	Week 4	Week 5
Pre-migration assessment, inventory, user mapping, rollback plan	Jira environment setup, ZigiOps config, field mapping, conditional status rules	Pilot migration (50-200 tickets), validation, adjustments, re-pilot if needed	Full migration execution, parallel sync enabled, real-time monitoring	Post-migration validation, reconciliation, team sign-off, ServiceNow archiving

Timeline for a mid-to-large enterprise migration (10,000-100,000 records, moderate customization). Simple environments may complete in 2-3 weeks. Highly customized instances may extend to 6-8 weeks.

ZigiOps vs. Manual Migration

Capability	Manual / Script-Based	ZigiOps
Field Mapping	Developer-coded logic, brittle when schemas change	Visual drag-and-drop with conditional rules, no coding required
Status Translation	Manual state-to-integer tables hardcoded in script	Built-in conditional mapping engine handles all ServiceNow state integers
Comments & Attachments	Often omitted; binary attachments frequently fail silently	Full transfer with timestamp and authorship; binary handling with retry logic
Duplicate Prevention	Manual deduplication logic required; frequently missing	Last Time expression engine prevents duplicate creation automatically
Error Handling	Errors halt migration or produce silent failures	Comprehensive logging, automatic retry queuing, real-time visibility
Bidirectional Sync	Not supported without significant additional development	Native bidirectional sync for parallel operation
Data Storage	Many scripts cache data locally - security risk	Zero data storage - no transferred data retained by ZigiOps
Security Certification	No certification; depends on developer practices	ISO 27001 certified, enterprise-grade security
Transaction Limits	Depends on infrastructure; rate limiting often unhandled	Unlimited transactions, automatic API rate limit management
Time to First Run	Weeks to months of development and testing	Pre-built templates enable a first run within hours

ZigiOps vs manual migration: capability comparison for IT teams evaluating ServiceNow to Jira migration tooling.

Ensuring ServiceNow Jira Migration No Data Loss: The Checklist

Before the Migration

✓ Complete the Pre-Migration Readiness Scorecard (all Critical items)

✓ Inventory all ServiceNow tables, fields, and custom configurations in scope

✓ Document all workflow states and map them to Jira equivalents before touching a single record

✓ Audit user accounts in both systems and prepare a user mapping table

✓ Confirm the Jira target environment is fully configured before migration starts

✓ Define migration scope: date range, ticket types, assignment groups

✓ Configure Last Time expressions in ZigiOps for all operations

✓ Establish a rollback plan

During the Migration

✓ Use a platform with built-in error handling, retry logic, and duplicate prevention

✓ Run a pilot migration before committing to full-scale transfer

✓ Validate pilot results: field values, comments, attachments, user assignments, and statuses

✓ Monitor progress in real time and log all migration events

After the Migration

✓ Spot-check records across all ticket types and data categories

✓ Run reconciliation checks to identify missing or duplicated records

✓ Confirm comment history, attachment integrity, and user assignment accuracy

✓ Obtain sign-off from operational teams before decommissioning ServiceNow

✓ Archive ServiceNow data per your data retention policy

Make Your Migration from ServiceNow to Jira Reliable from Day 1

A data migration from ServiceNow to Jira is not a weekend project, and it is not a task that rewards shortcuts. The risks are real and specific: mismatched field mappings, lost comment history, broken status transitions, missing attachments, duplicate records from absent Last Time logic, and interrupted transfers that leave data in an inconsistent state across two platforms. Each of these failure points is preventable with the right preparation and the right tooling.

ZigiOps gives your team the most complete, no-code solution available for migrating tickets from ServiceNow to Jira with full data integrity, operational continuity, and end-to-end visibility. From pre-built templates and visual field mapping with conditional status translation, to duplicate-preventing Last Time expressions, bidirectional sync, zero data storage, and ISO 27001-certified security, ZigiOps is purpose-built for the complexity of real-world ITSM migrations.

Whether you are planning a phased migration over several months or a focused cutover within weeks, ZigiOps delivers the confidence and the capability to achieve a true ServiceNow Jira migration no data loss outcome - without writing a single line of code, and without keeping your data a moment longer than necessary.

‍

FAQ