The AI Strategy Problem Hiding in Your Old ITSM Data

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

Whether you have to move off your ITSM platform this year or you are choosing to, the migration project in front of you has a blind spot. And right now it is a more expensive blind spot than it used to be.

Every ITSM vendor is selling the same promise. AI that triages your tickets, drafts your resolutions, and learns your environment over time. It is a good promise. The technology is real.

But the part nobody is putting on the slide is what that AI actually runs on. It runs on your historical ticket data. The models learn from how your team categorized incidents, how they resolved them, what the resolution notes said, which change caused which outage. That history is the training set. It is the only thing that makes the AI yours instead of a generic chatbot.

This is true no matter what you are running or where you are going. Cherwell to Ivanti. ServiceNow to something leaner. Jira Service Management to a competitor. A forced move because a platform hit end of life, or a chosen one because the new tool is better. In every case the same question applies, and almost no one I ask has a clean answer.

When you migrate off your old platform, where does that historical data physically go, and is it still good enough to train anything?

I spent years inside Cherwell as an engineer, so I will use it as the example throughout. But nothing about this problem is specific to Cherwell. It is specific to migration.

Migration moves your operations. It does not preserve your record.

A migration project moves your open tickets, your active CMDB, and your current workflows into the new system. That is the point of it. What it almost never does is carry a decade of closed tickets, resolved incidents, retired change records, and attachments across in usable form. Most migration SOWs leave that out on purpose.

So the historical record gets handled one of two ways. It stays trapped in the old platform, which you keep paying to run. Or it gets exported to CSV and dropped on a file share.

We have written before about why the export route fails for compliance. When you flatten a record from any of these platforms to a spreadsheet, you keep the rows and lose the record. The expressions, the linked records, the attachments, the form layout that gave the data meaning, all gone. An auditor who needs the full context of a change three years ago gets a column of values that no longer means anything.

Here is the part that is new. That same flattening problem is now an AI problem, and a worse one.

Bad data does not just fail an audit. It trains the machine to be confidently wrong.

If you feed an AI a flattened, stale, half migrated export, it does not know the data is degraded. It learns the patterns it is given and answers with total confidence. You are no longer just failing to find a record. You are teaching a system to generate wrong answers at scale and present them as fact.

I saw a clean example of this recently. A team pointed an AI support tool at old data, and it spent months confidently telling customers a policy was still in effect long after it had changed. The model was not broken. The data underneath it was. AI does not fix a messy data situation. It exposes it, and then it multiplies it.

So the organizations rushing to bolt AI onto a new ITSM platform are walking into a trap. The new platform is clean, but it only holds the last few months of activity. The history that would actually make the AI useful is sitting in a dead system, or in a pile of flattened files that have already lost most of their meaning.

The clock makes this urgent, and it is not one clock

Cherwell Service Management reaches end of life on December 31, 2026. Thousands of organizations are migrating off it right now, most to Ivanti Neurons, ServiceNow, or Jira Service Management. That is the migration happening loudest this year.

It is not the only one. Jira Data Center is on its own end of life path, which will push a far larger wave of teams through the exact same decision a couple of years from now. And plenty of organizations are not being forced anywhere. They are leaving ServiceNow or another incumbent simply because a newer platform fits better. Forced or chosen, the historical record faces the same fork at the moment of migration. It either gets preserved properly or it quietly gets stranded.

And the cost of getting it wrong is not theoretical. Keeping a dead platform alive purely for read access is expensive. I have seen a vendor quote a six figure annual number just to let a customer keep reading data they already owned. That is the bill for not having a plan. For regulated teams, the compliance angle is the same story with different stakes—see our audit-readiness guide for public companies and regulated-industries data retention overview.

What good actually looks like

Historical ticket data is only worth keeping if it stays three things at once. Intact, meaning the full record and not a flattened shadow of it. Accessible, meaning a person or a system can search it the way they searched the original. Governed, meaning the access controls and retention rules travel with the data instead of getting lost in the move.

That is exactly why we built Cortex Archive the way we did. It stands up a read only copy of your old platform’s data, inside your own network, that looks and works like the original system. The record stays whole. Nothing leaves your infrastructure. It stays audit ready, and it stays available to whatever you decide to build on top of it later, including the AI. For Cherwell specifically, Cortex Archive for Cherwell connects to your database backup and preserves form views, relationships, and attachments without keeping Cherwell in production.

I am not arguing against migrating. Migrate. The new platforms are better. I am arguing that you should decide what happens to your historical record on purpose, before the old system goes dark, instead of discovering the gap six months later when someone asks the AI a question it cannot answer.

One line for your migration checklist

If you are moving off any ITSM platform, now or in the next couple of years, add one item that is probably not on the project plan yet.

After we migrate, our full historical ticket data will still be intact, searchable, and accessible to both our compliance team and our AI tooling, and we know exactly where it lives.

If your goal is an organization running at full efficiency, you need to be able to write that line and mean it. If you can, you are in good shape. If you cannot, that is the gap, and it is far cheaper to close before the old platform goes dark than after.

That is the conversation worth having.

Frequently Asked Questions

Why does ITSM migration affect AI strategy?

AI on new ITSM platforms learns from how your team categorized incidents, resolved tickets, documented changes, and linked outages to root cause. Migration scopes usually cover live operations, not years of closed history—so the new system starts thin while the patterns AI needs stay stranded on the old platform or in degraded exports.

Where does historical ITSM data go during a platform migration?

Most migration statements of work move open tickets, current CMDB, and workflows. Closed incidents, retired changes, attachments, and long-tail history are often excluded, left on the legacy stack, or dumped to flat files. Neither default path keeps records intact and searchable in original context.

Can CSV or spreadsheet exports of ITSM data train AI reliably?

Not if you need faithful behavior. Flat exports strip expressions, links, attachments, and form context. AI trained on that data learns whatever patterns remain and answers with confidence—it does not know the source was degraded.

Is this only a Cherwell end-of-life problem?

Cherwell EOL on December 31, 2026 makes the gap urgent for many teams today, but the same structural issue applies to any ITSM move—Jira Data Center transitions, ServiceNow replacements, or voluntary platform changes. The question is always where the full historical record lives after cutover.

What should historical ITSM data preserve for AI and compliance?

It should stay intact (full record), accessible (searchable like the source system), and governed (retention and access rules travel with the data). That is what Cortex Archive is built to provide inside your network for legacy ITSM databases.

What should I add to an ITSM migration checklist for AI readiness?

Add a line you can defend: after migration, full historical ticket data remains intact, searchable, and available to compliance and AI tooling, and you know where it lives. If you cannot write that today, close the gap before the old platform goes dark.

For historical ITSM data that stays behind after migration, Cortex Archive preserves the familiar record experience from your database backup—audit ready today, available to the AI you deploy tomorrow.