Cherwell to Jira Service Management migration: what moves, what you rebuild, and a plan before end of life

Who this guide is for

This is for Cherwell administrators, IT service managers and Atlassian admins at organisations where Jira Service Management is the likely replacement for Cherwell Service Management, usually because engineering already runs on Jira and Confluence. If you are still choosing a platform, read our Cherwell replacement guide first. If Freshservice is the target, see the companion Cherwell to Freshservice migration guide.

Facts come from vendor sources checked on Nov 10, 2026: the Ivanti Product End of Life hub for the date; Ivanti’s CSM documentation on Ivanti’s CSM documentation on Business Objects, CSM documentation on Relationships, the CSM “Export a Blueprint Schema” page and the Cherwell REST API documentation; and Atlassian’s Atlassian Service Collection / Jira Service Management pricing page, Atlassian guide to preparing data for Assets imports, Atlassian Assets Data Manager import page and Atlassian CSV importer documentation. Views on sequencing and design are ours, from service desk work.

The deadline and what it changes

On Nov 10, 2026 the Ivanti Product End of Life hub listed Cherwell Service Management (CSM) (EoL 12/31/2026) and Cherwell Asset Management (CAM) (EoL 12/31/2026). Ivanti announced the CSM end of life on October 31, 2023 (Ivanti’s Cherwell end-of-life announcement). Ivanti’s detailed end-of-life FAQ is behind a sign-in; partner-republished copies say on-premises perpetual installations keep running without support and cloud tenants become inaccessible 30 days after the date. Confirm both with Ivanti for your contract.

For a JSM move this has one practical consequence: export first, design second. JSM is flexible enough that teams are tempted to spend weeks designing the perfect space and Assets schema while the Cherwell cloud tenant clock runs. Take a complete export of data and schema in the first week, then design against the export rather than the live system.

How Cherwell and JSM model the service desk differently

Cherwell is built on Business Objects: Major objects such as Incident, Problem, Change, Knowledge Article, Customer, Configuration Item and Service; Supporting objects such as Task, Journal and Approval; Lookup objects that hold constrained values; and Group objects such as the Configuration Item group, whose members (Computer, Printer, Telephony Equipment) share fields from a Group Leader. Objects relate through owns and links relationships, and behaviour hangs off One-Step Actions and Automation Processes.

JSM splits the same world into two halves. Work lives as work items in service spaces, each with work types, request types, fields, workflows and queues. Things live in Assets, as objects in object schemas, with object types, attributes and references between objects. Assets is included in Service Collection Standard, Premium and Enterprise, with 5,000, 50,000 and 500,000 objects respectively before overage, which Atlassian prices from $0.02 per object per month with volume discounts.

Assets as the CMDB target: the most important design decision

If you get one thing right in a Cherwell to JSM move, make it the Assets schema. Cherwell CMDBs tend to be either very good (curated, related, used in change) or abandoned (populated once by discovery, never trusted). Either way, the migration is the chance to decide what the CMDB is for.

Design the schema from the Cherwell Group, not from a template

Use the Blueprint Schema export to list every member of the Configuration Item group and its fields. Create one Assets object type per CI class you actually use, with child object types where classes share attributes; Assets supports parent and child object types and attribute inheritance. Then map Cherwell relationships to reference attributes, for example Computer “used by” a Person, Application “runs on” a Server, Business Service “depends on” an Application.

Import rules that catch Cherwell exports

Atlassian’s Atlassian guide to preparing data for Assets imports sets out rules worth building into your export scripts from day one:

• CSV files need a header row and a single-character delimiter; multiple values in one attribute are separated with two pipe characters (||).
• The expected date format is MM/dd/yyyy. If your export uses another format, set the date format explicitly in the import structure.
• Objects are identified by the attribute assigned as the Label, not by Name or Key. Choose a stable Label (asset tag, hostname) before the first import.
• Users are identified by email address or Atlassian account ID; user names are not supported.
• JSON imports need an array selector, and objects are again matched on the Label attribute.
• Object type mappings must be enabled before the import structure can run.

Load in two passes. First create all objects with their own attributes; then run a second import that sets references, because a reference can only point at an object that already exists. Atlassian also documents Assets Data Manager for cleansing and reconciling data from multiple sources (Entra ID, Intune, SCCM, Jamf, Lansweeper, ServiceNow and others); Atlassian says Data Manager is included in all Service Collection Premium and Enterprise plans. If your Cherwell CMDB was fed by discovery, consider rebuilding from the source tools through Data Manager instead of importing stale Cherwell copies.

Size the object count before you pick a plan

Count your Cherwell CIs, plus anything else you plan to hold in Assets (people, locations, services, contracts). If the total is near 5,000, Standard’s allowance will be tight; Premium includes 50,000. Overage starts at $0.02 per object per month (about 1.5p at the Bank of England rate below). Do the count before signing, not after the import.

Mapping Cherwell records to JSM work items

Which import tool

Atlassian’s Atlassian CSV importer documentation covers the basic CSV importer: a header row with a Summary column, attachments by URL, multiple comments in repeated columns, users by email or Atlassian account ID, and a 250 work item limit per CSV file for users without administrator permissions. Two limits matter for Cherwell: the bulk-create CSV option cannot map parent-child relationships, so subtasks need the CSV External System Import that admins run from system settings; and Select List (cascading) custom fields also need the External System Import. Attachment URLs must be reachable by your Jira site, which usually means staging Cherwell attachments in temporary storage with expiring links.

For large histories or where you need exact timestamps and authorship, a migration partner using the Jira REST APIs is often faster than many CSV runs. Either way, run a sample load first and have agents work migrated items before the full load.

What you rebuild: automation, SLAs, portal

This is usually the largest piece of work in a Cherwell to JSM move. Teams that treat it as “recreate Cherwell in Jira” end up with brittle automation and dozens of custom fields. Teams that treat it as “what does the service desk need in 2027” finish faster.

Which JSM plan, and what it costs

Prices from the Atlassian Service Collection / Jira Service Management pricing page on Nov 10, 2026, at Atlassian’s default 75-agent view, billed monthly. Atlassian uses progressive per-agent pricing and its currency switcher shows USD and JPY but not GBP, so sterling figures are indicative only.

Indicative GBP conversions use the Bank of England daily spot rate (series XUDLUSS) of US$1.3360 per £1 for 6 Nov 2026, the latest published figure when we checked on Nov 10, 2026. They are not official UK prices: the vendor does not publish a GBP list price for these items, and your invoice currency, rate and VAT treatment may differ.

For the detail on tiers and how Assets allowances drive plan choice, see our Jira Service Management pricing guide. If you are moving from JSM Data Center rather than Cherwell, the JSM Data Center to Cloud guide covers that route.

A phased plan before and after Dec 31, 2026

If the calendar does not fit, phase it: open work, the last 12 months and the Assets schema before Dec 31, 2026; older history and lower-value custom objects from the export in January. On-premises customers with perpetual licences have more room, but should still treat Dec 31 as the end of vendor support.

Five mistakes we see in Cherwell to JSM moves

• Importing the CMDB before choosing a Label. Assets matches objects on the Label attribute. Change it later and re-imports create duplicates instead of updates.
• One service space per Cherwell team. Cherwell teams often map to dozens of small spaces. Start with one IT service space and use queues, request types and groups; split only where permissions or SLAs genuinely differ.
• Recreating every Cherwell field. Count how often each field is filled in the export. Fields that are empty on most records do not need to exist in Jira.
• Forgetting automation allowances. A Cherwell instance with heavy Automation Processes can burn through automation steps quickly once rebuilt. Estimate executions per month before choosing Standard.
• Leaving knowledge until last. Knowledge moves into Confluence, which may belong to a different admin team. Agree spaces, permissions and templates early, or agents go live without their articles.

None of these are JSM limitations. They are design shortcuts that feel quick in week two and cost time in month three.

Best for, and wrong choice when

Frequently asked questions

Related articles