How to Get Your Cherwell Database from Ivanti Before EOL
Cherwell Service Management reaches end of life on December 31, 2026. If Ivanti hosts your environment, the database is on infrastructure you do not control. Getting the final copy is therefore an operational handoff, not a task to leave until the day someone needs an old ticket.
The sequence matters: prepare early, submit after the last production change, retrieve promptly, restore, and validate before the retained backup expires.
1. Prepare before the final production change
Support queues and internal approvals take time. Complete the preparation while Cherwell is still live, but do not request the final backup while users are still changing records.
- Confirm the request route. Know which Ivanti support account, entitlement, and contact will be used. Make sure that access will still work at cutover.
- Name the final-change owner. One person should declare that the last production change has been made and authorize the request.
- Name the file owner. Assign responsibility for retrieving the backup, checking its size and checksum if provided, and storing an untouched master copy.
- Prepare the restore target. Have a supported Microsoft SQL Server environment with enough storage and an administrator ready to restore the file.
- Define the validation plan. Choose record types, known attachments, custom Business Objects, and date ranges that will prove the backup is usable.
2. Request the final hosted backup at the right moment
For an Ivanti-hosted environment, follow the Getting Your Cherwell Data walkthrough, which links to Ivanti’s request process and summarizes the current steps.
Submit the request as soon as the last person makes the last production change to Cherwell, but no sooner. A backup captured before that point is not the final system of record. Be explicit that you need a native database backup for archival purposes, not a CSV export.
If a migration partner is involved, write down who declares the final change, who opens the ticket, who downloads the file, and who validates the restore. Unassigned handoffs are how this step gets missed.
3. Retrieve, restore, and validate within the retention window
Ivanti’s documented process says hosted backups are retained for 30 days, including after license expiry. Do not read that as permission to wait. Treat it as the maximum recovery window for finding and correcting a bad download, failed restore, or incomplete handoff.
Preserve the original file before working with it. Record when it was downloaded, where the master copy is stored, and who handled it. Restore a working copy to SQL Server, then validate the result while Ivanti can still help.
What you should receive
Ivanti-hosted customers should receive a .BAK file: a native Microsoft SQL Server backup. It is not a CSV dump or a collection of flattened reports. The backup retains the source database tables and relationships, including custom Business Objects and attachments stored in the database.
A native backup is the strongest starting point for preservation, but it does not automatically prove that an archive application will render every customization. The restore and the archive mapping are separate validation steps.
Restore-environment choices that matter
- Separate the application and database hosts. SQL Server can consume substantial memory and I/O. Separate hosts make performance easier to size and troubleshoot.
- Size from the live database. Ask the DBA for current database size, growth, and attachment volume, then add working headroom for restore and indexing.
- Treat Azure SQL Managed Instance carefully. A .BAK restore can require extra handling. Validate full-text indexes and search after the restore rather than assuming they survived.
- Keep latency low. Place the archive application and database in the same region or low-latency network segment.
- Make the archive connection read-only. Preserve an untouched master backup and use a database principal without write permissions for archive access.
How to validate the restored Cherwell database
- Record counts. Compare major Business Objects individually rather than relying on one total.
- Attachments. Open known records with files and confirm the files render correctly.
- Custom Business Objects. Check non-IT use cases such as HR, facilities, security, or any team-specific objects.
- History and date range. Open old and recent records so the sample spans the expected retention period.
- Search. Test exact IDs, free-text terms, and any fields users rely on for discovery.
- Permissions and audit evidence. Confirm who can reach the archive, how access is logged, and how the master backup is protected.
Why a database backup is better than CSV for archival
CSV is useful for analysis, but it flattens relationships and often separates or omits attachments, journals, and custom structures. See the Cherwell CSV export comparison for the trade-offs.
For long-term access, keep the native backup as the preservation source and validate any archive against the records and relationships your organization actually needs.
Frequently Asked Questions
When should I request my final Cherwell database backup?
Prepare the ticket and ownership early. Submit it immediately after the last production change has been completed and confirmed.
How long does Ivanti retain a hosted Cherwell backup?
Ivanti’s documented process states 30 days. Retrieve and validate the backup as soon as it is available so there is time to resolve a problem.
What file do Ivanti-hosted Cherwell customers receive?
A native SQL Server .BAK file. Restore it to a supported SQL Server environment before relying on it for archival access.
Is a CSV export enough to archive Cherwell?
Usually not when users need relationships, attachments, journals, custom Business Objects, or a familiar record view. CSV can supplement a native backup, but it should not silently replace it.
What should I do after the restore passes validation?
Document the evidence, preserve the master backup, and decide how users will search and retrieve records. You can review the Cherwell archive overview or explore the Cortex Archive demo to see the access model.