Who Owns the Ticket History After a Divestiture?

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

The deal closes on a Friday. Logos change, bank accounts move, and somewhere in the announcement there is a clean sentence about an orderly separation. The ITSM ticket history is not in that sentence. It almost never is.

I’ve worked with IT departments for nearly 25 years, so I have watched what actually happens to a service-management database when a company splits in two. The deal lawyers settle who owns the brand, the contracts, and the customer list. The IT team is left holding a question that the purchase agreement glossed over. Ten years of incidents, changes, problem records, and attachments are sitting in one database, and that database now serves two companies that are supposed to have nothing to do with each other.

So the question is simple to ask and hard to answer. After the carve-out, who owns the ticket history, who can still read it, and where does it physically live a year from now?

The deal closes. The data does not split cleanly.

A divestiture separates a business on paper long before it separates the data. The divested unit (call it NewCo) is now its own company. The parent (RemainCo) keeps running the ITSM platform. But the records do not sort themselves into two tidy piles.

Most ITSM databases are commingled by design. A single change record might touch shared infrastructure that served both the divested unit and the parent. A problem ticket might reference a vendor contract that followed NewCo out the door, with resolution notes written by an engineer who stayed with RemainCo. Ownership of any one record is genuinely contestable, and the export you run to “give NewCo its data” will either leave records behind or hand over records that were never NewCo’s to take.

This is the part that surprises people. The legal separation can be clean. The data separation is a knot, and untangling it is engineering work that lands on a team with no budget line for it.

The TSA is a clock, not a solution.

The Transition Services Agreement is the mechanism that keeps the lights on during the handoff. Under the TSA, RemainCo agrees to keep providing certain services to NewCo for a defined window so the new company can stand up its own systems. That window is finite. A TSA often runs 12 to 18 months, though access to a single system like the ITSM platform is frequently cut sooner, as NewCo migrates off RemainCo’s environment to stop the TSA meter running. It is never permanent, because the entire point of a divestiture is that the two companies stop depending on each other.

Read access to the old ITSM platform usually lives inside that TSA. NewCo’s people can still log in and pull a record while the agreement is active. The day the TSA expires, those logins are revoked, and the historical record goes dark for everyone on the NewCo side. Whatever they did not extract and preserve in a form they control is now on the other side of a wall they no longer have a key to.

A TSA is not a data retention plan. It is a deadline, and you rarely control the date.

Both sides still owe the auditor.

Here is what makes the stranded record more than an inconvenience. The compliance obligations survive the separation, and they do not move neatly with the platform.

If NewCo is a public company or becomes one, it owes SOX evidence for IT change controls going back years, including the period when those changes lived in RemainCo’s system. A healthcare carve-out still owes HIPAA retention on the incident history. A financial-services divestiture still answers to GLBA and to regulators who do not care that the data was awkward to separate. The auditor’s question is not “was this hard.” It is “show me the change record from three years ago, with its approvals and its linked records, in context.” If that record is trapped in a platform NewCo can no longer reach, the answer is a finding.

RemainCo is not off the hook either. The records it keeps still contain references to the divested business, and it owes its own retention on its own history. We have written before about why this matters for public companies facing IT-records retention and for regulated industries specifically. A divestiture does not lower the bar for either side. It just adds a wall in the middle of the evidence.

Why the export route fails here specifically

The reflex is to dump NewCo’s records to CSV and hand over a file share. It feels like a clean break. It is not.

When you flatten an ITSM record to a spreadsheet, you keep the rows and lose the record. The expressions, the linked records, the attachments, and the form layout that gave the data meaning all disappear. We covered the mechanics of that loss in detail in CSV export vs. a purpose-built archive. In a divestiture the flattening problem is worse, because you are also making an ownership decision on the way out. Every record you include and every one you drop is a call about what was NewCo’s, and a flat file gives you no way to defend that call later. A column of values is not an audit trail of who owned what.

Migrating the records into NewCo’s new platform instead of a flat file is not the safer path it sounds like. Two ITSM systems rarely agree on the things that matter: date and time formats differ, attachments are stored and referenced differently, the record and data shape are not the same, and lookup values like status, team, category, and priority do not line up between platforms. The records arrive transformed, and the transformations are silent. As one partner told us while scoping a migration, “we’ll lose data and we won’t even know what we lost.”

There is also a cost trap on the other side. The alternative to a real archive is keeping the old platform alive purely so someone can still read the data. Keeping a platform alive on a minimum license just to read it is a recurring cost, and once you add the server, the patching, and the staff time, running a dead system for read access becomes an expensive annual habit that buys you nothing new. For some platforms it is not even an option: most Cherwell licenses expire on December 31, 2026, so after end of life the platform stops running whether you planned for it or not, and the read-access crutch disappears entirely. Now imagine two companies, each tempted to keep paying that bill rather than solve the separation properly. That is the price of not having a plan, charged twice.

What a clean separation of the record looks like

A divested historical record is only safe if it stays three things at once. Intact, meaning the full record with its links, attachments, and form context, not a flattened shadow. Segregated, meaning NewCo’s records and RemainCo’s records can be cleanly divided and each side holds only what is theirs. Governed, meaning the retention rules and access controls travel with the data instead of evaporating when the TSA ends.

That is exactly why we built Cortex Archive the way we did. It reads the metadata already in the old platform’s database and rebuilds a familiar, read-only interface to it, inside the owning company’s own network, with no changes to the data. For a divestiture, each side can hold its own archive of its own records, in its own infrastructure, with nothing leaving either company. The record stays whole, the separation is defensible, and neither side has to keep a dead platform running to answer a question two years from now. It works the same way whether the source is Cherwell, ServiceNow, Ivanti Neurons, or Jira Service Management.

I am not telling you to slow the deal down. Deals move on their own schedule. I am telling you to put the historical record on the separation checklist on purpose, while you still have access to it, instead of discovering the gap after the TSA expires and the door is locked.

One line for your separation checklist

If your company is on either side of a divestiture, carve-out, or spin-off, add one item the deal team almost certainly left off the plan.

When the TSA ends, each company will hold its own complete historical ITSM record, intact and searchable, segregated so each side has only what it owns, and we know exactly where it lives.

If you can write that line today and mean it, the separation is clean. If you cannot, you have just found the work the deal team left out, and the only time to do it is now, while the logins still work.

The deal settles who gets the brand, the contracts, and the customer list. Make sure someone owns the history too, with a name on it and a place it lives, before the TSA expires and there is no good answer left.

Frequently Asked Questions

Who legally owns ITSM ticket history after a divestiture?

The historical records for a divested business unit generally follow that unit, but legal ownership and physical control are separate. The records usually remain inside the parent company’s ITSM platform after close, so the divested entity owns the data in principle while the parent still controls the system that holds it. The purchase agreement and the Transition Services Agreement define who may access what, and for how long.

What is a TSA and how does it affect ITSM data access?

A Transition Services Agreement is a short-term arrangement where the parent company keeps providing certain services, including system access, to the divested company while it stands up its own infrastructure. TSAs are time-boxed, typically running 12 to 18 months, though access to a specific system like the ITSM platform often ends sooner. When the TSA ends, access to the parent’s ITSM platform is typically revoked, and any historical record the divested company did not preserve in a form it controls becomes unreachable.

Can we just export the divested unit’s tickets to CSV?

You can, but CSV export strips the expressions, linked records, attachments, and form layout that make a record usable and auditable. In a divestiture there is an added problem: every record you include or exclude is an ownership decision, and a flat file gives you no defensible way to show how that line was drawn. A purpose-built archive preserves the full record and keeps the separation clean.

Does a divested company still have data retention obligations for old IT records?

Yes. Retention and audit obligations survive the separation. A divested company still owes SOX evidence for historical IT change controls, HIPAA retention on past incident records, GLBA and other industry rules, and any contractual retention terms, even for the period when those records lived in the parent’s system. Losing platform access does not lift the obligation.

How do you separate commingled ITSM records between two companies?

Cleanly separating commingled records requires preserving each record in full context and then dividing the archive so each company holds only what it owns. That is far more defensible than a one-time flat export, because the original record structure, links, and attachments are retained and the ownership boundary can be applied and shown deliberately rather than guessed at in a spreadsheet.

What should be on a divestiture checklist for ITSM data?

Add a single defensible line: when the TSA ends, each company will hold its own complete historical ITSM record, intact and searchable, segregated so each side has only what it owns, with a known location. If you cannot write that today, close the gap before the TSA expires, while you still have access to the source platform.

When a divestiture splits a company, the historical ITSM record does not have to go dark. Cortex Archive stands up a read-only copy of the old platform inside each company’s own network, so both sides keep a complete, searchable, audit-ready record of exactly what they own.