Migrate from Jira Service Management to ServiceNow: Technical Guide

Why Do Companies Outgrow Jira Service Management for ServiceNow?

Most teams don't leave JSM because it's bad. They leave because their organization has outgrown what a project-based ITSM can do. JSM is built on Jira's core issue-tracking engine — flexible by design, effective for engineering-led teams that prioritize speed and tight integration with the Atlassian stack. (support.atlassian.com)

The trigger is usually one of these:

• 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.

The decision to migrate is usually driven by audit requirements, M&A integration, or scaling beyond a few hundred agents — not by dissatisfaction with JSM itself. For a deeper look at the architectural differences, see our ServiceNow vs Jira Service Management Architecture Guide (2026).

How Do Jira Issue Types Map to ServiceNow Tables?

This is where the data-model gap hits hardest. In JSM, everything is a Jira issue with an issue type label. Atlassian layers request types on top of work types: one request type maps to one work type, and one work type can support many request types. Work items created without a request type lose some JSM behavior (e.g., SLA tracking, customer portal visibility, queue eligibility). (support.atlassian.com)

In ServiceNow, each ITSM process lives on a separate table that extends the base task table. There is no equivalent of Atlassian's customer-facing request type wrapper — you must decide during design whether the request type determines the target table, survives as metadata on a custom field, or both.

Extraction Script Pseudocode: Issue Type Routing

# Pseudocode: Route JSM issues to correct ServiceNow tables
TABLE_MAP = {
    "Incident": "incident",
    "Service Request": "sc_req_item",
    "Service Request with Approvals": "sc_req_item",
    "Problem": "problem",
    "Change": "change_request",
    "Post-Incident Review": "problem",  # Map PIRs to problem table
}
 
for issue in jira_issues:
    issue_type = issue["fields"]["issuetype"]["name"]
    target_table = TABLE_MAP.get(issue_type)
    if target_table is None:
        log_warning(f"Unmapped issue type: {issue_type} on {issue['key']}")
        target_table = "task"  # Fallback to base table, flag for review
    route_to_servicenow(issue, target_table)

How Do Jira Statuses Map to ServiceNow State Values?

This is the single most misunderstood mapping in JSM-to-ServiceNow migrations. JSM uses semantic, human-readable statuses that are project-specific and workflow-configurable. ServiceNow uses deterministic, numeric state integers. (support.atlassian.com)

ServiceNow's out-of-box incident states:

These values are not sequential — 4 and 5 are intentionally skipped in modern ServiceNow releases (they were used in legacy Fuji/Geneva instances for "Awaiting User Info" and "Awaiting Evidence"). Custom states can be added, but active states must have values below 6, since the platform treats 6+ as terminal states that trigger SLA completion and prevent re-assignment without explicit reopen logic.

State models differ by table. The problem table defaults to:

The change_request table uses an entirely different range:

You cannot push a string like "Waiting on Customer" into ServiceNow's state field — your migration script must evaluate each Jira status string, map it to the correct ServiceNow integer on the correct table, and ensure the target state is valid according to ServiceNow's state transition rules.

Example State Mapping Table

# Incident state mapping from JSM to ServiceNow
INCIDENT_STATE_MAP = {
    "Open": 1,
    "To Do": 1,
    "In Progress": 2,
    "Working": 2,
    "Waiting for Support": 3,      # On Hold
    "Waiting for Customer": 3,     # On Hold - set hold_reason = "Awaiting Caller"
    "Pending": 3,
    "Resolved": 6,
    "Done": 7,
    "Closed": 7,
    "Cancelled": 7,                # Set close_code = "Cancelled"
}

How Do JSM Queues Map to ServiceNow Assignment Groups?

They don't — at least not directly. This is a fundamental model mismatch.

JSM queues are JQL filters. A queue is a saved query like project = SUPPORT AND status = Open AND priority = High. Tickets aren't "assigned" to a queue; they appear in a queue if they match the JQL at that moment. One ticket can appear in multiple queues simultaneously. (support.atlassian.com)

ServiceNow Assignment Groups are strict user-membership entities stored in the sys_user_group table. A ticket's assignment_group field is a reference to a single group. Routing is handled by assignment rules, not filters.

The migration approach:

1. Audit your JSM queues. Export each queue's underlying JQL and document the intent (e.g., "Tier 1 Support — all P1/P2 incidents").
2. Create corresponding Assignment Groups in ServiceNow with the appropriate members. By default, task.assignment_group is filtered to groups of type itil. If you create new groups during migration and miss the type or membership model, records may load successfully but be unassignable in the UI or ignored by assignment rules. (servicenow.com)
3. Build assignment rules or Flow Designer flows that replicate the queue logic as routing rules. ServiceNow's Assignment Lookup Rules (sla_assignment) evaluate category, subcategory, and configuration item to route to groups.
4. Set the assignment_group field on each migrated record based on which queue the ticket was primarily associated with in JSM.

Write queue mappings explicitly. Do not let them live only in an admin's memory. A small spec like this exposes the hidden logic before you build assignment rules:

queue: P1 - Network Unassigned
jql: project = ITSM AND priority = Highest AND component = Network AND assignee is EMPTY AND statusCategory != Done
targetAssignmentGroup: Network Support
servicenowGroupSysId: "a1b2c3d4e5f6..."
routingRule: incident.category = network AND priority = 1
groupType: itil
members:
  - network-admin@company.com
  - network-engineer@company.com

You'll lose the "ticket appears in multiple views" behavior. ServiceNow's equivalent is saved list filters or Service Operations Workspace (SOW) Agent Queues — but those are presentation-layer, not data-layer concepts. SOW Queues use Advanced Work Assignment (AWA) conditions, which are closer to JSM's model but require the ITSM Professional license tier.

How Do You Migrate Jira Custom Fields to ServiceNow?

JSM custom fields live on the Jira issue and are configured per project or globally. ServiceNow custom fields are columns on specific tables (incident, problem, change_request) or on the base task table. Custom fields in ServiceNow are prefixed with u_ by convention (e.g., u_business_justification).

Before migration, export your JSM custom field definitions via the Jira REST API (GET /rest/api/3/field) and map each one to a ServiceNow dictionary entry. Fields that don't exist on the target table must be created via the sys_dictionary table or the Table & Column editor before import.

User Mapping

User mapping deserves special attention. ServiceNow links all records to a user via a 32-character GUID called a sys_id. Jira Cloud identifies users by their Atlassian Account ID (a UUID like 5b10ac8d14c05b22cc7d4ef5). Before migrating tickets, extract all Jira users via GET /rest/api/3/users/search, map their email addresses to the sys_user table in ServiceNow, and store the resulting sys_ids in a lookup table.

# Pseudocode: Build user lookup table
user_map = {}
jira_users = jira_api.get("/rest/api/3/users/search?maxResults=1000")
for jira_user in jira_users:
    email = jira_user["emailAddress"]
    sn_user = servicenow_api.get(
        f"/api/now/table/sys_user?sysparm_query=email={email}&sysparm_fields=sys_id"
    )
    if sn_user["result"]:
        user_map[jira_user["accountId"]] = sn_user["result"][0]["sys_id"]
    else:
        log_warning(f"No ServiceNow user found for {email}")
        user_map[jira_user["accountId"]] = DEFAULT_INTEGRATION_USER_SYS_ID

If your script attempts to assign an incident to an email address instead of a sys_id, ServiceNow will either reject the payload (if the field is a strict reference) or assign the ticket to the API integration user, destroying your historical audit trail.

Permission Mapping

ServiceNow handles permissions differently from JSM. JSM uses project roles (Administrator, Agent, Customer); ServiceNow uses groups and roles on the sys_user_has_role table. Key role mappings:

Permission mapping must be planned separately from data migration.

How Do You Migrate JSM SLAs to ServiceNow's task_sla Table?

SLA migration is where most DIY efforts break down. JSM tracks SLAs as time-based goals attached to issues with start, pause, and stop timestamps. ServiceNow stores SLA data in the task_sla table, with each record tracking elapsed time (business_time_left), pause duration (business_pause_duration), percentage complete (business_percentage), and breach datetime (planned_end_time). You cannot simply import a final "SLA met/breached" value — ServiceNow calculates SLAs dynamically based on schedules, conditions, and timestamps.

The task_sla table key fields:

The migration process:

1. Extract JSM SLA cycle data via the REST API (GET /rest/servicedeskapi/request/{issueIdOrKey}/sla). You need the full lifecycle: startedAt, stoppedAt, elapsedTime, remainingTime, breached, and paused values — not just the screen value. If you have Atlassian Analytics, the JSM SLA schema (jsm_sla dataset) exposes this normalized cycle data with millisecond precision. (support.atlassian.com)
2. Create SLA Definitions in ServiceNow (contract_sla table) that match your JSM SLA policies (e.g., "P1 Response: 1 hour," "P2 Resolution: 8 business hours"). Ensure the associated schedule (cmn_schedule) matches your JSM business hours calendar.
3. Insert records into task_sla with the historical timestamps in ISO 8601 datetime format (UTC), associating them with the correct incident sys_id and contract_sla sys_id. (servicenow.com)
4. Run the SLA Repair utility. This is the step most teams miss. ServiceNow's SLA engine uses a History Walker to reconstruct SLA records from the task's audit history (sys_audit table). After importing historical task_sla records, SLA Repair recalculates elapsed times and breach indicators based on the imported data rather than the current system time.

For large datasets, batch the SLA Repair operation — running it on 10,000+ records at once can cause significant performance degradation (expect 2–4 hours per 10,000 records depending on audit history depth). Avoid dot-walk-heavy pause logic where possible, because SLA Repair only sees the final state of dot-walk fields, not their full historical progression.

A practical decision point: if you only need historical SLA data for reporting, keep Jira SLA outcomes in custom audit fields (u_original_sla_met, u_original_breach_time) and let native ServiceNow SLAs start fresh at cutover. If you need historical SLAs to behave like native ServiceNow records — e.g., for continuous improvement trend analysis or contractual SLA reporting — map Jira cycle timestamps into a task_sla-compatible model and test SLA Repair thoroughly in a sub-production instance before touching production.

How Do You Migrate JSM Assets to ServiceNow CMDB?

If you're using JSM's Assets feature (formerly Insight), migrating to ServiceNow's CMDB requires translating a schema-free, object-type model into ServiceNow's normalized class hierarchy.

Key structural differences:

Migration approach:

1. Map JSM Object Types to CMDB classes. Use ServiceNow's CSDM as the guide. JSM's "Server" object type → cmdb_ci_server. JSM's "Application" → cmdb_ci_appl. Document types that have no CMDB equivalent and decide whether to extend the CMDB schema or map to a generic class.
2. Export JSM Assets via the Assets REST API (GET /jsm/assets/workspace/{workspaceId}/v1/object/list).
3. Transform attributes to match CMDB field types. Freeform text fields that contain IP addresses must map to validated ip_address fields. Serial numbers must map to serial_number on the correct hardware class.
4. Import CIs via the ServiceNow CMDB Identification and Reconciliation Engine (IRE) rather than direct table inserts. IRE uses identification rules to prevent duplicates and maintain CI integrity. Direct inserts bypass IRE and can create orphaned or duplicate CIs.
5. Rebuild relationships in the cmdb_rel_ci table with the correct cmdb_rel_type references.

How Do You Translate Jira Automation Rules to ServiceNow Flow Designer?

Automation cannot be migrated programmatically. Jira's "when-if-then" rules and ServiceNow's Flow Designer share a broad structural similarity — trigger, conditions, actions — but the implementation paradigms are too different for automated conversion. Do not attempt to write a script that converts Jira automation JSON into ServiceNow Flow Designer XML. (support.atlassian.com)

Not every Jira rule belongs in Flow Designer. ServiceNow's Flow Designer queues execution asynchronously when trigger conditions occur, while Business Rules remain the better fit for tight server-side validation, pre-insert guards, or immediate state enforcement tied directly to record operations. ServiceNow documents a default limit of 50 actions per flow unless you change the com.glide.hub.flow_engine.max_flow_actions system property. (servicenow.com)

Decision matrix for where to rebuild each rule:

Practical approach:

1. Export your JSM automation rules (there's no bulk API — screenshot or document each rule manually, including the rule's audit log showing execution frequency).
2. Categorize rules by complexity and execution frequency. Simple routing and field-update rules can become Business Rules; multi-step approval workflows and cross-table orchestration belong in Flow Designer.
3. Rebuild in ServiceNow. For simple field-update rules, a Business Rule with a script is faster to build than a Flow Designer flow. For anything involving approvals, notifications, or cross-platform integrations, use Flow Designer.
4. Test each rebuilt rule in a sub-production instance before go-live. Use ServiceNow's Flow Designer test mode, which allows you to run flows with test records without affecting production data.

ServiceNow's Flow Designer also integrates with IntegrationHub for cross-platform orchestration — something JSM automation can't do natively. Take the migration as an opportunity to consolidate scattered webhook-based automations into proper IntegrationHub spokes.

How Do You Migrate Confluence Knowledge Base to ServiceNow Knowledge?

This is consistently the most painful part of a JSM-to-ServiceNow migration. The native options are poor on both sides.

ServiceNow's built-in import tools don't work well for Confluence:

• Import from External Knowledge Sources: Expects a publicly reachable WebDAV endpoint, supports only Basic auth, and creates a blank knowledge article with the source file attached for each imported file. That's document harvesting, not article migration. (servicenow.com)
• Easy Import: Loses all images and formatting. Designed for CSV with plain text content.
• Import from Word: Numerous formatting issues with complex tables, embedded images, and Confluence macros. Maximum file size of 5 MB per document.

One ServiceNow community user who evaluated all available options for migrating 2,000 articles from Confluence concluded that none of the native tools worked and opted to hire contractors for manual migration.

Confluence Cloud's export options are also limited. Confluence Cloud can export spaces as HTML, CSV, PDF, or XML, but Atlassian notes that page comments are not exported in HTML. More significantly, Atlassian says Confluence Cloud XML site and space export reaches end of life on December 1, 2026 — the feature continues to work, but Atlassian will no longer fix bugs or provide SLAs for it. (support.atlassian.com)

The proper approach is API-driven:

1. Extract Confluence content as HTML via the REST API (GET /wiki/api/v2/pages/{id}?body-format=storage). This gives you the full HTML body with inline image references in Confluence's XHTML-based storage format. (developer.atlassian.com)
2. Download all attachments separately (GET /wiki/api/v2/pages/{id}/attachments) and re-upload them to ServiceNow as sys_attachment records on the corresponding kb_knowledge article. Rewrite the HTML body to replace Confluence image URLs with new ServiceNow attachment URLs (/sys_attachment.do?sys_id=...).
3. Transform the HTML. Strip Confluence-specific CSS and macros. Confluence's storage format includes custom macros (<ac:structured-macro>) that ServiceNow won't render. Build a macro register during discovery: decide for each macro type whether to render to HTML, replace with static text, attach a file, or drop the element.

Common macro handling decisions:

4. Insert articles via the ServiceNow Table API (POST /api/now/table/kb_knowledge), setting fields like kb_knowledge_base, kb_category, workflow_state (set to published for active articles), short_description, and text (the transformed HTML body).
5. Rewrite internal links. Any Confluence page-to-page links must be updated to point to the new ServiceNow KB article URLs. Build a redirect map: {confluence_page_id: servicenow_kb_sys_id} and do a find-replace across all article bodies after import.
6. Migrate page metadata. Map Confluence labels to ServiceNow KB article tags. Map Confluence space keys to ServiceNow Knowledge Bases. Map Confluence page hierarchy (parent/child) to ServiceNow KB categories.

For more on Confluence migration complexity, see our Confluence import guide.

Pre-Migration Preparation

Audit Your JSM Data Model

• Export all issue types, custom fields, workflows, and statuses via the Jira REST API (GET /rest/api/3/field, GET /rest/api/3/workflow/search, GET /rest/api/3/status).
• Document every JQL-based queue and its member agents.
• Map every request type to its underlying work type and fields. (support.atlassian.com)
• Export your automation rules (there's no bulk export — document each rule manually, noting trigger frequency from the rule audit log).
• If you have Atlassian Analytics, jsm_issue, jsm_incident, jsm_change, and jsm_sla schemas are useful for count reconciliation and historical validation.
• Record total counts per issue type per project — these are your reconciliation baselines.

Clean Your Data Before Export

• Archive or delete test tickets, spam, and duplicate issues. In a typical JSM instance, 5–15% of tickets are test data or duplicates.
• Standardize status values across projects — if "Completed" and "Done" mean the same thing, unify them before migration rather than maintaining two mappings.
• Verify that all user accounts have valid email addresses (ServiceNow resolves users by email). Deactivated Jira users should still be mapped to ServiceNow for historical record integrity.
• Tag every comment stream as public or internal before load. JSM's GET /rest/servicedeskapi/request/{issueIdOrKey}/comment endpoint returns a public boolean on each comment — use this to separate work_notes from comments during import.

Account for API Rate Limits on Both Sides

Jira Cloud enforces points-based rate limiting on REST APIs, with burst limits per second and per-hour quotas. Atlassian's current guidance says app-based integrations are subject to points-based quotas starting March 2, 2026, while API-token traffic still hits burst limits (typically 100 requests per 10-second window for standard tenants). (developer.atlassian.com)

On the ServiceNow side, inbound REST API rate limits are governed by sys_rate_limit_rules and enforced per user per hour (default: no limit, but many organizations set 1,000–10,000 requests/hour per integration user). Plan your extraction and loading scripts to handle 429 Too Many Requests responses with exponential backoff on both sides.

# Pseudocode: Exponential backoff for rate-limited API calls
def api_call_with_retry(url, max_retries=5):
    for attempt in range(max_retries):
        response = http_get(url)
        if response.status_code == 429:
            retry_after = int(response.headers.get("Retry-After", 2 ** attempt))
            sleep(retry_after)
            continue
        return response
    raise Exception(f"Max retries exceeded for {url}")

Handle Attachments Separately

Jira attachments are stored per-issue and must be downloaded individually via the REST API (GET /rest/api/3/attachment/content/{id}). ServiceNow Import Sets have per-processor size constraints — oversized rows can be skipped silently, and large file uploads can fail with partial data loads. ServiceNow's default attachment size limit is 24 MB per file (configurable via com.glide.attachment.max_size). Large attachment-heavy migrations should be batched and loaded via the ServiceNow Attachment API (POST /api/now/attachment/file) rather than Import Sets. (servicenow.com)

Prepare Your ServiceNow Instance

• Create all Assignment Groups (with the correct itil group type), SLA Definitions (contract_sla records), and Service Catalog items before importing any data.
• Configure dictionary entries for custom fields on each target table.
• Set up a dedicated integration user with rest_api_explorer, import_set_loader, import_transformer, and table-specific write roles. Allocate rate limit headroom.
• Configure business schedules (cmn_schedule) to match your JSM business hours before SLA import.
• Freeze new request types, queue edits, and automation changes during the final validation window.
• Take a snapshot of the sub-production instance before test loads so you can roll back cleanly.

Consider Your Tooling Options

Native ServiceNow Import Sets and the Table API are the DIY path. Tools like Exalate and Getint position themselves as bidirectional sync layers between Jira and ServiceNow. Precision Bridge positions itself as a template-driven migration platform for ITSM data. These tools can reduce plumbing, but they do not solve target-state design: queue ownership, change models, KB fidelity, and SLA semantics still need deliberate human decisions.

Plan Your Rollback Strategy

If migration fails mid-flight:

1. Before migration: Export a full baseline of ServiceNow target tables using sys_export_set or Update Sets for configuration changes.
2. 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.
3. After failed migration: Delete records by batch ID, restore configuration from Update Sets, and re-run from the failed batch.
4. JSM remains operational throughout — never decommission JSM until ServiceNow is fully validated and in production.

Migration Timeline

The biggest timeline variables are Confluence KB complexity, the number of JSM automation rules that need to be rebuilt in Flow Designer, and SLA behavior requirements. A JSM instance with 50 automation rules and 2,000 KB articles takes significantly longer than one with 10 rules and no KB. Simple migrations with under 10,000 tickets and no KB can finish in under 2 weeks.

We recommend a parallel run strategy rather than a hard cutover. Use a delta migration approach: sync historical data in the background while your team continues working in JSM, followed by a final weekend sync to capture the latest updates. The delta sync identifies records modified since the last extraction using JSM's updated JQL field and ServiceNow's sys_updated_on timestamp. For broader context on migration planning, see our Help Desk Data Migration Timeline guide.

Common Pitfalls and How to Avoid Them

1. Mapping all JSM issues to the incident table. JSM projects often contain mixed issue types. Dumping everything into incident breaks ServiceNow's ITIL process separation and corrupts reporting. Split by issue type during extraction, not after import. Use the routing pseudocode above.

2. Ignoring the internal/public comment distinction. JSM has internal comments (visible to agents only) and customer-visible comments. ServiceNow uses work_notes (internal) and comments (customer-visible, called "Additional comments") on the task record. If your migration script doesn't distinguish between these, internal notes become visible to end users in the Service Portal. This is a privacy and compliance issue, not a formatting issue — it can expose PII, internal troubleshooting notes, or security-sensitive information. (developer.atlassian.com)

3. Losing SLA history by skipping the SLA Repair step. Importing tickets without running SLA Repair means ServiceNow applies current SLA definitions from import time. Historical compliance data is gone. Always import SLA timestamps and run repair in batches of 5,000–10,000 records.

4. Treating Confluence macros as HTML. Confluence macros (status labels, expand blocks, table-of-contents, JIRA issue links) are not standard HTML. They render as broken markup or raw XML tags in ServiceNow KB. Use the macro register approach described above to handle each macro type explicitly during transformation.

5. Not testing state transitions. ServiceNow enforces state transition rules — you can't always jump from state 1 (New) to state 7 (Closed) without passing through intermediate states. If your import script sets a closed state on a record that never transitioned through "In Progress" and "Resolved," Business Rules or Flow Designer flows tied to those transitions won't fire, and audit trails will be incomplete. Workaround: Temporarily disable state transition Business Rules during import (specifically incident_state_transition_validation), then re-enable after migration.

6. Silent failures on large Import Set loads. ServiceNow Import Sets can skip oversized rows or fail to process large files without clear error messages. The import appears to complete but only processes a fraction of records. Always validate row counts after each import batch: compare SELECT COUNT(*) FROM import_set_row WHERE import_set = '{sys_id}' AND sys_import_state = 'error' against your source count.

7. Phantom ownership from queue-to-group mapping. Copying queue names as assignment groups without setting the correct group types, memberships, or routing rules means records load successfully but are unassignable in the UI or ignored by assignment rules. Design the ownership model explicitly, including the type field on sys_user_group.

8. Timezone mismatches on datetime fields. JSM stores and displays datetimes in the user's configured timezone. ServiceNow stores all datetimes internally in UTC. If your extraction script doesn't normalize to UTC before import, timestamps will be off by the offset of whatever timezone the Jira admin account uses. Always convert to ISO 8601 UTC (2025-06-15T14:30:00Z) before loading.

9. Missing Service Catalog design. JSM request types map to ServiceNow catalog items, but catalog items require variables (form fields), variable sets, execution plans, and approval policies. Simply creating a catalog item with a matching name but no variables means end users see a blank form. Design catalog items with the same fields that existed on the JSM request type forms.

If a migration has already gone sideways, our migration rescue guide covers recovery strategies.

How ClonePartner Handles JSM-to-ServiceNow Migrations

We've completed 1,500+ data migrations across ITSM, CRM, and ERP platforms. JSM-to-ServiceNow is a migration we've executed repeatedly, and we know where the failure modes hide.

Our approach:

• API-first extraction and loading. We don't rely on CSV exports or Import Sets for anything beyond simple reference data. Custom scripts extract from Jira's REST API and load directly into ServiceNow's Table API with proper batching, retry logic, and rate limit handling.
• SLA timestamp preservation. We map historical SLA data to task_sla with full start/pause/stop timestamps and run SLA Repair in controlled batches — preserving your compliance history.
• CMDB migration with IRE. We use ServiceNow's Identification and Reconciliation Engine for CI imports, preventing duplicate or orphaned CIs that plague direct-insert approaches.
• Confluence KB migration with formatting intact. We parse Confluence storage format, strip macros per a documented macro register, re-host images as ServiceNow attachments, and rewrite internal links. No manual copy-paste.
• Zero-downtime execution. Both platforms stay operational during migration. We run delta syncs to capture records created during the migration window. See our zero-downtime migration approach for how this works.
• Compliance-ready. SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliant. Your data never touches an uncontrolled environment.

If your JSM instance is small — few request types, no KB, no SLA backfill — an in-house script can be reasonable. Once you need audit-grade history or a weekend cutover with little tolerance for rework, it usually stops being a side project.