Methodology: we compared Ivanti's Cherwell documentation, Atlassian's support, developer and licensing pages, Atlassian's own Cherwell guide, and partner write-ups on the end-of-life date, all checked on 12 Oct 2026. No vendor reviewed or paid for this article. We did not run hands-on tests.
A Cherwell to Jira Service Management migration moves Cherwell business objects (incidents, changes, knowledge articles, customers and configuration items) into JSM work items, Assets objects and Confluence pages, then rebuilds the automation on the JSM side. StrataCom and Beyond20 both report that Cherwell Service Management reaches end of life on 31 Dec 2026, which is 80 days after 12 Oct 2026. This page is for Cherwell owners who have already chosen JSM. It shows what moves, what does not, how fields map, and how to plan backwards from the deadline.
Key takeaways
- Cherwell Service Management end of life is 31 Dec 2026, according to StrataCom (which dates Ivanti's announcement to 31 Oct 2023) and Beyond20, both checked 12 Oct 2026.
- Atlassian's Cherwell guide maps business objects to issue types, CIs to Assets object records, and One-Step Actions to automation rules, and says to rebuild workflows rather than lift and shift them (as of 12 Oct 2026).
- Atlassian's CSV import documentation recommends about 1,500 work items per file and makes imported comments public in JSM spaces (as of 12 Oct 2026).
- Cherwell's grid export truncates long text at 300 characters by default (Ivanti documentation, as of 12 Oct 2026).
- Closed issues imported by CSV keep accruing SLA time unless you flag or transition them (Atlassian knowledge base, updated 26 Sep 2025).
Why teams move from Cherwell to Jira Service Management
Most Cherwell teams move because the product is ending, not because of a feature gap. Ivanti's Cherwell history page is headed "Cherwell products, now discontinued," and Ivanti's own route is a clean install into Ivanti Neurons for ITSM (Ivanti, as of 12 Oct 2026). Atlassian's guide, written with StrataCom, positions JSM as a replacement that can also run HR, facilities, legal and security workflows. These dates set your deadline.
| Date | What happened or happens | Source |
|---|---|---|
| 25 Mar 2021 | Ivanti acquired Cherwell | Ivanti Cherwell history page |
| 31 Oct 2023 | Ivanti announced the end of life date | StrataCom |
| 31 Dec 2026 | Cherwell Service Management end of life | StrataCom; Beyond20 |
| 30 days after | Cloud tenants no longer accessible; on-premises perpetual licenses keep running unsupported | Service Quality (partner claim) |
| 13 Oct 2026 | New Atlassian cloud list prices: Service Collection Standard, 100 agents, annual, $19,700 becomes $21,000 | Atlassian pricing tables |
Two buyer-side facts matter. JSM is sold inside Service Collection (JSM, Customer Service Management, Assets and Rovo), which is cloud only and cannot be bought piece by piece (Atlassian, as of 12 Oct 2026). Atlassian also stopped selling new Data Center subscriptions to new customers after 30 Mar 2026, so an on-premises Cherwell shop choosing Atlassian is moving to Cloud.
Cherwell to Jira Service Management migration: what moves, what gets rebuilt
Records move. Logic does not. Incidents, requests, problems, changes, customers, CIs and knowledge can be exported and loaded into JSM, but One-Step Actions, SLA definitions, running SLA timers and priority matrices are rebuilt. Read each column top to bottom; rows are lists, not matched pairs.
| Moves as data | Gets rebuilt in JSM | At risk of loss or distortion |
|---|---|---|
| Incidents, requests, problems and changes as work items | One-Step Actions and automation processes become automation rules | Journals: seven types collapse into one comment stream |
| Users and customers, matched by email | Specifics forms become JSM forms | Linked attachments stored as file paths |
| CIs as Assets object records | Lookup tables become object schemas | SLM History journals and running SLA timers |
| Knowledge articles as Confluence pages | Categories become request types | Owns and Owned By relationships |
| Stored attachments | Priority matrices, SLA definitions, catalog structure | People with both a user and a customer profile |
| Relationships as work item links and Assets references | Customer Workgroups become organizations (our suggestion) | CIs beyond 20 objects on one Assets field |
The first two columns follow Atlassian's guide (as of 12 Oct 2026). The guide offers three scopes (open tickets only, open plus recent history, or everything) and three treatments for history: a data warehouse, a separate JSM project that keeps the Cherwell structure, or remapping. Choose per record type before you map a field.
Running SLA timers cannot carry over: Atlassian says JSM calculates SLAs from issue history (knowledge base, updated 26 Sep 2025).
Field mapping from Cherwell to JSM
Cherwell limits come from Ivanti's help pages (versions 10.1 to 2023); JSM limits from Atlassian's support pages. All were read on 12 Oct 2026.
| Cherwell | JSM target | Cherwell-side limit | JSM-side limit |
|---|---|---|---|
| Statuses: New, Assigned, In Progress, Pending (Stop The Clock), Resolved, Closed, Reopened | Workflow statuses, each in To do, In progress or Done | Pending pauses the clock | CSV maps status only to existing workflow statuses |
| Priority: Impact x Urgency, 1 to 5 | Priorities (default Highest to Lowest) | Standard incident matrix returns 1 to 5, standard request matrix 1 to 3; matrices are customizable | Names and meanings are admin-customizable |
| Users and customers | Jira users and JSM customers; organizations group customers | Users consume a license; customers sit in Customer Workgroups; one person can hold both profiles | CSV users by email or account ID; watchers must exist; user creation blocked above a user-limited license |
| Journals (seven types) | Comments, public or internal | Docs do not label any type public or internal | CSV makes mapped comments public |
| Attachments | Work item attachments | Stored or linked; linked files need network access; export can exclude attachments | CSV needs HTTP or HTTPS URLs reachable from your site; 1 GB default, 2 GB maximum per file |
| CIs (Computer, Server, Printer and others) | Assets object types and objects | Grid export reaches only the object and its one-to-one related objects | Header row required; dates MM/dd/yyyy; users by email, not user names |
| Relationships: Owns, Owned By, Link | Parent links, work item links, Assets references | Owns and Owned By children exist only while the parent does | Parents must precede children in CSV; Assets keys regenerate on import |
| Knowledge Article | Confluence page | Body must be exported and converted (our note) | Confluence .docx import: 5 MB per document, bulk up to 30 files and 50 MB |
Journals: decide public or internal first
Cherwell's seven default incident journals are Note, Customer Request, History, Mail History, SLM History, Queue History and Remote Support History (Ivanti, as of 12 Oct 2026). Atlassian says all comments mapped through CSV become public in a JSM space. If Note journals hold technician-only troubleshooting, a plain CSV load shows them on the portal. Our recommendation, not a vendor rule: Customer Request and Mail History become public comments, Note becomes internal, and the three history types go to an archive unless reports need them. Test the internal path in a sandbox.
Priority and relationships
Map each active matrix cell to a JSM priority; a common choice, again ours, is 1 to Highest through 5 to Lowest. Link relationships become work item links, Owns relationships become comments or child work items, and CI-to-CI relationships become Assets references. Import the referenced object type first and reference by label, because Atlassian says each import generates new object keys.
Export from Cherwell, import into Jira Service Management
Cherwell has three export routes (Ivanti, as of 12 Oct 2026).
- Data Export tool. It writes a full system to a compressed .czar archive, can exclude attachment files, never contains decrypted data, and leaves out encryption keys. Ivanti's overview says single-object export writes .csv or .xml, but its steps name .czar, so test which you get.
- Grid export. CSV exports all rows; Excel exports only rows in the grid. Desktop Client grids cap at 20,000 rows, and long text is cut at 300 characters unless you clear the truncate box.
- REST API. Operations include getsearchresults, getbusinessobjectbatch, getrelatedbusinessobject, getbusinessobjectattachments and getactivities (up to 2,000 per page). Journals come through related-object calls.
On the JSM side, Atlassian names direct importers only for Asana, Trello and Bitbucket and recommends CSV "in most cases" (as of 12 Oct 2026). The CSV importer documents these rules: about 1,500 work items per file, roughly an hour for a file that size, Summary as the only required field, and request type set by ID rather than name or portal visibility can suffer.
For API loads, Jira Cloud returns HTTP 429 with a Retry-After header at its limits, and documents per-work-item write limits of 20 operations per 2 seconds and 100 per 30 seconds (Atlassian rate-limiting documentation, as of 12 Oct 2026). A work item with hundreds of journals loaded as comments can hit that ceiling.
CIs load through Assets import (CSV, JSON, Assets Discovery or REST), which needs an import structure and enabled object type mappings (Atlassian, as of 12 Oct 2026). Atlassian's guide also names a StrataCom toolkit that maps fields and handles journal entries.
Plan in phases, working back from 31 Dec 2026
There is no neutral public benchmark for duration, so this plan fixes order and exit gates, not weeks. The only fixed dates are 31 Dec 2026 and a partner-claimed 30-day cloud access window after it, which is a last resort, not a plan.
| Phase | What happens | Exit gate |
|---|---|---|
| Discover | Count records, custom fields, integrations, One-Step Actions, SLAs and attachments by type. Choose history scope. | Signed scope per record type |
| Map | Build JSM workflows, request types, priorities, schemas and Assets. Settle journal visibility. | Approved mapping sheet |
| Test migration | Load a sample, then a full copy to a sandbox. Check counts, links, attachments and comment visibility. | Reconciliation with no unexplained gaps |
| Cutover with delta sync | Freeze before 31 Dec 2026, load the final extract, then the changes since. | Go/no-go decision |
| Reconcile | Compare totals, spot-check links, confirm SLA behavior on open items. | Business sign-off |
| Hypercare | Fix mapping defects; keep a read-only Cherwell export. | Agreed close date |
Fix the cutover date first, with a freeze window before 31 Dec 2026. Place the final test migration before it, and start it only after mapping is signed. Take a complete Cherwell export early, so any gap surfaces while Cherwell is still supported. MigrateX runs migrations as a controlled change: mapped, test-migrated, cut over with delta sync, reconciled and signed off.
Cherwell to JSM failure points
- Internal notes go public. CSV comments become public (Atlassian). Set visibility per journal type first.
- Clipped text. Grid export cuts long fields at 300 characters by default (Ivanti), so descriptions and resolutions can arrive short.
- SLA clocks that never stop. Closed issues imported by CSV keep counting. Atlassian's fixes are a flag field that excludes them from SLA goals, or a bulk transition to Done, which stops the clock at the transition time.
- Linked attachments. Linked files are not stored in Cherwell (Ivanti), and Jira Cloud fetches attachments by URL, so a file-share path will not load.
- Duplicate people. One Cherwell person can have a user and a customer profile (Ivanti). Match on email, or you load two identities.
- Assets limits. Atlassian's Assets migration documentation caps 20 objects per field per work item.
- Lost elapsed SLA time. JSM shows remaining SLA time by default; Atlassian's workaround copies elapsed time into a field by automation (knowledge base, updated 9 Jul 2026).
Cherwell to JSM migration checklist
- Confirm your Cherwell edition (cloud or on-premises) and what happens to access after 31 Dec 2026.
- Count records per business object.
- Choose history scope per record type.
- List every One-Step Action and mark it rebuild, retire or replace.
- List active SLAs and their pause conditions.
- Document every priority matrix, including customized ones.
- Decide visibility for all seven journal types.
- Separate stored from linked attachments.
- Build the JSM workflow, request types and Assets schema before importing.
- Export users and customers, deduplicate by email, check license limits.
- Run a sandbox migration and reconcile counts, links, comments and attachments.
- Set the freeze window before 31 Dec 2026 and agree go/no-go criteria.
- Store a final complete Cherwell export read-only.
FAQ
Methodology
We built this page from Ivanti's versioned Cherwell help pages, Atlassian's support, developer, pricing and licensing pages, Atlassian's Cherwell guide, and partner pages for the end-of-life date, all read on 12 Oct 2026. The date rests on two independent partner sources, StrataCom and Beyond20, because the Ivanti pages we could read do not state it. Suggestions marked as ours are recommendations, not vendor rules. Cherwell help pages vary by version, so check yours.
Disclosure: MigrateX, the publisher of this article, runs ITSM data migrations, including between platforms named here. No vendor reviewed or paid for this article.