ServiceNow to JSM Migration: What Actually Needs to Move?
What if the hardest part of an ITSM migration isn't moving the data, but deciding what deserves to move in the first place?
ServiceNow has long been a strong choice for enterprises managing complex workflows, IT operations, assets, and large-scale service environments. However, as technology stacks evolve, enterprise customers are reassessing the economics and architecture of ITSM, including cost, complexity, ROI, efficiency, governance, security and compliance, user experience, AI-enabled workflows, deeper integration with existing tools, and the ability to connect service management with development and business workflows.
According to a recent report, over 80% of the Fortune 500 use Atlassian, and more than 1,000 customers had upgraded to Atlassian's Teamwork Collection in under three quarters, reflecting growing enterprise adoption of its broader platform.
This is particularly relevant for businesses already invested in a broader technology ecosystem like Jira, Confluence, and the wider Atlassian ecosystem. When development, knowledge management, collaboration, and service operations already run on connected tools, organizations may prefer an ITSM platform that fits naturally into that ecosystem rather than maintaining separate platforms, integrations, data flows, and user experiences.
For organizations already invested in the Atlassian ecosystem, Jira Service Management (JSM) can bring ITSM closer to development, knowledge, and service workflows. A ServiceNow to JSM migration can therefore become an opportunity to rationalize the existing environment, retaining what supports the business, redesigning what can work better, and removing legacy complexity that no longer adds value.
1. Users, Roles, and Permissions: Define What JSM Needs to Support
A successful migration starts with the target environment, not the existing ServiceNow configuration. Before moving data, define how JSM should support the business after cutover and which parts of the current environment are actually required.
This means establishing the target structure for:
- Services and requests: How employees will access and categorize services.
- Users and permissions: Who can access, manage, approve, and administer services.
- Workflows: Which processes, states, approvals, and escalations need to exist in JSM.
- SLAs: How response and resolution commitments will be calculated.
- Assets and relationships: How applications, infrastructure, devices, and services will be represented.
- Knowledge: Which existing content should be migrated, updated, or consolidated.
- Integrations and APIs: Which systems need to exchange data with JSM.
- Reporting and history: What information needs to be available for operations, compliance, and decision-making.
This changes the migration conversation from “How do we move everything?” to “What does the business actually need in the target environment?”
That distinction becomes particularly important when an organization already uses Jira Software, Confluence, or other Atlassian products. JSM can connect service management with development and knowledge workflows, but that value depends on designing the target environment properly.
Let's look at what should move, what should change, and what should stay behind in a ServiceNow to JSM migration.
2. Data and Records: Build a ServiceNow Data Migration Map
A ServiceNow instance can contain years of incidents, requests, problems, changes, users, configuration items, attachments, and historical information.
Not all of it belongs in JSM.
A practical ServiceNow data migration should classify information into four groups:
- Migrate: Active records and data required for day-one operations.
- Transform: Information that needs restructuring before entering JSM.
- Archive: Historical information required for audit, reporting, or reference.
- Retire: Obsolete configurations and records with no continuing business value.
For example, active incidents and changes may need to move into JSM, while years of closed tickets may be better retained in an archive rather than transferred into the production environment. This reduces migration volume and gives the target platform a cleaner data foundation.
3. Workflows and Business Rules: Redesign Workflows for JSM
ServiceNow workflows should not automatically be recreated one-for-one in JSM.
The two platforms approach workflow configuration differently, so direct replication can introduce unnecessary states, approvals, and custom logic.
Instead, deconstruct each critical workflow:
Trigger → Condition → Routing → Approval → Automation → SLA → Resolution
Then map the business requirement to the appropriate JSM configuration.
A ServiceNow workflow with multiple scripted rules, for example, may be replaced by a combination of JSM workflows, automation, request types, and integrations.
The objective is functional continuity, not configuration duplication.
4. SLAs and Service Commitments: SLAs Need Logic Mapping, Not Field Mapping
SLAs are one of the more technically sensitive parts of a ServiceNow to JSM migration because they define the conditions and business rules used to measure service performance against agreed targets. During migration, teams need to map the underlying logic, including:
- Start and stop conditions
- Pause rules and business calendars
- Priority- and assignment-based targets
- Escalation rules and time zones
These rules should then be recreated and tested in JSM to ensure service commitments continue to be measured consistently. Historical SLA data should be migrated as reference data rather than treated as active JSM SLA logic.
5. Assets and CMDB Relationships: Map CMDB Data to JSM Assets
One of the most important technical considerations in a ServiceNow migration to JSM is the treatment of CMDB and asset data.
ServiceNow CMDB structures and JSM Assets are not interchangeable.
Instead of simply importing configuration items, map the underlying model:
- CI class → Assets object type
- CI attribute → Object attribute
- CI relationship → Object relationship
Then validate ownership, dependencies, duplicates, and data quality.
JSM Assets can provide a structured foundation for services, applications, and technology relationships, but the migration should rationalize the existing model rather than reproduce every legacy CI.
This is particularly valuable when the existing ServiceNow CMDB contains duplicate, stale, or poorly maintained records.
6. Integrations and APIs: Integrations Need to Be Reassessed, Not Simply Reconnected
An ITSM platform rarely operates in isolation. A ServiceNow environment may exchange data with identity, monitoring, security, HR, ERP, DevOps, and collaboration systems, so each integration needs to be evaluated as part of the migration.
Rather than rebuilding every existing connection in JSM, classify integrations as:
- Retire: Remove integrations supporting assets or information that are no longer required.
- Replace: Use a native JSM capability or another integration.
- Rebuild: Recreate the existing business function.
- Redesign: Change the workflow to improve how systems interact.
- Temporarily retain: Maintain the integration during a phased migration.
For example, if a monitoring tool currently creates a ServiceNow incident whenever an infrastructure threshold is breached, the JSM design could use JSM alerts and automation to route, enrich, prioritize, or trigger the appropriate response instead of simply recreating the same endpoint.
JSM can also integrate with ServiceNow for incident and alert synchronization, which can help organizations maintain interoperability while moving services in phases.
Integrate Jira Service Management with ServiceNow
7. Knowledge and Service Data: What Needs to Be Cleaned Before Migration
AI is becoming part of how JSM can handle various tasks and operations. The virtual service agent in JSM uses generative AI to search connected knowledge bases, answer questions, maintain conversation context, and route requests. Its AI capabilities can also generate automation flows, summarize work items, support natural-language search, and provide AI-powered change-risk assessments.
That makes the quality of migrated data important. Before moving to JSM, review:
- Knowledge: Remove duplicates and outdated content.
- Service data: Standardize service and request names.
- Assets: Validate relationships and ownership.
- Historical records: Improve classification where it will support future analysis.
- Automation: Review existing triggers and rules for reuse or redesign.
The business value of these AI capabilities depends on having structured, accessible, and permission-controlled information that JSM can use effectively. This is especially relevant as 2026 research shows that while 84% of ITSM professionals say AI has met or exceeded ROI expectations, 52% report that workload has stayed the same or increased. This highlights the importance of implementing AI around well-structured workflows rather than simply adding AI tools.
Don't Turn the Cutover Into a Single-Day Experiment
For complex enterprises, migration should be treated as a controlled transition rather than a single export-and-import event.
A practical migration sequence is:
Discover → Clean → Map → Pilot → Validate → Migrate → Cut over → Stabilize
A pilot migration allows teams to test:
- Data integrity
- Workflow behavior
- SLA calculations
- Permissions
- Integrations
- Reports
- Automation
The final migration can then focus on delta data and validated configurations rather than discovering problems during production cutover.
The Real Success Metric: What Works After Migration?
A technically complete migration isn't necessarily a successful one. The stronger measure is whether the organization can operate effectively in JSM after the transition.
That means validating:
- Data: Is the right information available?
- Workflows: Do critical processes function as intended?
- Context: Are services, assets, and changes connected?
- Integrations: Do downstream systems still exchange information?
- Experience: Can employees and agents complete work without unnecessary friction?
- Governance: Are access, audit, and approval requirements preserved?
The best JSM migration is therefore not the one that moves the most records.
It is the one that creates the right target environment with the least unnecessary legacy complexity.
How Clovity Helps Organizations Move From ServiceNow to JSM
A ServiceNow to JSM migration requires more than data transfer. It requires decisions around architecture, data, workflows, assets, integrations, testing, and adoption.
As an Atlassian Platinum Solution Partner, Clovity helps organizations assess, plan, and execute JSM adoption and migration initiatives, including ServiceNow migration, data mapping, workflow transformation, integrations, Assets configuration, implementation, and post-migration support.
Clovity can help organizations move through the journey from:
Migration assessment → Target architecture → Data strategy → JSM configuration → Integration → Pilot → Cutover → Optimization
For businesses already using Atlassian products, the migration can also create stronger connections between Jira Software, Confluence, JSM, Assets, and other parts of the Atlassian ecosystem.
