Cherwell to Freshservice migration: mapping Cherwell objects, data and workflows before the Dec 31, 2026 end of life
Short answer
Ivanti’s own end-of-life hub lists Cherwell Service Management (CSM) and Cherwell Asset Management with an end-of-life date of 12/31/2026 (checked Nov 10, 2026). If Freshservice is your destination, the move is less about tickets and more about Business Objects: Cherwell lets you model almost anything as a Major, Supporting, Lookup or Group object, while Freshservice has a fixed ITSM data model with custom fields. So the first job is a mapping: Incident and Service Request to Freshservice tickets, Problem and Change to their own Freshservice modules (Pro plan and above), Configuration Items to asset types in the CMDB, Customers to requesters, and Journals to notes. One-Step Actions and Automation Processes do not migrate; you rebuild the ones that matter in Workflow Automator. History moves through the Freshservice partner bulk API (tickets and notes only, 50 per request, 10 requests a minute) or via a migration partner, not through a self-service importer. With weeks rather than months left, our advice is: export everything you are legally or operationally required to keep now, migrate open and recent work, and archive the rest. Freshservice Pro, the tier most Cherwell ITIL shops need, is $99 / £79 per agent per month billed annually (official USD and GBP on the Freshservice pricing page, checked Nov 10, 2026).
Contents
- Who this guide is for
- The end-of-life date, and what it means in practice
- How Cherwell stores data, and why that shapes the migration
- Mapping Cherwell objects to Freshservice
- Getting data out of Cherwell
- Getting data into Freshservice
- One-Step Actions, Automation Processes and approvals: what you rebuild
- Which Freshservice plan, and what it costs
- A plan for the weeks left
- Best for, and wrong choice when
- Frequently asked questions
Who this guide is for
This guide is for IT service managers and Cherwell administrators who have decided, or are close to deciding, that Freshservice will replace Cherwell Service Management. If you are still choosing between Ivanti Neurons for ITSM, ServiceNow, Freshservice and Jira Service Management, start with our Cherwell replacement guide and come back here once Freshservice is on the shortlist. If Jira Service Management is your target instead, read the companion Cherwell to Jira Service Management migration guide.
We use only vendor sources for facts: 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 for how Cherwell stores and exposes data, and Freshworks’ own pages for Freshservice: the Freshservice pricing page, the Freshservice bulk migration API guide for data migration partners and the Freshservice “Importing Assets” article. Everything was checked on Nov 10, 2026. Opinions about sequencing and scope are ours, from service desk migrations, and are labelled as such.
What we will not do
We do not quote Ivanti prices for extending Cherwell or moving to Ivanti Neurons; Ivanti sells by quote. We do not claim a native Cherwell importer in Freshservice, because we did not find one in Freshworks’ documentation. And we do not promise that a migration will finish by a given date. That depends on your data volume, your customisations and how quickly decisions are made.
The end-of-life date, and what it means in practice
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 first announced the CSM date in its end-of-life announcement of October 31, 2023 (see Ivanti’s Cherwell end-of-life announcement; the community page needs JavaScript and may ask you to sign in). The same hub lists other legacy products with the same date, so do not assume a Cherwell add-on or integration you rely on outlives the core product.
Ivanti’s CSM end-of-life FAQ is behind a sign-in. As republished by Ivanti partners, it says on-premises customers with perpetual licences can keep running the product after the date but without Ivanti support, and that cloud tenants are discontinued and no longer accessible 30 days after the end-of-life date. Confirm both points for your contract with your Ivanti account team. The practical reading is simple:
| Your Cherwell setup | What end of life means | What to do now |
|---|---|---|
| Cherwell cloud (Ivanti-hosted) | Per the FAQ wording above, the tenant goes away about 30 days after Dec 31, 2026, and the data with it | Take a full export of data and schema now. Do not wait until cutover week |
| Cherwell on-premises, perpetual licence | The software keeps running, unsupported and unpatched | You have more room, but every month on an unsupported system is risk on a database full of personal data. Plan a read-only archive and a decommission date |
| Cherwell on-premises, subscription | Depends on your subscription term | Check your contract end date with Ivanti; plan as if support stops on Dec 31, 2026 |
On Nov 10, 2026 there are about seven weeks to the date. That is enough time to stand up Freshservice and move live work if decisions are quick. It is rarely enough to migrate every historical record, every custom object and every automation. Plan for that honestly: decide now what must be in Freshservice on day one, what can follow in January from an export, and what goes to an archive only.
How Cherwell stores data, and why that shapes the migration
Cherwell is built on Business Objects. Ivanti’s documentation describes four categories. Major objects stand alone and represent a major part of the business, with examples such as Incident, Problem, Change, Knowledge Article, Customer, Configuration Item and Service. Supporting objects exist only to complement a Major object, such as Task, Journal and Approval. Lookup objects supply constrained values to fields, such as the Incident Cause list. Group objects share common fields under a Group Leader; Ivanti’s example is the Configuration Item group with members Computer, Printer and Telephony Equipment.
Objects connect through Relationships. A Major object can own a child (Incident owns Journals, Change Request owns Tasks), which exists only as long as the parent does, or link to another object that can exist independently (Customer links SLA, Problem links Knowledge Articles). Behaviour lives in One-Step Actions, Automation Processes and approval configuration, attached to the objects.
Freshservice works the other way round. It has a fixed set of modules (tickets, which cover incidents and service requests; problems; changes; releases; assets and the CMDB; solutions for knowledge) and lets you add custom fields, asset types and workflows on top. So the migration question is not “how do I copy Cherwell tables”, it is “which Freshservice record does each Cherwell object become, and which Cherwell objects have no home at all.” Every Cherwell shop has a few custom Major objects built for one team; those are the ones that need a decision, not a script.
Mapping Cherwell objects to Freshservice
This is the mapping we start from. Adjust it to your own Blueprint schema export (next section), which will show the custom objects and fields your instance actually has.
| Cherwell object (category) | Freshservice destination | Notes |
|---|---|---|
| Incident (Major) | Ticket of type Incident | Cherwell often stores incidents and service requests in one Incident object with a type field. Split on that field during import |
| Service Request (often Incident with a type) | Ticket of type Service Request, linked to a service catalogue item | The service catalogue is on Growth and above. Historical requests usually land as plain tickets; only new requests use catalogue items |
| Problem (Major) | Problem | Problem management is on Pro and Enterprise. On Starter or Growth there is no home for problem records |
| Change Request (Major) | Change | Change management, CAB and change calendar are on Pro and Enterprise. Rebuild change types and risk questions rather than copying them |
| Knowledge Article (Major) | Solution article | Recreate categories first; check article HTML and embedded images after import |
| Customer (Major) | Requester | Load from your directory (Entra ID, Okta, Google) rather than from Cherwell where possible, then match by email |
| Configuration Item group (Group: Computer, Printer and so on) | Asset types in the CMDB, one per Group member | Freshservice imports one asset type per CSV. Create custom asset types and fields first |
| Service (Major) | Service catalogue items and/or a business service asset type | Decide whether “Service” means something users request or something you monitor; they map differently |
| Journal (Supporting, owned by Incident and others) | Ticket notes (private) or replies (public) | Journals carry history, emails and notes; map journal types to private vs public notes deliberately |
| Task (Supporting) | Ticket, problem or change tasks | Only migrate open tasks on open records; closed tasks rarely add value |
| Approval (Supporting) | Approval history as a note; live approvals rebuilt in workflows | Pending approvals should be finished in Cherwell or re-requested in Freshservice |
| Lookup objects (Category, Cause, Priority, Team lists) | Dropdown field choices, categories, groups | Clean these up first. Cherwell lookups often contain years of retired values |
| SLA (linked to Customer) | SLA policies | Rebuild in Freshservice; multiple SLA policies are on Growth and above |
| Custom Major objects | Custom ticket type, custom module via app, or archive | Decide one by one. If nobody uses it weekly, archive it |
Two mapping rules save weeks. First, keep the Cherwell record ID in a custom field on every migrated record, so links, emails and audit questions can be traced back. Second, map status and priority values explicitly, with a written table signed off by the service owner. Cherwell lifecycles are often customised; Freshservice statuses are simpler. Collapsing six Cherwell states into four Freshservice statuses is fine as long as someone has decided it.
Getting data out of Cherwell
There are two things to export, and you need both: the schema (what your Cherwell instance looks like) and the data (the records).
The schema: Blueprint Schema export
Ivanti documents a Blueprint Schema export in CSM Administrator: open a Blueprint, choose Tools, then Export Schema, select Major, Supporting and Lookup objects, and choose which metadata to include: Business Object properties, lifecycle, fields, relationships, One-Step Actions, approvals and Automation Processes. The output is a single .html, .rtf, .txt or .xml document. This is the most useful file in the project. It tells you which custom objects and fields exist, which lifecycles you have bent, and which automations you will need to rebuild. Export it on day one and keep a copy with the archive.
The data: REST API and saved searches
For records, the Cherwell REST API documentation supports create, read, update and delete on Business Objects, search through saved or ad-hoc queries, and (since CSM 9.7.0) exporting all rows from the results of a saved search. Version 10.2.0 added a v2 stored searches operation aimed at third-party reporting integrations. In practice, a migration script pages through each object with saved searches, pulls related Journals and attachments per record, and writes a staging file per object. Many teams also take a database backup for the archive; that is a copy for legal retention, not something you import.
Export checklist for Cherwell
- Blueprint Schema export with all object types and all metadata options
- Record counts per Major object, by status and by year, so you can reconcile later
- Open records of every type, with Journals, Tasks, Approvals and attachments
- Closed records for the retention period you have agreed (often 12 to 24 months for the live system)
- Knowledge Articles with categories and images
- Configuration Items per Group member, with relationships
- Lookup tables, SLA definitions, Teams and their members
- A full archive copy (database backup or bulk export) for everything you are not migrating
If you are on Cherwell cloud
Export now, and test that you can read what you exported. Leaving the export until the final weeks of December removes your margin for a failed or incomplete pull.
Getting data into Freshservice
Freshservice does not offer a self-service “import from Cherwell” button. There are three routes, and most projects use all three.
| Route | What it covers | Limits to plan for |
|---|---|---|
| Partner bulk migration API | Tickets and notes with attachments, created in bulk | For Freshworks data migration partners; needs a migration token. 50 tickets or notes per request, 10 requests per minute per account, 40 MB of attachments per entity. Attachments must be at public URLs. Workflows, business rules, Slack and Teams are not muted during the load |
| Standard Freshservice REST API | Everything else: requesters, agents, groups, problems, changes, solution articles | Normal API rate limits apply; create dependencies (workspaces, users) before the records that reference them |
| CSV asset import | CMDB assets, one asset type per file | Create custom asset types and fields first. Display Name is the only field required by default. Hardware can match on serial number, display name or asset tag |
Two details from Freshworks’ partner guide are worth taking seriously. The documented cap of 50 records per request and 10 requests per minute means at most 500 tickets or notes a minute, before retries. A desk with 200,000 tickets and three notes each is 800,000 records, which is more than a day of continuous loading at that cap. That is fine if you plan for it and a problem if you discover it in cutover week. Second, because workflows are not muted, switch off Workflow Automator rules, business rules and Slack or Teams notifications in the target account before loading, or automations written for live work will fire on tickets from 2023. Freshworks says only some notification emails (ticket assigned, CC and associations) are suppressed during bulk migration.
For assets, Freshworks’ Freshservice “Importing Assets” article explains the mechanics: split the CSV by asset type, use requester email in the Used By field and agent email in Managed By, match the date format, and watch for “serial number must be unique” errors caused by assets sitting in the inventory trash. Map each Cherwell Configuration Item Group member to one Freshservice asset type, and load relationships after the assets exist.
One-Step Actions, Automation Processes and approvals: what you rebuild
Nothing in Cherwell’s automation layer migrates as code. You rebuild behaviour, and that is a chance to drop the automations nobody remembers adding. Use the Blueprint Schema export to list every One-Step Action and Automation Process, then sort them.
| Cherwell behaviour | Freshservice equivalent | Our advice |
|---|---|---|
| One-Step Actions triggered by a button (assign to me, resolve with template) | Canned responses, scenario automations, ticket templates | Keep the five or ten agents use daily; drop the rest |
| One-Step Actions triggered on save or field change | Workflow Automator rules (event, condition, action) | Rebuild in Workflow Automator, test on a sandbox if you have Enterprise |
| Automation Processes (scheduled or event-driven) | Workflow Automator, supervisor-style time triggers, or an orchestration app | List triggers and outcomes first; many duplicate SLA escalations Freshservice already does |
| Approvals on Change and Request | Change approvals (Pro+), service request approvals | Rebuild approval chains by service, not by copying Cherwell configuration |
| Email monitor and auto-replies | Email channel, notifications | Point the mailbox at Freshservice only at cutover |
| Integrations (directory, monitoring, discovery) | Native apps, connector apps, REST API | Re-plan each one; connector app tasks on Pro and Enterprise include a one-time 500-task credit, then $80 / £65 per 5,000 tasks |
If your Cherwell instance has been heavily customised with mApps or custom Major objects, budget most of the effort here, not in data loading. In our experience the data move is mechanical once the mapping is agreed. The rebuild of behaviour is where requirements surface late.
Which Freshservice plan, and what it costs
Cherwell shops that run incident, request, problem and change usually need Freshservice Pro, because problem, change, release and major incident management start there. Growth covers incident, service catalogue, SLAs and assets. Prices below are the official USD and GBP list prices on the Freshservice pricing page, checked on Nov 10, 2026.
| Plan | Per agent / month, billed annually | Per agent / month, billed monthly | What matters for Cherwell leavers |
|---|---|---|---|
| Starter | $19 / £15 | $29 / £25 | Incident and knowledge only. Rarely enough for a Cherwell estate |
| Growth | $49 / £40 | $59 / £45 | Adds service catalogue, SLA management, on-call and cloud management. Fine if you never used Problem or Change in Cherwell |
| Pro | $99 / £79 | $119 / £95 | Adds problem, change, major incident, release, workload management and employee journeys. The usual target |
| Enterprise | Contact sales | Contact sales | Adds sandbox, audit logs, Freddy AI Agent (Classic) and Freddy AI Insights |
Freddy AI Copilot is an add-on at $29 / £23 per agent per month billed annually ($35 / £28 monthly). Asset management is licensed in Asset Units, which Freshworks says can be bought in packs of 500; the pricing page does not list a unit price, so ask for a quote if your CMDB is large. Freshworks offers a 14-day free trial. As a worked example from the list prices only: 20 agents on Pro billed annually is $1,980 / £1,580 per month, or $23,760 / £18,960 a year, before tax, add-ons and Asset Units.
For the full plan comparison see our Freshservice pricing guide.
A plan for the weeks left
This is the sequence we would run from mid-November for a mid-sized Cherwell estate moving to Freshservice. It assumes a decision has been made and someone can sign off mappings within a day or two.
| Window | Work | Done when |
|---|---|---|
| Week 1 | Full export: Blueprint Schema, record counts, all data for the retention period, archive copy. Freshservice account, SSO and requester sync | You can open the exports and the counts reconcile |
| Week 2 | Mapping workshop: object map, status and priority tables, custom objects decision, asset types. Configure groups, categories, SLAs | Mapping signed off by the service owner |
| Week 3 | Trial load of a sample (a few hundred records of each type with notes and attachments). Rebuild top workflows and catalogue items | Agents can work a migrated ticket end to end |
| Week 4 | Full load of closed history in date windows; assets by type; knowledge | Counts match the export within agreed tolerance |
| Week 5 | Delta load of records changed since the full load; agent training; email routing test | Training done, test emails land in Freshservice |
| Week 6 | Cutover: switch mailboxes and portal links, set Cherwell read-only, final delta | New work only in Freshservice |
| Week 7 and after | Hypercare; decommission plan for Cherwell; archive access for audit | Cherwell cloud data safely archived before the tenant closes |
If that does not fit, cut scope rather than quality: move open work and the last 12 months, archive the rest, and leave custom objects for a second phase. A clean desk with less history beats a full history nobody trusts.
Best for, and wrong choice when
Freshservice is the right destination when
Your Cherwell use is mainstream ITSM (incident, request, problem, change, knowledge, CMDB), you want a SaaS product with published per-agent prices, and you are willing to simplify customisations rather than replicate them.
Freshservice is the wrong destination when
Your Cherwell instance is effectively a custom application platform, with many custom Major objects running non-IT processes, or you need on-premises hosting. Ivanti Neurons for ITSM or ServiceNow fit that profile better; see our Ivanti Neurons vs Freshservice vs ServiceNow comparison.
Consider Jira Service Management instead when
Your engineering teams already live in Jira and you want incidents and changes linked to their work. Assets in JSM is a strong CMDB target for Cherwell Configuration Items. See our Cherwell to JSM migration guide.
Frequently asked questions
When does Cherwell reach end of life?
Ivanti’s Product End of Life hub lists Cherwell Service Management (CSM) and Cherwell Asset Management (CAM) with an end-of-life date of 12/31/2026 (checked Nov 10, 2026). Ivanti announced the CSM date on October 31, 2023.
Is there a native Cherwell importer in Freshservice?
We did not find one in Freshworks’ documentation. Tickets and notes are loaded through Freshservice’s bulk migration API for data migration partners, other records through the standard REST API, and assets through CSV import per asset type.
How do Cherwell Business Objects map to Freshservice?
Incidents and service requests become tickets, Problems and Change Requests become problems and changes (Pro plan and above), Knowledge Articles become solution articles, Customers become requesters, Configuration Item group members become asset types, and Journals become notes. Custom Major objects need a case-by-case decision.
Do One-Step Actions migrate?
No. One-Step Actions and Automation Processes are Cherwell configuration. Export them with the Blueprint Schema, decide which still matter, and rebuild those in Freshservice Workflow Automator, scenario automations or templates.
Which Freshservice plan do Cherwell users need?
Usually Pro, at $99 / £79 per agent per month billed annually (official prices checked Nov 10, 2026), because problem, change, release and major incident management start on Pro. Growth ($49 / £40) is enough only if you used incident, request and assets without problem and change.
How fast can the bulk API load tickets?
Freshworks documents up to 50 tickets or notes per request and 10 requests per minute per account, so at most 500 records a minute before retries. Plan large histories in date windows over several days.
What happens to Cherwell cloud data after Dec 31, 2026?
Ivanti’s sign-in-gated FAQ, as republished by partners, says cloud tenants are discontinued and inaccessible 30 days after the end-of-life date. Confirm with Ivanti and take a full export well before then.
Should we migrate all Cherwell history?
Not necessarily. With limited time, migrate open work and recent history that agents actually search, and keep the rest in a read-only archive with documented access for audit requests.