Cherwell End of Life December 2026: Data Migration Guide

Cherwell End of Life December 2026: Data Migration Guide

Ivanti ends Cherwell Service Management (CSM) and Cherwell Asset Management (CAM) on December 31, 2026. After that date, there are no updates and no support (hub.ivanti.com). Ivanti announced the end of life on October 31, 2023. Cloud-hosted tenants may face a harder cutoff. Partner StrataCom's summary of Ivanti's FAQ says cloud tenants become inaccessible 30 days after the end-of-life date (stratacominc.com). That is a partner's reading, not an Ivanti statement, so confirm your tenant's dates and data-export options with Ivanti in writing.

Whether you move to Ivanti Neurons for ITSM, ServiceNow, Jira Service Management, Freshservice, or another platform, every path requires a data migration — and the data extraction from Cherwell is the part most teams underestimate. This guide covers what data needs to move, how to get it out of Cherwell, concrete field mapping examples, an extraction method decision matrix, and how to plan backward from the December 31 deadline.

What Does Cherwell End of Life Actually Mean?

Cherwell end of life means Ivanti stops all product updates, security patches, and official support for Cherwell Service Management on December 31, 2026. The impact depends on your deployment model:

• Cloud-hosted customers lose access entirely. StrataCom's summary of Ivanti's FAQ says cloud tenants will be "discontinued and will no longer be accessible 30 days following the end-of-life date" (stratacominc.com). Another partner, Service Quality, says subscription customers have 30 days after the upgrade grace period ends to request their data as a standard database export (servicequality.com.au). Request this explicitly from Ivanti — do not assume it will be provided automatically.
• On-premises customers with perpetual licenses can keep running Cherwell after December 31. But without security patches, bug fixes, or vendor support, every month on an unsupported system widens your compliance and security exposure. Auditors and infosec teams will flag this.

Both Cherwell Service Management and Cherwell Asset Management share the same December 31, 2026 end-of-life date.

What Cherwell Data Needs to Move

A Cherwell migration is not a ticket dump. Cherwell's data model is built around Business Objects — configurable containers (Incident, Problem, Change, Config Item, etc.) with fields, relationships, and lifecycle states. Most Cherwell environments have been heavily customized with additional Business Objects, fields, and One-Step Actions beyond the out-of-the-box configuration.

Category	Cherwell Construct	What It Contains
Tickets	Incident Business Object	Incidents and service requests (Cherwell stores both in the same object), with journals, approvals, and task records
Change & Problem	Change and Problem Business Objects	Change requests, problems, and their linked records
CMDB	Config Item Group Business Object	Configuration items, CI types, CI-to-CI relationships, and CI-to-incident links
Assets	Asset-related Business Objects / CAM	Hardware, software, license entitlements
Knowledge base	Knowledge Article Business Object	Articles, categories, approval states
People & teams	Customer, Team, User Business Objects	End users, technicians, groups, roles
Attachments	Linked to parent Business Objects	Files attached to incidents, changes, CIs — stored in the database or file system

Critical detail — incident/service request co-mingling: Cherwell stores incidents and service requests in the same Incident Business Object, differentiated by a type field (typically a lookup value such as "Incident" or "Service Request"). Most target platforms — ServiceNow, Jira Service Management, Freshservice — treat these as separate record types in separate tables or projects. Your field mapping must account for this split at the extraction stage, not during load.

Journals and audit history deserve special attention. Cherwell stores the chronological history of a ticket in Journal objects — technician notes, customer emails, status changes, and automated system updates. Journals must be extracted as related child objects and mapped to the target platform's equivalent structure.

Users and teams must be migrated and mapped first, because every ticket, journal, and asset relies on user references for accurate attribution. If users load after tickets, author fields break and cannot be retroactively corrected without re-loading affected records.

Knowledge articles with inline images require parsing, downloading, and re-hosting those images in the target platform to prevent broken image links post-migration.

What Migrates vs. What Gets Rebuilt

Not everything in Cherwell can be lifted and dropped into a new platform. Understanding this split early prevents scope creep and missed deadlines.

Data that migrates (with transformation):

• Incident, problem, change, and request records with their journals and timestamps
• CMDB configuration items and their relationships
• Knowledge articles
• Customer and technician records
• Attachments

Configuration that must be rebuilt on the target platform:

• Forms and layouts. Cherwell forms are visual layers on top of Business Objects. Every target platform has its own form designer. Atlassian's published Cherwell-to-JSM guidance maps Cherwell specifics forms to Jira Service Management forms (success.atlassian.com).
• One-Step Actions and automations. These are Cherwell-specific workflow constructs stored in a proprietary format with no portable equivalent. Expect to reimplement the equivalent logic in the target platform's automation engine (ServiceNow Flow Designer, JSM automation rules, Neurons workflow designer).
• Dashboards and reports. Saved searches, dashboard widgets, and report definitions are platform-specific. Plan an inventory and prioritized rebuild.
• SLA policies and escalation rules. The logic translates conceptually, but the implementation is target-specific.
• Blueprints (mApps). Cherwell Blueprints package configuration changes in a CSM-proprietary format. They do not transfer outside CSM.

This distinction matters for planning. The data migration — extracting records, transforming fields, loading into the target — is a bounded, scriptable project. Rebuilding automations and workflows is a separate effort on your own timeline, and it requires deep knowledge of the target platform.

How to Extract Data from Cherwell

Extraction Method Decision Matrix

The right extraction approach depends on your deployment model, data volume, and relationship complexity. Use this matrix to select your primary method:

Method	Deployment	Record Volume	Relationship Fidelity	Throughput	Recommended When
REST API	Cloud or on-prem	Any	High	Limited by server throttling	Standard migrations; primary method for all relational data
Direct SQL Server	On-premises only	Any	Highest	Not API-limited	On-prem with DBA access; best for large CMDB and attachment extraction
Full database export	Cloud (on request to Ivanti)	Full environment	Depends on the format Ivanti delivers	Single export	Cloud customers who need a full copy before EOL
CSV/Excel grid export	Cloud or on-prem	<5,000 records	Low (flat)	Manual	Small reference data; last resort only

Preferred extraction order: REST API → Direct SQL / database export → CSV. The REST API preserves relationships and supports automation. Direct SQL access is the highest-fidelity fallback for on-premises environments. CSV is the least preferred option because it flattens relationships and loses type information. For large Cherwell migrations, combine API extraction for relational data with database-level exports for attachments and audit trails.

Cherwell REST API

The Cherwell REST API provides programmatic access to Business Objects, including the ability to query, retrieve, and export records with their fields and relationships.

Key endpoints (help.ivanti.com):

• /api/V1/getsearchresults — run searches and retrieve Business Object records with pagination
• /api/V1/getbusinessobjectattachments — retrieve attachments linked to a specific record
• /api/V1/getrelatedbusinessobject — traverse relationships between Business Objects
• /api/V1/getbusinessobjectsummary and /api/V1/getbusinessobjectschema — look up a Business Object's ID, then its fields, before querying custom objects

Rate limits: Ivanti's API reference does not publish a fixed rate limit for the CSM REST API, so do not plan around a number. Build exponential backoff and retry logic into any extraction script, log every failed call, and reconcile record counts after each run. A script that does not retry throttled or timed-out requests will silently drop records on high-volume extractions.

Pagination: Use the pageNumber and pageSize parameters on /api/V1/getsearchresults (help.ivanti.com). Keep page sizes moderate and test them against your instance, because large pages increase timeout risk.

Direct SQL Server Access

For on-premises installations, direct access to the underlying SQL Server database is the highest-fidelity extraction method. Business Object data is stored in tables prefixed with the Business Object's internal name. Relationships are stored in linking tables. This approach bypasses API rate limits entirely.

For Ivanti-hosted (cloud) customers, ask Ivanti explicitly for a full database export of your tenant — not a CSV export. Confirm in writing what format Ivanti will deliver and whether it includes custom Business Objects, relationships, and database-stored attachments. Do this now, not in December.

Handling Attachments

Cherwell attachments are not always simple file paths or URLs. An attachment can be imported into the database, linked to an external file, or stored as a URL attachment (help.ivanti.com). Via the API, you list a record's attachments and then download each file with a separate call. Specific failure modes:

• Large attachments can hit timeout limits during REST API extraction — log and retry them separately
• Validate every downloaded file; a bad download produces a file that appears to exist but cannot be opened
• After extraction, attachments must be staged and uploaded to the target, with the target-generated attachment ID mapped back to the parent record

For cloud environments, a full database export that includes imported attachments can be more reliable than API-based attachment extraction for large attachment volumes. Linked files stored outside the database need their own copy step.

Concrete Field Mapping Examples

Field mapping is where migrations fail silently. The following examples cover the highest-risk mappings in a Cherwell-to-target migration.

Cherwell Incident → ServiceNow Incident (sc_task / incident table)

Cherwell Field	Cherwell Type	ServiceNow Field	ServiceNow Type	Transformation Required
IncidentID	AutoNumber	number	String	Direct map; prefix with "CHR-" to preserve traceability
RecID	GUID	correlation_id (staging)	String	Used as staging FK only; not stored in final record
Status (lookup)	Lookup table	state (integer)	Integer	See status mapping below
Priority	Lookup (1–4)	priority (integer)	Integer (1–4)	Direct map if scales match; validate
Owned By	RecID → User	assigned_to	Reference (sys_user)	Requires user migration to complete first
Customer RecID	RecID → Customer	caller_id	Reference (sys_user)	Same dependency
Description	Rich text	description	String (HTML or plain)	Strip HTML or convert to ServiceNow format
Journal (child objects)	Related Journal BO	work_notes / comments	Journal field	Split by journal type (technician vs. customer-facing)
Type = "Incident"	Lookup value	Incident table	—	Route to incident table
Type = "Service Request"	Lookup value	sc_task or ritm	—	Route to request/catalog task table
CreatedDateTime	DateTime	sys_created_on	DateTime	Normalize to UTC; confirm the source time zone first
ClosedDateTime	DateTime	closed_at	DateTime	Same UTC normalization

Cherwell Incident Status → ServiceNow State integer mapping (common defaults):

Cherwell Status	ServiceNow State Value
New	1
In Progress	2
On Hold	3
Resolved	6
Closed	7
Cancelled	8

Your Cherwell environment may use custom status values. Run a SELECT DISTINCT Status FROM Incident (or API equivalent) before finalizing this mapping.

Cherwell Incident → Jira Service Management (JSM)

Cherwell Field	JSM Field	Transformation
Type = "Incident"	Issue type: Incident	Route to Incident project
Type = "Service Request"	Issue type: Service Request	Route to separate JSM project or request type
Status	Status (JSM workflow state)	Map Cherwell statuses to JSM workflow transitions
Owned By	Assignee	Requires Atlassian account match by email
Journal (technician)	Internal comment	JSM internal comment flag = true
Journal (customer-facing)	Public reply	JSM internal comment flag = false
Priority	Priority	Direct map if 1–4 scale; JSM uses Highest/High/Medium/Low/Lowest

Cherwell CI → ServiceNow CMDB

Cherwell Construct	ServiceNow Equivalent	Notes
Config Item Group (root)	cmdb_ci (base class)	Root CI table
Specific CI type (e.g., Server)	cmdb_ci_server	ServiceNow uses class hierarchy; map CI types to appropriate CMDB class
CI-to-CI relationship	cmdb_rel_ci	Relationship type and direction must be mapped; ServiceNow has predefined rel types
CI-to-Incident link	task_ci	Join table; requires both CI and incident records to exist first
RecID	correlation_id	Use as staging reference; ServiceNow generates its own sys_id

Cherwell CI → JSM Assets

Cherwell Construct	JSM Assets Equivalent	Notes
Config Item Group	Object schema	Define one schema per major CI category
Specific CI type	Object type within schema	Configurable; must be defined before loading records
CI field	Object attribute	Create custom attributes to match Cherwell field set
CI-to-CI relationship	Object reference attribute	Directional references; configure reference direction during schema setup

How Long Does a Cherwell Data Migration Take?

Two separate clocks run during any Cherwell exit, and conflating them causes planning failures.

Clock 1: The data migration. This covers extraction from Cherwell, transformation and field mapping, loading into the target, validation, and a delta sync for records that changed during the migration window.

Typical durations for the data migration ClonePartner performs:

Environment Size	Estimated Migration Duration
Small (under 10,000 records)	Under 24 hours
Most environments	1–5 business days, depending on data volume, complexity, and API rate limits
Very large (several hundred thousand records, or 5,000+ documents)	Custom engagement; timeline given after scoping

The primary constraint on duration is not record volume alone — it is API rate limits on both the Cherwell side (during extraction) and the target side (during load), combined with CMDB relationship complexity. A 50,000-record environment with a heavily customized CMDB and 200 GB of attachments takes longer than a 200,000-record environment with a simple CI structure and minimal attachments.

Clock 2: The replatform/rebuild project. This is the customer's own effort: selecting a target platform, configuring it, rebuilding automations and workflows, training staff, testing, and going live. ClonePartner does not perform this work, and the figures above do not cover it. It runs on a separate track from the data migration. Start platform scoping now, so the target environment is ready to receive data before the migration window opens.

Cherwell CMDB Migration: The Hardest Part

The CMDB is typically the most complex piece of a Cherwell migration. Cherwell's CMDB uses a Group Business Object model where a Group Leader (Configuration Item) sits at the root, and specific CI types inherit from it. CI-to-CI relationships, CI-to-incident links, and CI-to-change associations all need to survive the migration.

Cherwell uses RecIDs (Record IDs) — GUIDs — as unique identifiers to link objects. An Incident record contains the RecID of the assigned technician, the RecID of the affected CI, and the RecIDs of its child Journals. These Cherwell RecIDs do not exist in the target platform. The migration process must maintain a staging mapping table that maps each legacy Cherwell RecID to the newly generated ID in the target system (e.g., a ServiceNow SysID or JSM issue key). If this mapping table is incomplete or inaccurate, tickets get assigned to the wrong users or CIs become orphaned with no way to retroactively correct the linkage.

Common CMDB failure modes and their causes:

Failure Mode	Root Cause	Prevention
Broken CI-to-incident links	Incidents loaded before CIs exist in target	Enforce load order: CIs → people → tickets → journals
Orphaned CI relationships	Mapping table incomplete for one CI type	Validate 100% RecID coverage before beginning ticket load
CI type flattening	Target has fewer CI classes than Cherwell	Build CI type mapping before migration; merge or split as needed
Wrong relationship direction	Cherwell parent→child not preserved	Explicitly map relationship direction during CI-to-CI extraction
Duplicate CIs	Same physical asset in multiple CI types	Deduplication pass before load; use serial number or hostname as dedup key

For CMDB migrations, extract the full CI tree with relationships via the API, build and validate the RecID mapping table in a staging environment, and load in dependency order: CI types → CI records → CI-to-CI relationships → CI-to-ticket links.

Where Cherwell Customers Are Migrating

Every Cherwell exit is a migration — including the move to Ivanti Neurons for ITSM, because Ivanti describes that path as a clean install, not a lift-and-shift of your existing CSM environment.

Ivanti Neurons for ITSM

Ivanti Neurons for ITSM is Ivanti's designated successor to Cherwell, formerly called Ivanti Service Manager. It is the path of least commercial friction: your vendor relationship carries over. Neurons is available as a cloud service and on-premises.

It is a separate product with a different data model. Ivanti says a clean install of Neurons keeps many core CSM tools, including stored expressions, values and prompts, and incoming webhooks (ivanti.com). Plan to rebuild or reconfigure forms, automations, dashboards, and CMDB structure in the new environment. A clean install starts without your Cherwell records, so historical data still has to be migrated.

ServiceNow

ServiceNow is the enterprise standard for organizations that want deep workflow automation across IT and business functions. The trade-off is implementation effort and cost, and the data model differences (ServiceNow's table-inheritance CMDB vs. Cherwell's Group Business Object model) require careful CI type mapping.

Jira Service Management

Jira Service Management (JSM) suits teams that value developer integration, Confluence knowledge base alignment, and lower total cost of ownership. Atlassian publishes specific guidance for Cherwell-to-JSM transformations, and our Jira Service Management migration checklist covers the API constraints and field mapping requirements you'll face on the target side. Atlassian's guidance maps Cherwell lookup tables to JSM Assets object schemas (success.atlassian.com).

Other Platforms

Other common targets include HaloITSM, EasyVista, InvGate Service Management, Freshservice, and BMC Helix. The choice depends on ITSM maturity, budget, deployment requirements, and how much of Cherwell's customization you want to replicate versus rethink in the target platform's native paradigm.

How to Plan Backward from December 31, 2026

If you haven't started scoping the data migration, start now. The platform rebuild runs on one track; the data extraction runs on another. Both must converge before your cutover date.

1. Inventory your Cherwell data. Run a schema export from CSM Administrator (Blueprint menu → Export Business Object schema) for each major Business Object. Count records per object using the Cherwell grid or a direct SQL SELECT COUNT(*) query. Identify custom Business Objects unique to your environment. Document the total attachment volume.
2. Decide what to migrate vs. archive. Not all historical data needs to land in your new platform. A common approach: migrate the last 12–24 months of operational records plus all reference data (CMDB, people, groups, knowledge), and archive older records in a read-only format for compliance. Define this boundary before the migration starts — changing it mid-project resets the extraction scope.
3. Secure your database backup. If you're cloud-hosted, ask Ivanti in writing for a full database export of your tenant now, and confirm its format. Do not wait until December. If you're on-premises, take a clean backup of your SQL Server database and store it off the Cherwell server.
4. Build your field mapping document. Map Cherwell Business Object fields to target platform fields for each record type. Use the mapping tables in this guide as a starting point. Flag fields that require transformation (status integer mapping, the incident/SR split, datetime UTC normalization, rich text stripping).
5. Run a sample migration. Load a representative subset — 500–1,000 records per record type, including edge cases — into a sandbox instance of the target platform. Validate field mapping, verify that relationships survived, check attachment integrity, and confirm timestamp accuracy.
6. Execute the full migration and delta sync. Run the full historical load during the working days before go-live, while your agents keep working in Cherwell. Go live on a Monday morning: freeze Cherwell before the working day starts, run a final delta of changed records only (about 30 minutes), and have agents log in to the new platform that morning.

Cloud customers: Partners describe a 30-day post-EOL window for tenant access, but that is their reading, not an Ivanti statement. Treat it as an emergency fallback, not a schedule. Extract everything before December 31.

Validation: How to Know the Migration Worked

A Cherwell migration is only done when the data in the target platform has been verified against the source. Use these validation checks in sequence:

• Record-count parity. Total records per Business Object in Cherwell must match the target, accounting for deliberate exclusions. Discrepancies of even 1% in a 100,000-record environment mean 1,000 missing records.
• Field-level spot checks. Pull 50–100 sample records from both systems and compare field by field. Priority areas: rich-text journal entries (HTML encoding issues), timestamps (UTC normalization errors), and status values (integer mapping errors are common).
• Relationship integrity checks. Verify CI-to-incident links, parent-child CI relationships, and ticket-to-attachment associations using a sample of 100+ records with known relationships. Check both directions: does the CI list its linked incidents? Does the incident reference its CI?
• Attachment verification. Confirm that attachments are accessible and openable on the target, not just that a reference record exists. File corruption during extraction produces records that appear attached but cannot be opened.
• Delta sync validation. After the delta sync, confirm that records created or updated in Cherwell during the migration window appear correctly in the target.

Security and Compliance During the Move

Historical ITSM data contains sensitive employee information, security incident details, and proprietary infrastructure maps. The migration must handle this data under strict controls.

ClonePartner is SOC 2 Type II and ISO 27001 compliant (independently audited). We maintain GDPR, CCPA, and HIPAA safeguards, and we execute a BAA before processing any PHI.

All data is encrypted using AES-256 at rest and TLS 1.2+ in transit. We execute NDAs and DPAs on request. A dedicated migration engineer owns each project from scoping to final cutover. Our staging databases auto-purge no later than 30 days after the project closes.

What If You Can't Finish by December 31?

On-premises customers with perpetual licenses have a fallback: keep Cherwell running in a read-only state while the migration completes. The application continues to work after EOL, but without vendor support or security patches. If you take this route, isolate the server from internet-facing traffic, restrict access to named users only, and set a firm decommission date. This is a risk-acceptance decision, not a safe default.

Cloud customers do not have this option. Once the tenant shuts down, your only copy of the data is the export you took or requested from Ivanti. If you did not request it in time, the 30-day window that partners describe may be your only remaining recourse — and Ivanti has not published a guarantee that it will fulfill late requests.

For anyone pushing against the deadline: the data migration itself — extracting from Cherwell and loading into the target — is the fastest piece to execute once scoping is complete. It is not the bottleneck. The bottleneck is typically late decisions about what to migrate, an unready target environment, or missing database credentials. Address those now.

Getting Started

A Cherwell data migration is a bounded, well-understood project. The technical complexity is concentrated in four areas: the incident/service request type split, RecID mapping to target IDs, CMDB load ordering, and attachment extraction at scale. Everything else is field mapping and validation.

ClonePartner is an engineer-led service that turns complex data migrations into predictable, fixed-price engagements. We've completed 1,500+ successful migrations and built 500+ integrations, including ITSM platform moves with complex CMDB hierarchies. Each project gets a dedicated migration engineer — not a ticket queue — with one fixed price starting at $500, no hourly billing, no per-record fees, and no change orders.

For more on the broader approach to help desk data migrations, see our help desk data migration checklist or our guide to zero-downtime help desk migration. If you're evaluating Ivanti Neurons specifically, our Ivanti Neurons to ServiceNow migration guide covers the target-side considerations.