Synapse Software
Cherwell EOL Dec 2026: What Happens to Your Data
On October 31, 2023, Ivanti announced that Cherwell Service Management — the ITSM platform used by an estimated 2,000+ organizations worldwide — would be discontinued. The End of Life (EOL) date is set for December 31, 2026.
That date is now less than 11 months away.
Most of the conversation around the Cherwell sunset has focused on migration — which ITSM platform to move to, how to plan the cutover, which consulting firm to hire. That’s an important conversation. But there’s a question that gets far less attention, and it’s one that can create serious compliance exposure if left unanswered:
What happens to your historical Cherwell data after December 31, 2026?
This post walks through exactly what the EOL means, what your options are, and what you need to know to protect your organization.
What “End of Life” Actually Means
End of Life for Cherwell doesn’t just mean “no more updates.” Here’s the timeline and what each milestone actually means:
| Date | What Happens | Impact |
|---|---|---|
| Oct 31, 2023 | Ivanti announces Cherwell EOL | Clock starts. Organizations begin planning. |
| Sep 2024 | Support ends for versions before 2023.1 | Cloud customers on older versions: service deactivated 30 days after renewal. On-prem: no Ivanti support. |
| Jun 2025 | Support ends for version 2023.3 | Only the latest 2025 release remains supported. |
| Dec 31, 2026 | Full End of Life. All support ends. | Cloud instances shut down. On-prem can technically keep running but with zero support, zero patches, and mounting security/compliance risk. |
The critical point: after December 31, 2026, cloud-hosted Cherwell instances will be shut down. On-premises installations with perpetual licenses can technically continue to run, but with no support, no security patches, and no updates from Ivanti. That means you’re running unpatched, unsupported software connected to a SQL database containing potentially sensitive data — a growing liability that compliance auditors and security teams will increasingly flag. Ivanti has also clarified that upgrading from an unsupported version is no longer a recommended path — the effort required leaves little time to migrate before EOL.
The Data Question Nobody Is Talking About
When you migrate from Cherwell to ServiceNow, Jira Service Management, Halo, or any other platform, your migration partner will help you move your active data — open incidents, current configurations, knowledge articles, maybe the last 12–24 months of tickets.
But what about the rest?
Most enterprises running Cherwell have 5, 10, sometimes 15+ years of historical ITSM data. Incidents, problems, changes, HR cases, facilities requests, custom business objects, configuration items, journals, attachments. All of it living in a SQL Server database that Cherwell reads.
That data doesn’t migrate automatically. And most migration partners explicitly scope it out of their projects, because migrating a decade of historical records into a new platform is expensive, complex, and often breaks the new system’s data model.
So the question becomes: how do you retain access to historical Cherwell data after the software stops working?
Why This Is a Compliance Problem, Not Just an IT Problem
For many organizations, this isn’t optional. Regulatory frameworks mandate that you retain access to historical records for specific periods:
| Regulation | Retention Period | Who It Applies To |
|---|---|---|
| HIPAA | 6 years (federal minimum); state laws often extend to 7–10 years | Healthcare providers, health plans, business associates. Covers PHI-related compliance documentation, audit logs, and breach records. |
| SOX (Sarbanes-Oxley) | 7 years | All publicly traded US companies. Covers financial records, audit work papers, internal control documentation. |
| FERPA | 3 years (federal minimum under GEPA); state laws typically 5–7+ years | Educational institutions receiving federal funding. State laws govern student record retention periods; FERPA requires access controls while records are maintained. |
| GLBA | Varies; disposal required within 2 years after last use unless otherwise required | Financial institutions. Requires written information security program protecting customer financial information. Other banking regulations (e.g., BSA) may extend retention. |
| SEC Rule 17a-4 | 3–6 years depending on record type | Broker-dealers and financial services firms. Trade blotters, ledgers, and customer account records: 6 years. Communications: 3 years. Must be readily accessible for first 2 years. |
| GDPR | As long as necessary for stated purpose; must demonstrate accountability | Any organization processing personal data of EU residents. Requires documented retention policies, subject access request fulfillment, and demonstrable compliance. |
If your Cherwell instance contains records subject to any of these frameworks — and if you use Cherwell for HR cases, facilities management, or internal IT operations, it almost certainly does — you need a compliant way to access that data for years after the software shuts down.
The risk isn’t theoretical.
If an auditor asks for 5-year incident history and your only copy is locked in a database that no software can read, you’re facing a compliance gap — not a convenience problem. The data exists, but you can’t produce it in a usable format.
Your Four Options (and What Each Actually Costs)
When it comes to handling historical Cherwell data, organizations generally have four paths:
Option 1: Keep Cherwell Running
Some organizations plan to maintain Cherwell on-premises as a read-only archive after EOL. According to Ivanti’s FAQ, on-premises perpetual license holders can technically keep the software running — but with zero support, zero security patches, and zero updates. You’re running unsupported, unpatched software connected to a SQL database containing potentially sensitive data. Meanwhile, Ivanti will no longer process license renewals for unsupported versions, and cloud instances will be shut down entirely.
- Cost: ~$15,000/year (minimum 5 licenses) while available, plus infrastructure costs, plus security risk
- Risk: No security patches. No support. Compliance auditors may flag unsupported software as a risk.
- Verdict: Not viable past December 2026 for most organizations.
Option 2: Export Everything to Flat Files
Export all Cherwell data to CSV files or a data warehouse. This preserves the raw data, but you lose everything that makes Cherwell data usable: form views, relationships between records, journal entries, attachments, and the context that ties an incident to a configuration item to a change request.
- Cost: Engineering time to export + storage costs. Ongoing cost every time someone needs to query historical data (requires SQL or developer expertise).
- Risk: Data without context. Relationships lost. Expressions that drove Cherwell form views aren’t captured. Custom business objects may not export cleanly.
- Verdict: Better than nothing, but creates a permanent gap in accessibility and usability.
Option 3: Migrate All Historical Data to Your New Platform
Ask your migration partner to bring everything over — every incident, problem, change, and custom object from the past decade. This is the most comprehensive option, but also the most expensive. Migration partners typically scope this as a major professional services engagement, and the complexity of mapping Cherwell’s flexible data model to a new platform’s schema is significant.
- Cost: Tens to hundreds of thousands of dollars in professional services, depending on data volume and complexity.
- Risk: Data model mismatches. Custom objects may not have equivalents. Performance impact on the new platform. Timeline delays.
- Verdict: Works for recent data (12–24 months), but impractical and expensive for a full historical archive.
Option 4: Deploy a Purpose-Built Archive
Use an archival tool specifically designed to read Cherwell databases and provide a familiar, searchable interface to historical data — without any data migration, data changes, or complex configuration. The archive runs on your own infrastructure (self-hosted), connecting directly to your existing Cherwell database backup.
- Cost: A fraction of the alternatives. Perpetual license models mean the software continues to work even after your support period ends.
- Risk: Lowest risk option. Data never moves. Read-only by design. Runs within your existing security infrastructure.
- Verdict: Purpose-built for this exact problem. Preserves the full Cherwell experience — forms, relationships, attachments, journals, custom objects — at a fraction of the cost of alternatives.
What You Should Do Now
Whether you’re already mid-migration or just starting to plan, here are the steps to protect your historical data:
- Inventory your Cherwell data. How many years of history do you have? Which business objects contain regulated data? Which custom objects are unique to your organization?
- Check your retention requirements. Talk to your compliance team. Which regulations apply to you? How many years of historical access do you need? Is a CSV export sufficient for audit purposes, or do you need searchable, contextual access?
- Separate archival from migration. Don’t burden your migration project with a decade of historical data. Let your new ITSM focus on the future. Handle historical data separately with a purpose-built solution.
- Secure your database backup. Request your Cherwell database from Ivanti now. This typically takes 1–3 weeks for cloud-hosted instances. For on-premises, ensure you have a clean backup of your SQL Server database.
- Evaluate your archival options before the deadline. Don’t wait until Q4 2026 when every Cherwell customer is scrambling. The organizations that plan now will have smoother transitions and better vendor support.
The Bottom Line
The Cherwell EOL deadline is real, and it’s approaching faster than most organizations expect. Migration to a new ITSM platform is the right move — but migration alone doesn’t solve the historical data problem.
Your historical Cherwell data represents years of institutional knowledge: incident patterns, resolution procedures, configuration histories, compliance records. Losing access to that data isn’t just an inconvenience — it’s a compliance risk, a knowledge gap, and a liability.
The time to plan is now, while you still have options.