The Plan That Sounds Simple (Until You Think About It)
I’ve had a lot of conversations with Cherwell admins over the past two years about what to do with historical data after the December 31, 2026 end-of-life date. The most common plan I hear goes something like this: “We’ll just export everything to CSV and call it done.”
I get the appeal. CSV is universal. It’s cheap. Your compliance team can technically point to a folder of files and say the data still exists.
But here’s what I’ve learned after years of working inside Cherwell’s codebase and then building tools that read Cherwell databases: a CSV export doesn’t preserve your data. It preserves some of your data, in a format that strips out most of what made it useful in the first place.
Let me walk through exactly what you lose.
What Actually Happens When You Export Cherwell Data to CSV
Cherwell’s built-in export tool lets you export business object data from grids into CSV or Excel files. One business object at a time. You get a flat spreadsheet of whatever columns were visible in that grid view.
That sounds reasonable until you think about what a Cherwell environment actually contains.
A typical enterprise Cherwell instance has dozens of business objects: Incidents, Problems, Changes, Configuration Items, Knowledge Articles, HR Cases, Facilities Requests. Each one has its own form layouts, relationships to other objects, journal entries, approval chains, and file attachments.
When you export a business object to CSV, every one of those records becomes a single row in a spreadsheet. The relationships between objects disappear. The attachments don’t come with it. The journal history gets flattened into a text blob or dropped entirely. And the form context that made the record understandable to a human reviewer is completely gone.
Five Specific Things CSV Export Strips Out
1. Expression-Driven Fields
This one catches people off guard. Not every field you see on a Cherwell form is a direct database value. Many are driven by “expressions,” which are dynamic calculations that Cherwell’s application layer computes at display time. Think of a field that shows the SLA countdown, or a status indicator that combines values from multiple underlying fields.
When you export to CSV, you get whatever static value was last stored. You don’t get the logic. If that expression was the thing your compliance team relied on to interpret the record, it’s gone.
2. Complex Relationships
Cherwell stores data across many linked objects. An incident record might be linked to a configuration item, a customer, a problem, a change request, multiple journal entries, an approval chain, and a set of tasks. These aren’t simple one-to-one joins. Cherwell’s relationship model supports complex multi-table links, embedded object references, and nested hierarchies.
A CSV export gives you one table at a time. To reconstruct those relationships, you’d need to export every related business object separately, then figure out how to rejoin them using record IDs across dozens of spreadsheets. Most teams don’t even attempt this.
3. Attachments
This is the one that comes up most in conversations. Files attached to records (screenshots of errors, signed approval documents, contracts, configuration exports) don’t come along in a CSV export. They’re stored separately in the database. Extracting them requires a different process entirely, and then you have to figure out how to reconnect each file to the right record.
I’ve talked to admins who discovered this gap only after their Cherwell license expired.
4. Form Views and Layout Context
When an auditor reviews a record, they expect to see it in context. In Cherwell, that means the form layout: fields arranged in a specific order, tabs grouping related information, related items displayed inline, journal entries in chronological order. All of that context is defined in Cherwell’s metadata configuration.
A CSV file is rows and columns. There’s no form context. There’s no visual arrangement. A compliance reviewer looking at row 47,231 in a spreadsheet has no way to understand what they’re looking at without recreating the mental model of the original Cherwell form.
5. Audit Trail Integrity
Regulated industries need to demonstrate that records are complete, unaltered, and presented in their original format. A CSV export is a point-in-time extraction that strips structure, removes attachments, and eliminates the application context. An auditor reviewing a CSV has reasonable grounds to ask: “How do I know this is the complete record? Where are the attachments? Where’s the change history?”
You can’t answer those questions with a spreadsheet.
“But We’ll Put the CSVs in a Data Warehouse”
This is the next version of the plan I hear. Export to CSV, load into a data warehouse, and query from there.
The data warehouse solves the storage problem. It doesn’t solve the fidelity problem. You still lose expression-driven fields, form context, and attachments. You still have to manually reconstruct cross-object relationships. And you’re now maintaining a custom data pipeline for a dead platform.
Who builds that pipeline? Who maintains it? Who documents the table mappings so the next person can understand which database columns correspond to which Cherwell fields? The pool of people who understand Cherwell’s internal data model is shrinking every month as teams complete their migrations and move on.
What a Purpose-Built Archive Actually Preserves
A purpose-built archive for Cherwell data reads the configuration metadata directly from the database. It understands how business objects are defined, how relationships are structured, how expressions compute, and where attachments are stored. It reconstructs a familiar form view automatically, the same layout and context your team saw in Cherwell.
That means: relationships are intact. Attachments are accessible from the record. Journal entries display in order. Custom business objects work the same way out-of-the-box objects do.
No export step. No data transformation. Minimal configuration. No pipeline to maintain.
When CSV Actually Makes Sense
I’m not saying CSV is always wrong. If you need a quick statistical summary of ticket volumes by month, a CSV export works fine. If you’re feeding aggregate numbers into a reporting dashboard, export away.
But if you’re retaining historical Cherwell data for compliance, audit readiness, or operational reference, a flat file export creates more risk than it eliminates.
The question isn’t “can we get the data out?” The question is: “When someone needs to find a specific record two years from now, will they be able to understand what they’re looking at?”
With a CSV, the honest answer is: probably not.
Frequently Asked Questions
What data does a Cherwell CSV export actually include?
A CSV export from Cherwell includes the visible columns from a single business object grid view. It does not include related objects, attachments, journal entries in full context, or expression-driven field calculations.
Can I export Cherwell attachments to CSV?
No. Attachments are stored separately in the Cherwell database. CSV export only captures tabular field data. Extracting attachments requires a separate database-level process, and you still need a way to link each file back to its parent record.
Is a CSV export from Cherwell audit-ready?
In most regulated environments, no. Auditors expect records in their original format with complete context: related items, attachments, and audit trails intact. A CSV provides a flattened subset of the record without that context.
What are expression-driven fields in Cherwell?
Expressions are dynamic calculations defined in Cherwell’s configuration layer. They compute field values at display time based on logic that combines multiple data points. When you export to CSV, you get only the last stored static value, not the expression logic.
What happens to Cherwell data relationships in a CSV export?
They disappear. Cherwell uses a complex relationship model that links business objects through multi-table connections, embedded references, and hierarchies. A CSV export produces one flat table per business object. Reconstructing relationships requires manual cross-referencing across multiple exported files.
How does a purpose-built archive differ from a CSV export?
A purpose-built archive reads Cherwell’s database metadata to reconstruct form views, relationships, attachments, and expression logic automatically. Records display in their original context with minimal configuration. No data transformation or export pipeline is required.
What Cherwell content versions does Cortex Archive support?
Cortex Archive officially supports every Cherwell content version back to 8.0. Earlier versions may be supported on a case-by-case basis.
Synapse Software