Evaluate the Exit Before the Entry: The ITSM Criterion Everyone Skips
Across close to 100 enterprise ITSM databases archived, between our own work and our partners’, the teams we meet did everything right by the usual scorecard when they chose the platform years earlier. They just never asked the one question that would have made the eventual exit survivable, because the exit was not on the scorecard.
Why exit never makes the scorecard
The reason is human, not technical. You select a platform when you are optimistic about it. The whole evaluation is framed around getting value from the thing you are about to adopt. Asking “how do we leave this” in the middle of choosing it feels like planning a divorce at a wedding. So it gets left off, every time, and the gap is structural rather than careless.
But every platform is temporary. Vendors get acquired and rationalize portfolios, which is exactly what happened to Cherwell after Ivanti bought it. Vendors change strategy, which is what Atlassian did when it set Data Center to end of life in 2029. Or you simply outgrow the fit. Forced or chosen, you will leave this platform eventually, and the terms of that exit are set by decisions you make now, while you have leverage, not later, when you do not.
What “score the exit” actually means
ITSM vendor scorecard with features, price, support and integrations scored, and the exit row left blank.
Every evaluation scores the first four. The fifth is the only one you cannot renegotiate after you sign.
This is not a vague principle. It is a small number of concrete questions you put on the evaluation scorecard alongside everything else.
| Add to your scorecard | The answer that should worry you |
|---|---|
| Can we extract the full historical record, not just active data? | “Active records export easily.” |
| Do we control the extract, or does the vendor? | “Our professional services team handles that.” |
| What does the data look like once it is out? | “You get a CSV.” |
| What will it cost to read our own history after we leave? | “Keep paying us.” |
Can we get the full historical record out, not just active data? Many platforms make it easy to export current records and hard to extract years of closed history with full fidelity. Ask to see a complete historical export, including links, attachments, and history, before you sign.
Do we control the extract, or does the vendor? If leaving requires the vendor’s cooperation, their professional services, or a fee set at the worst possible moment, you are not in control of your own data. Confirm you can extract independently.
What does the data look like once it is out? A flattened export that has lost its structure is not your record, it is a report about your record. We cover that gap for CSV exports specifically. Score whether the exit produces a usable record or a lossy shadow.
What will it cost to read our own history after we leave? The answer that should worry you is “keep paying us.” Keeping a dead platform alive for read access is a recurring bill, and migrating the full history out instead is a substantial professional-services project. If the only way to read your past is to keep paying the vendor you left, that is lock-in wearing a different hat.
The leverage problem
Here is why this has to happen before the entry. During the evaluation, you have leverage. The vendor wants your business, and you can make data portability a condition. After you sign and migrate years of operations onto the platform, the leverage is gone. The cost of leaving is now enormous, the vendor knows it, and any exit term you did not secure up front is now negotiated from weakness or not at all.
Exit terms are the one part of an ITSM decision that only gets more expensive to fix the longer you wait. Features you can add later. Integrations you can build later. A clean exit you cannot retrofit once you are locked in.
You can also fix the exit you already skipped
If you are reading this already on a platform you chose without scoring the exit, the criterion still applies, just in reverse. You cannot renegotiate the entry, but you can take control of the exit yourself by archiving your historical record into a system you own, independent of the vendor, so that leaving no longer depends on their cooperation or their pricing. That is the build versus buy decision the end-of-life teams are making right now under deadline pressure, and it is the same move, just done late.
Cortex Archive is how you take that control. It puts the historical record on infrastructure you control, read-only and independent of the vendor, so the next end-of-life announcement is someone else’s problem rather than a fire drill for your team. Owning your archive is owning your exit. It supports Cherwell, ServiceNow, Ivanti Neurons, and Jira Data Center.
Choose the next platform on features and price and support. Just add one line to the scorecard first, and mean it: when we leave, we get our complete history out, in a form we control, without paying ransom to read our own past. The teams scrambling this year are the ones who skipped that line. You do not have to be one of them next time.
Frequently Asked Questions
What is the most overlooked ITSM platform selection criterion?
Data portability and exit. Evaluations focus on features, price, support, and integrations, and rarely score how you will extract your full historical record when you eventually leave. That omission becomes costly years later, when leaving means stranded history or paying to keep a dead platform readable.
Why should I evaluate how to leave a platform before I adopt it?
Because every platform is temporary, through acquisition, strategy change, or outgrowing the fit, and your leverage to set exit terms is highest before you sign. After you migrate years of operations onto a platform, the cost of leaving is enormous and any exit term you did not secure is now negotiated from weakness.
What questions assess ITSM data portability?
Whether you can extract the full historical record and not just active data, whether you control the extract independently of the vendor, whether the exported data keeps its structure or arrives flattened, and what it will cost to read your own history after you leave. Put these on the evaluation scorecard.
What is a sign of ITSM vendor lock-in?
The clearest sign is that reading your own historical data after leaving requires continuing to pay the vendor, through professional services, export fees, or keeping the platform alive for read access. If the only path to your past runs through the vendor’s invoice, that is lock-in.
Can I fix this if I already chose a platform without evaluating the exit?
Yes. You cannot renegotiate the entry, but you can take control of the exit by archiving your historical record into a system you own, independent of the vendor. That makes leaving a decision you control rather than one gated by the vendor’s cooperation or pricing.
How does owning an archive relate to owning my exit?
If your full historical record lives in an archive on your own infrastructure, leaving the platform no longer threatens your history. You can migrate active work to a new system and retire the old one without losing or paying to read the past. Owning the archive is what makes the exit yours.
Related reading
- Retire the Platform, Keep the History: Build vs Buy — taking control of the exit you already skipped
- Why DIY ITSM Archives Fail Audits — why the exit has to produce a real record
- How to Archive Jira DC Issues Before a Cloud Migration — exit planning for the next big EOL
- The AI Strategy Problem Hiding in Your Old ITSM Data — why the history you exit with is worth keeping
The cheapest time to secure your ITSM exit is before you sign the entry. Cortex Archive lets you own that exit at any point, keeping your full historical record on your own infrastructure, independent of whatever the vendor decides next.