Cherwell EOL and Data Retention: What European Organisations Need to Know Before December 2026

08 Apr 2026 · By Brian Parks, CEO — Synapse Software
Former Senior Software Engineer at Cherwell Software (2017–2020)

The Question European Organisations Are Not Asking Yet

Earlier this year, I wrote about what happens to Cherwell data at US companies subject to SOX and HIPAA. The European regulatory landscape is different, and in many ways, stricter. But the underlying problem is identical.

The migration project is well underway. ServiceNow, Jira Service Management, Ivanti Neurons, HaloITSM. The platform decision is made. The implementation partner is engaged. Timelines are set.

But there is a question that almost never shows up in the migration project plan: what happens to the historical data that stays behind in Cherwell?

Your migration partner will move your active data. Open incidents, recent changes, current configurations. Everything older stays in the Cherwell database. And after December 31, 2026, that database is sitting on an unsupported platform with no patches, no vendor support, and no clear path to access.

What Lives in Your Cherwell Database That European Regulators Care About

Cherwell is not just a ticketing system. At most regulated organisations I have worked with, it contains:

  • IT change management records tied to critical business systems
  • Incident records with references to personal data (customer, employee, or patient information)
  • Access control and provisioning documentation
  • HR case management data with personally identifiable information
  • Service request records containing financial, health, or sensitive personal data
  • Audit trail logs for IT General Controls
  • Custom business objects unique to your organisation’s compliance workflows

If your Cherwell instance touches any of these, you have regulated data that must remain accessible after the platform goes dark.

The European Regulatory Landscape

GDPR and UK GDPR: Storage Limitation Meets Retention Obligations

GDPR’s storage limitation principle (Article 5(1)(e)) says you should not keep personal data longer than necessary. But it does not set specific time limits. That is up to you to justify based on your processing purposes and any legal obligations.

Here is where it gets complicated for ITSM data. GDPR does not tell you how long to keep records. But other laws do.

Financial records in the UK must be kept for at least 6 years under HMRC requirements, with the Companies Act requiring 6 years for public companies. Tax and financial records in many EU jurisdictions require 6 to 10 years depending on the country. Employment records often carry multi-year retention requirements that vary by country. And sector-specific regulations often extend well beyond that.

The result: your Cherwell database almost certainly contains personal data that you are legally required to retain for years after December 2026. GDPR says you must protect that data with appropriate security measures for as long as you hold it. Running it on an unsupported, unpatched platform after EOL makes that obligation very difficult to meet.

The ICO (UK’s data protection authority) has been clear: if you keep personal data to comply with a legal requirement, you will not be considered to have kept it longer than necessary. But you still need to protect it adequately. An unsupported Cherwell instance with no security patches is hard to defend as “appropriate technical and organisational measures.”

GDPR fines can reach up to 20 million euros or 4% of global annual turnover, whichever is higher. UK GDPR mirrors these maximums.

DORA: The New Standard for Financial Services

The Digital Operational Resilience Act came into full effect on January 17, 2025. It applies to banks, insurance companies, investment firms, payment providers, and their critical ICT service providers across the EU.

DORA requires financial entities to maintain robust ICT risk management frameworks. That includes identifying and managing risks associated with every information asset. An unsupported ITSM platform containing years of operational data is exactly the kind of ICT risk DORA was designed to address.

Key DORA requirements relevant to your Cherwell data:

  • ICT Risk Management (Articles 5–15): Financial entities must identify, classify, and adequately protect all information assets. A Cherwell instance running without vendor support, security patches, or bug fixes after December 2026 creates an unmanaged ICT risk that DORA requires you to address.
  • Third-Party Risk (Articles 28–30): DORA requires a complete register of all ICT third-party contracts. When Cherwell reaches EOL and Ivanti stops providing support, your contractual relationship with the platform effectively ends. But your data does not disappear. You need a documented plan for what happens to the data on an unsupported platform.
  • Incident Reporting: DORA requires significant ICT incidents to be reported within hours. A data breach on an unpatched, unsupported Cherwell instance would trigger reporting obligations and raise immediate questions about your ICT risk management framework.

DORA fines can reach up to 2% of global annual turnover for financial entities, with individual fines up to 1 million euros. For critical ICT service providers, fines can reach 5 million euros.

In Germany specifically, the previous regulatory IT requirements (BAIT, VAIT, KAIT, ZAIT) are being replaced by DORA. BAIT will be completely repealed as of December 31, 2026. Yes, that is the same date Cherwell shuts down. German financial institutions face a double transition.

NIS2: Beyond Financial Services

The Network and Information Security Directive 2 applies more broadly than DORA. It covers essential and important entities across sectors including energy, transport, healthcare, public administration, and digital infrastructure.

NIS2 requires these entities to implement appropriate cybersecurity risk management measures. Running critical IT service data on an unsupported platform falls squarely within the scope of risks that NIS2 expects organisations to manage.

EU member states were required to transpose NIS2 into national law by October 2024, though implementation timelines vary by country.

UK Government: Public Records and FOI

UK government agencies face an additional layer. The Freedom of Information Act 2000 gives the public the right to request information held by public authorities. Historical ITSM records, including service requests, incident reports, and change documentation, are potentially disclosable under FOI.

If those records are trapped on a platform that no longer functions, responding to FOI requests becomes impossible. The UK also has sector-specific records management guidance published by The National Archives, with retention periods varying by record class from 7 years to permanent.

The Regulatory Summary

Regulation Retention requirement Who it applies to What is in your Cherwell DB
GDPR (EU) No fixed period; must justify retention and protect data with appropriate measures All organisations processing personal data of EU residents Incident records with personal data, HR cases, service requests with customer/employee PII
UK GDPR Same as EU GDPR; Companies Act adds 6 years for public companies; HMRC requires 6 years for tax records All UK organisations processing personal data Same as above, plus FOI-responsive records for public authorities
DORA ICT risk management framework required; unsupported platforms create unmanaged risk EU banks, insurers, investment firms, payment providers, critical ICT providers IT change records, incident logs, access control documentation, third-party contract records
NIS2 Cybersecurity risk management measures required Essential/important entities in energy, transport, healthcare, public admin, digital infrastructure IT service records supporting critical infrastructure operations
UK FOI Act Public authorities must retain records accessible for public requests UK government departments, NHS, local authorities, police Service requests, incident reports, change documentation held by public bodies

The Four Options (and Why Three of Them Are Bad)

Every organisation dealing with Cherwell end of life has four options for their historical data:

Option 1: Keep Cherwell alive

Maintain a minimum Ivanti license (approximately $15,000 USD per year for 5 seats), plus server infrastructure, patching, and staff time. After December 2026, there will be no security patches and no vendor support. Under GDPR, DORA, and NIS2, running an unsupported platform with personal data on it is a compliance finding waiting to happen. The pool of engineers who know Cherwell is also shrinking rapidly.

Option 2: Export to CSV or flat files

Write SQL scripts to extract data into spreadsheets. This is the most common approach and the most likely to fail when someone actually needs a record. Flat exports lose form views, relationships between records, attachments, expression-driven fields, and security permissions. When a regulator or auditor asks for the original incident record, a CSV row is not what they expect. The question will be: “Can you produce the original service record from 2024 showing how your team handled this incident, with all linked approvals and attachments intact?” If the answer involves searching through spreadsheets, you have a problem.

Option 3: Migrate all historical data into the new platform

Move everything into ServiceNow or Jira or wherever you are going. Significant professional services cost. 6 to 18 month timelines. Data structure mismatches cause lossy translation. And most migration SOWs explicitly exclude historical data because it is a separate, complex workstream.

Option 4: Do nothing

Let the data go dark when Cherwell shuts down. This violates retention obligations across every regulation covered in this post. It creates audit exposure. And it transfers personal liability to whoever made the call.

There is a fifth approach: preserve the entire Cherwell environment in a read-only archive that maintains the original form views, linked records, attachments, and security groups without requiring an active Cherwell license or any data migration. That is what we built Cortex Archive for Cherwell to do.

What This Means for Your Timeline

December 2026 sounds far away. It is not.

Enterprise procurement in Europe typically takes several months. Government procurement can take six months or longer. If your organisation needs to evaluate, procure, and implement a data preservation solution before the Cherwell EOL date, the planning needs to start now.

DORA compliance is already being monitored. GDPR enforcement is ongoing. NIS2 transposition deadlines have passed. Waiting until Q4 2026 to address historical ITSM data is not a viable strategy for any regulated European organisation.

What European Organisations Should Do Before December 2026

  1. Inventory your regulated data. Which Cherwell business objects contain records subject to GDPR, DORA, NIS2, or sector-specific mandates? How many years of history do you have? Which custom objects are unique to your compliance workflows?
  2. Check your migration SOW. Ask your migration partner explicitly: is historical data in scope? If it is not (and it usually is not), you need a separate strategy for retaining access to that data.
  3. Evaluate your archive options before the deadline. Your retention obligations extend years beyond December 2026. The solution you choose needs to make regulated records accessible, searchable, and intact for the full retention window without depending on unsupported software.

The organisations that handle this well will have their archive strategy in place before the migration is complete. The ones that do not will find out the hard way, the first time an auditor asks for a record they cannot produce.

Frequently Asked Questions

When is Cherwell Service Management end of life?

December 31, 2026. After that date, the platform loses vendor support, security patches, and bug fixes. Cloud customers lose access entirely. On-prem customers can technically continue running, but on an unsupported, unpatched platform.

Does GDPR require a specific retention period for ITSM data?

No. GDPR’s storage limitation principle says you should not keep personal data longer than necessary. But other laws (tax, financial, employment, sector-specific) often require you to retain records for 6 to 10 years. The tension between these obligations is the core problem: you must keep the data, but you must also protect it with appropriate security measures. An unsupported platform does not meet that standard.

Does DORA specifically mention ITSM platforms?

DORA does not name specific technologies. It requires financial entities to identify, classify, and protect all information assets and to maintain robust ICT risk management frameworks. An unsupported ITSM platform containing years of operational and personal data is an unmanaged ICT risk under DORA’s framework.

What about organisations outside the EU and UK?

If your organisation processes personal data of EU residents (even if headquartered outside the EU), GDPR applies. If you provide ICT services to EU financial entities, DORA may apply. The regulations have extraterritorial reach.

Can I just export everything to CSV before the deadline?

You can, but it probably will not satisfy your compliance obligations. Flat exports lose form views, linked relationships between records, attachments, expression-driven fields, and security permissions. When an auditor or regulator asks for the original record in its full context, a spreadsheet row does not meet that standard.

Further Reading

For historical Cherwell data that stays behind after migration, Cortex Archive for Cherwell reads your database backup and preserves the familiar record experience without keeping Cherwell in production.