Cherwell End of Life in 2026: What to Migrate, What to Rebuild, and Where to Go Next
Cherwell reaches end of life on December 31, 2026, and cloud tenants close 30 days later. Learn what to migrate, what to rebuild, and which alternatives fit.

Ivanti ends Cherwell Service Management on December 31, 2026. Cloud customers face a second, harder deadline about 30 days later, when Ivanti says their tenants stop being accessible. On-premises customers keep a running system with no vendor behind it.
The date is the easy part. Cherwell gave administrators a no-code builder, and years of custom Business Objects, One-Step Actions and mApps now hold processes that may exist nowhere else in writing.
That build is what drives organizations out. When Arriva, a UK-founded transportation company with more than 35,000 employees, moved from Cherwell to Ivanti Neurons for ITSM, Ivanti's account of the move describes an IT team frustrated by the system's growing complexity.
It is also where the migration risk lives. Comparing ITSM platforms takes a few weeks of demos. Deciding which customizations deserve a second life, which a new platform already handles, and which should retire takes far longer, and that work decides whether your next platform turns into another Cherwell.
If you're starting late, the order of work matters more than the platform you pick. Protect the data first, inventory the build second, and choose the destination third.
What Happens to Cherwell on December 31, 2026
Ivanti's end-of-life listing gives December 31, 2026 for both Cherwell Service Management and Cherwell Asset Management. Customers received the notice on October 31, 2023, and it stated that contract end dates would not go past that day.
A pinned post in Ivanti's Cherwell community from November 2025 confirms what stops after the deadline: product updates and official support. Everything else depends on how you run Cherwell and which version you're on.
Your deployment model sets the real deadline
Ivanti's end-of-life FAQ spells out what happens to each deployment type. The original sits on Ivanti's customer hub, so the wording below comes from the copy published by Ivanti partner Service Dynamics. Check it against your own Ivanti documentation before you plan around it.
For cloud customers, the FAQ says the tenant will be discontinued and will no longer be accessible 30 days after the end-of-life date. For on-premises customers with perpetual licenses, it says the product will continue to run, but Ivanti will no longer provide support.
Only two versions still have support
Ivanti's version support matrix gives each release 12 months of feature updates and 18 months of technical support from its release date. The 2025.2 releases are capped at the end-of-life date.
Older releases already sit in best-effort territory. Ivanti says it will not log new bugs found on retired versions and warns that running one may affect your ability to renew. Partners quoting a July 2024 Ivanti notice report that Ivanti no longer recommends upgrading from an unsupported version, so a late upgrade to 2025.2 is a conversation to have with Ivanti before you attempt it.
If You Can't Finish by December 31
A late start narrows the realistic options to five, and most plans combine two of them. Deployment model decides which ones are open to you. On-premises customers with perpetual licenses can keep a working system after the deadline, while cloud customers have roughly 30 days of access, which makes protecting the data the first job.
A bridge to Ivanti Neurons for ITSM buys a supported platform without a new vendor relationship, and Ivanti says it avoids paying for two products during the transition. It is still a new platform: workflows get rebuilt and data gets reloaded.
If you suspect you'll leave Ivanti within a few years, price the second migration into the decision.
Running Cherwell unsupported works only as a bridge with an end date. Ivanti documents no compatibility commitments for future operating systems, databases or browsers.
I couldn't find any public Ivanti statement on whether license validation behaves differently after the deadline, so get that answer in writing before you count on the server staying up.
Third-party support exists for this gap. StrataCom, a former Cherwell partner, states it offers extended support for unsupported Cherwell versions. It can help with operations, but security fixes still have to come from Ivanti, and Ivanti has announced none.
A phased cutover keeps new intake on one system while the old one empties. Start with incident and request, set a firm date after which nothing new enters Cherwell, then move change, assets and the remaining processes.
Migration tooling can cover the overlap: Precision Bridge says its replication and archiving app for ServiceNow keeps legacy and new systems synchronized during transitional periods.
Your Real Migration Problem: Customization Debt
Cherwell put a no-code builder in administrators' hands, and years of use turned many instances into custom applications. The configuration lives in CSM Administrator.
Business Objects hold the data, forms sit on top of them, One-Step Actions automate work through a flowchart editor, and every change publishes through a Blueprint.
mApps package all of it for reuse. Ivanti's Cherwell Asset Management mApp, for example, bundles Business Objects, One-Step Actions and saved searches, and integrations such as PagerDuty's shipped the same way.
None of these constructs moves to another platform as built. Ivanti describes its own successor as a clean install that keeps many core CSM tools, including stored expressions, values, prompts and incoming webhooks, and it tells Cherwell customers they'll no longer work with blueprints. None of the other destinations reviewed for this guide documents an importer for Cherwell configuration.
Build the inventory from a schema export
Cherwell's own conference material describes the product as self-documenting. Create a Blueprint in CSM Administrator, then use Tools > Export Schema to output the definitions as HTML, XML, TXT or RTF.
That export is your inventory. Every Business Object, form, One-Step, automation process, dashboard and integration in it needs a decision before you sign a contract for the destination.
Triage every item into one of three outcomes
The inventory only helps if every line gets a verdict. Three questions, asked in order, are enough to sort it.
Be strict with the rebuild pile. Every rebuilt customization carries upgrade and administration cost on the new platform, which is exactly how the debt built up the first time.
Arriva's results point the same way. Ivanti's write-up of its move reports a large reduction in dashboards and upgrades that no longer need extensive support to troubleshoot, both consistent with carrying less custom work forward.
Set a governance rule before go-live
If the new platform also lets administrators build freely, decide now who approves a custom object or workflow, what business case it needs, and when it gets reviewed. A quarterly review of custom work keeps the new instance close to standard configuration, where vendor upgrades stay cheap.
What to Migrate, What to Rebuild and What to Archive
Data and process need different treatment. Reference data, the records the new platform needs on day one, migrates. Processes rebuild on the new platform's own tooling, and ticket history is a judgment call with two valid answers.
Two models for ticket history
Both models have public examples across industries. Every full-history move found during research involved vendor professional services or partner-built code, so budget for one or the other if you need history inside the new tool.
Ivanti's Memorial Health System case states the migration retained all of the organization's data, and Ivanti partner Service Quality says customers have several ways to move Cherwell data into Neurons. Treat those as vendor-side evidence that full-history moves are possible, then price the services they require.
Getting the data out of Cherwell
Partner Aelum Consulting describes three export routes: Cherwell's built-in export tool for Business Objects and grid data in CSV or Excel, the Cherwell API for relational data, and database exports for anything the tool doesn't capture. Larger migrations usually need all three, because the hard part is keeping records connected to each other.
For cloud customers, the last route runs through Ivanti. Service Quality states customers can request their data within 30 days after the grace period, in a standard database export format. I couldn't find the format, size limits or turnaround documented on Ivanti's own pages, so request the export early and test that it restores.
Four ways to keep history without migrating it
- Keep on-premises Cherwell running read-only. This option needs a perpetual license and a server you're willing to isolate.
- Report from the exported database. Service Quality states exported Cherwell data can be read with Power BI or similar tools.
- Replicate history into the new platform's reporting layer. Precision Bridge says its ServiceNow app can copy data from a legacy ITSM platform for BI reporting and analytics.
- Store history beside the new platform. Atlassian's Cherwell migration guidance lists a separate data warehouse, a dedicated project for historical records, or remapping history to the new data model.
Cloud customers can use only options two to four. Plan them before December, while the tenant still answers.
How Long a Cherwell Migration Takes
No vendor publishes migration durations by organization size. The published figures that do exist come from three different kinds of source, and the gap between them is worth seeing before you commit to a date.
Arriva's figure comes from the company's own description of the project at an Ivanti user group session: six years on Cherwell, a yearlong project, and go-live on Ivanti Neurons for ITSM in March 2024. The six-month figure for manufacturer EJ Group comes from its implementation partner, T4S Partners, which credits a reliance on out-of-the-box features.
InvGate's Cherwell plan puts go-live at about 45 to 90 days after kick-off, which it describes as its average implementation time. I'd treat any vendor figure as a best case for a lightly customized instance and plan from your own triage results.
The phases, in order
The phases overlap in practice. The gates shouldn't: each one needs evidence before the next phase spends money.
The Define and Shortlist phases are where late movers save the most time. Write down current and future requirements, functional and non-functional, before any demo, then cut the field to two or three platforms and judge them on fit, non-functional requirements and cost. Peer organizations in your region that have already left Cherwell are often the fastest source of honest references for both platforms and implementers.
Decide on ITSM or Enterprise Service Management Before You Shortlist
Extending the platform to HR, facilities or finance changes the license on some platforms and adds nothing on others. Settle the scope before the first demo, because it reorders the shortlist.
If another department could join within the contract term, price that scenario now. A second platform change in three or four years would repeat every step in this guide.
Ask each vendor to quote the expansion scenario as a separate line item, even if you won't buy it in year one. That fixes the price of growth before you depend on the platform.
Cherwell Alternatives, Grouped by Commercial Model
Ivanti's successor has the widest spread of documented Cherwell moves: Arriva in transportation, Memorial Health System in healthcare, EZCORP in consumer finance, EJ Group in manufacturing, and a public tender from the City of Oldenburg in Germany.
Outside Ivanti, manufacturer Jostens moved to Jira Service Management with an Atlassian partner, and ServiceNow, HaloITSM, InvGate and EasyVista all run Cherwell replacement programs through partners or their own teams.
Most of these accounts were published by the vendor or partner involved. Read them as evidence that a path exists, and verify the details in your own proof of concept.
The table groups these options by commercial model instead of ranking them. Pricing comes from each vendor's published pages as of October 2026, in US dollars.
Staying with Ivanti
Staying with Ivanti keeps one contract and one vendor relationship. Ivanti has named a dedicated executive for Cherwell customers, says it has tooling for the move, and runs regular Ask the Expert sessions with a former Cherwell professional services consultant.
The customer accounts still describe real projects. Arriva's took a year, Memorial Health System's used Ivanti Professional Services, and EZCORP's user-group session covered custom problem management workflows and English and Spanish support in its new environment.
Enterprise suites
ServiceNow and BMC Helix carry the deepest module catalogs and the strongest US government authorizations of the group, with quote-only pricing. If you're weighing the two, our ServiceNow vs. BMC Helix vs. Jira Service Management guide covers them in depth.
BMC Helix is also changing ownership. On June 17, 2026, Montagu agreed to buy a majority stake in BMC Helix from KKR-owned BMC Software, which keeps a minority stake. Confirm which legal entity you'll contract with and what roadmap commitments it will put in writing.
Platforms with published pricing
HaloITSM, Freshservice, Jira Service Management and InvGate let you build a budget before the first sales call. Their packaging conditions vary more than their list prices suggest, so read the next section before comparing totals. For the mid-market trio, see our comparison of ServiceNow, Jira Service Management and Freshservice and our breakdown of what Jira Service Management cannot do out of the box.
Compliance and data residency checks
Regulated buyers in any sector need the same handful of answers: which government authorizations a platform holds, which security attestations are current, where data can live, and whether the self-service portal meets accessibility standards. ServiceNow's Government Community Cloud appears on the FedRAMP Marketplace, BMC lists its FedRAMP and DoD authorizations, and InvGate and EasyVista publish their security certifications and TX-RAMP status.
Selection Criteria That Decide the Outcome
Incident, problem, change, request and knowledge management appear on every platform in this guide, so a feature checklist separates them less than you'd expect. Two things do separate them: packaging terms that change what you pay, and how much administration a routine change requires.
License terms that change the bill
ServiceNow's packages page lists the tier contents but no prices, and BMC's Service Management licensing documentation was last updated on October 1, 2026. InvGate, Freshservice, Atlassian and Halo publish list prices. All of them change terms without notice, so get the ones you rely on written into the order form.
Availability and exit terms
Your next exit starts the day you sign. Ask how data comes back out, and in what format, before the contract is final.
ServiceNow's terms come from the subscription agreement it publishes on the UK G-Cloud marketplace, a version dated November 2022. BMC's commitment appears in its service levels documentation, and EasyVista's in a reseller listing on the same marketplace. Where the table says not verified, ask for the clause before you sign.
Measure admin effort in the proof of concept
Every vendor in this guide describes its configuration as low-code or no-code, and none publishes administrator staffing requirements. A timed test with your own administrator at the keyboard is the only evidence you'll get, and it's worth more than any demo a sales engineer runs.
Score each platform on time to complete and on whether a vendor engineer had to step in. Then multiply the slowest routine task by the number of change requests your team handles in a year, and you'll have a rough sense of the administration load you're signing up for.
Sizing inputs to bring to every quote
- Agents, split into named and concurrent, because several platforms price them differently
- People who submit requests, including occasional users, because portal limits vary
- CIs and assets, because asset units and object caps drive cost on some platforms
- Departments in scope now and within the contract term
- Environments beyond production, such as development and test
- Residency or government authorization requirements
None of the vendors reviewed prices by ticket volume, so ticket counts matter more for capacity planning and staffing than for the license quote.
Choosing an Implementation Partner
Much of the former Cherwell partner network now sells other platforms. Service Quality, an Ivanti Premier Partner and former Cherwell Preferred Partner, now sells Ivanti Neurons.
StrataCom offers Jira Service Management packages and a Cherwell-to-JSM data migration toolkit, and co-presented a Cherwell migration webinar with EasyVista. Service Dynamics states it migrates Cherwell customers to Jira Service Management, ServiceNow, HaloITSM and Ivanti Neurons.
That history helps, because these firms know Cherwell's data model. It also means most migration advice in circulation comes from someone selling a destination. Ask questions that test method, and weigh the answers against your own triage.
Partner-built tooling can carry the hardest part. Jostens moved several years of historical Cherwell data from its SQL database into Jira Service Management using custom programming its partner, Isos Technology, had developed. That approach works, and it raises a question worth putting to every partner: who keeps the code when the project ends?
The last question matters most. A partner that resells one platform can still run a fair evaluation, but you should know where the incentives sit before you take its shortlist. Our guide to switching IT vendors without downtime or loss of control covers the contract side of the handover.
Check Your Cherwell Migration Risk
Answer six questions to see your exposure on January 1, 2027, the migration path that fits your situation, and what to look for in a destination platform. The result gives category-level guidance built from the deadlines and terms in this guide.
Three Decisions, in This Order
Protect the data first. Confirm your deployment model and version, get a verified export out of any cloud tenant, and freeze new Cherwell development so the inventory stops moving.
Inventory the build second. The schema export shows how much of your Cherwell instance you built yourself, and the triage turns that list into a scope you can price.
Choose the destination third, with licensing terms, exit terms and a timed admin test as the deciding evidence. Reverse the order and the size of your customization debt surfaces during the build, when every surprise costs time the deadline no longer gives you.
Also read: ServiceNow vs. BMC Helix vs. Jira Service Management: The Enterprise ITSM Decision Guide
Leaving Cherwell? Find ITSM Vendors Anonymously
Browse pre-vetted ITSM platforms and migration partners on TechnologyMatch. Match with vendors that fit your deployment model, scope and timeline, and reach out only when you're ready. It's private and free for you.
FAQ
When is Cherwell end of life?
Cherwell Service Management reaches end of life on December 31, 2026, and Ivanti lists the same date for Cherwell Asset Management. Ivanti notified customers on October 31, 2023, and stated that contract end dates would not extend beyond December 31, 2026. After that date, Ivanti provides no product updates or official support. Cloud customers face a second deadline: Ivanti's end-of-life FAQ says tenants become inaccessible 30 days after the end-of-life date.
What happens to Cherwell after end of life?
Ivanti stops releasing updates and providing official support. Cloud tenants are discontinued and become inaccessible 30 days after December 31, 2026, according to Ivanti's FAQ. On-premises installs with perpetual licenses keep running without support. Ivanti has published no extended support program, paid extension or security fixes for any version after the end-of-life date, so any Cherwell system still running carries unpatched risk from that point on.
Can I keep using Cherwell on-premises after end of life?
Yes, if you hold a perpetual license. Ivanti's FAQ states the product will continue to run, without support. Ivanti documents no compatibility with future operating system, database or browser versions, and its published FAQ doesn't address term-licensed on-premises installs. Treat continued use as a short, controlled bridge: isolate the server, restrict changes, use it mainly as a read-only archive and set a fixed decommission date.
What is replacing Cherwell?
Ivanti names Ivanti Neurons for ITSM as its go-forward product, and customers in transportation, healthcare and consumer finance have documented moves to it. You can choose any ITSM platform: manufacturer Jostens moved to Jira Service Management, and ServiceNow, HaloITSM, InvGate and EasyVista all market Cherwell replacement programs. Build the shortlist from your scope, licensing terms and administrative effort, since core ITSM features overlap heavily across these platforms.
Is Ivanti Neurons for ITSM the same as Cherwell?
Ivanti Neurons for ITSM is a separate product, formerly called Ivanti Service Manager. Ivanti describes the move from Cherwell as a clean install that keeps many core CSM tools, including stored expressions, values, prompts and incoming webhooks, and says customers will no longer work with blueprints. Plan it as a full migration: workflows, forms and One-Step automations need rebuilding and data needs loading, even though the vendor stays the same.
How long does a Cherwell migration take?
No vendor publishes durations by organization size, and the public figures come from different kinds of sources. Arriva describes a yearlong project before going live on Ivanti Neurons for ITSM in March 2024. A partner reports six months for manufacturer EJ Group, and InvGate cites 45 to 90 days after kick-off as its average. Treat vendor figures as a best case: your customization level and data decisions set your real timeline.
What should I migrate from Cherwell and what should I rebuild?
Migrate reference data first: CMDB records with their relationships, people and groups, and reviewed knowledge articles. Decide ticket history separately, either migrated for continuity or kept in an archive you can still search. Rebuild workflows, One-Step Actions, forms, dashboards and the service catalog on the new platform, because none of the destinations reviewed documents an importer for Cherwell's configuration. Retire anything no current process depends on.


