Skip to content
ServiceNow to JSM

Move the service desk, not just the tickets.

Atlassian has no one-click ServiceNow to Jira Service Management migration, so the move is a planned program: redesign the request catalog, bring the CMDB into JSM Assets, rebuild approvals and SLAs, and import the ticket history you need to keep. Atlas Bench, an Atlassian Platinum Solution Partner, runs that program and keeps ServiceNow and JSM running side by side until each service cuts over.

ServiceNow to Jira Service Management migrations that carry over the request catalog, the CMDB, and the change process, redesigned for JSM instead of copied field for field.

request review approve change record who decides, and on what evidence the gate is defined before anything is automated L1 L2 L3 L4

The problem

Most ServiceNow exits start as a cost decision and stall as a process problem. Years of catalog items, custom tables, and approval rules have built up, and much of it no longer matches how the business works. Copy it field for field and you rebuild ServiceNow inside Jira, with the same cost of change and a worse fit.

The data also moves unevenly. CMDB records can come across into JSM Assets. Tickets can be imported, but with limits on comments, history, and SLAs that have to be planned for. A basic CSV import, for example, adds every comment as public. The plan has to decide early what moves, what gets archived, and what gets redesigned.

What the work is

Current-state discovery

Catalog items, assignment rules, approvals, SLAs, integrations, and CMDB classes inventoried, with usage data showing what people actually use.

Service design in JSM

Request types, portals, queues, and workflows designed for JSM, with the catalog cut to what is in use.

CMDB to Assets

Configuration items brought into JSM Assets. On Service Collection Premium and Enterprise, Data Manager can pull records from ServiceNow so they are cleaned and reconciled before they land.

Change and approval rebuild

Change types, approval paths, and the CAB process rebuilt so every change record carries the evidence auditors ask for.

Ticket and knowledge migration

Open work moved, closed history imported or archived by policy, and knowledge articles moved into the JSM knowledge base.

Parallel run and cutover

Services cut over in waves, with both tools running until each one is proven, and agents trained on the new queues.

How it runs

  1. Discover

    3 to 4 weeks

    Catalog, CMDB, change process, and integrations inventoried. Decisions made on what moves, what is archived, and what is redesigned.

  2. Build

    6 to 10 weeks

    JSM service projects, Assets schema, workflows, SLAs, and approvals built and tested with real requests.

  3. Cut over

    In waves

    Services move one wave at a time, with data validated, agents trained, and ServiceNow retired once the last wave is proven.

What you get

  • A current-state inventory of the ServiceNow catalog, CMDB, and change process
  • A JSM service design with request types, queues, workflows, and SLAs
  • CMDB data brought into JSM Assets, cleaned and reconciled
  • A rebuilt change and approval process with audit-ready records
  • Migrated open work, knowledge articles, and the ticket history your policy keeps
  • A wave-by-wave cutover plan and a ServiceNow retirement date

Questions we get

Does Atlassian have a tool that migrates ServiceNow to JSM?
No. Atlassian has no dedicated ServiceNow migration tool. Teams use its CSV importer and REST APIs, Marketplace apps, or a partner. We combine Data Manager for the CMDB, API or Marketplace tooling for tickets, and a rebuild for workflows and approvals.
Can we move our CMDB?
Yes. Configuration items can be imported into JSM Assets. Data Manager, included in Service Collection Premium and Enterprise, has a ServiceNow data source that reads the CI tables you choose, such as cmdb_ci_server, so records can be cleaned before they land.
Do we have to bring all our ticket history?
Usually not. Most teams move open work and a defined window of closed tickets, then archive the rest where auditors can still reach it. We set that policy with you during discovery.
Will our SLAs and approvals carry over?
They are rebuilt, not copied. JSM has its own SLA and approval model, and the rebuild is the chance to drop rules nobody follows.
How long do we run both tools?
Each service runs in parallel until its cutover is proven. The overlap is planned per wave so you do not pay for two platforms longer than you need to.
What does this have to do with agents?
Rovo agents in JSM work from your request types and knowledge base. A clean catalog and current knowledge articles are what let an agent answer requests correctly.

Find out what you are actually running.

Fixed scope. The assessment reads the estate as it is: instances, schemes, licensing, and the decisions a migration would force you to make anyway. You get the findings, the ownership gaps, and the order to close them in.