Carve-Out and Spin-Off ITSM Archive Checklist

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

2026 has been a year of corporate breakups. Honeywell completed the spin-off of its aerospace business in June and split off its advanced materials unit late last year. FedEx stood up FedEx Freight as an independent company in June. Comcast separated its cable networks into Versant at the start of the year. DuPont spun off its electronics business. Kraft Heinz is splitting in two. Every one of those separations looks clean in the announcement. Behind each one is an IT team trying to figure out how to divide a decade of service-management records that were never built to be divided.

If your company is heading into a carve-out or spin-off, this is the checklist the deal documents will not give you. It is the companion to two related posts: who owns the ticket history after a divestiture, which covers the ownership question, and the legacy ITSM data workstream for a TSA exit, which covers how to run it as a project. This one is the list you check off.

Why corporate separations break ITSM data specifically

A service-management database is a web, not a stack of folders. An incident links to a change, which links to a configuration item, which links to a problem record, which has attachments and approvals and a form layout that gives all of it meaning. A divestiture takes that web and runs a line down the middle of it. Some records are clearly the parent’s, some clearly the new company’s, and a lot of them straddle the line because the two businesses shared infrastructure for years.

That is why “just give them their data” is harder than it sounds. There is no clean cut. There is only a boundary you draw on purpose and can defend later, or a boundary you draw by accident and cannot explain when an auditor asks.

Cortex separation split diagram

A commingled ITSM database splits along a documented ownership boundary into two read-only archives, one per company.

There is no clean cut. Split the commingled record along a documented ownership boundary, so each company keeps a complete, read-only archive of only its own records.

The checklist

1. Inventory every system that holds historical records. Not just the primary ITSM platform. Include any secondary instances, archived databases, and integrations that captured ticket data. You cannot separate what you have not found.

2. Draw the ownership boundary deliberately. Decide the rule for which records belong to which company, write it down, and apply it consistently. A documented rule is defensible. An ad hoc one is a finding waiting to happen.

3. Map retention obligations to each side. The divested company keeps its SOX, HIPAA, GLBA, and records-retention obligations for its own history, even for the years that history lived in the parent’s system. The parent keeps its own. Confirm who owes what before you decide who keeps what.

4. Choose a preservation method that keeps records intact. Flattening to CSV keeps the rows and loses the record, as we detail in CSV export vs. a purpose-built archive. For a separation, intact matters double, because a flat file gives you no way to defend how you split ownership.

5. Stand each archive up inside the owning company’s own infrastructure. The whole point of separation is independence. Neither company should depend on the other’s environment, or on a third party hosting the data, to read its own history.

6. Segregate so each side holds only what it owns. This is the step that makes the separation real. Each company should end with an archive of its records and nothing of the other’s, so there is no commingled data and no lingering access that should not exist.

7. Validate against the live source before access ends. Search the archive, pull a known record in full context, and have a compliance reviewer confirm it. Do this while the source system is still available, so you have something to check against. After the Transition Services Agreement expires, there is nothing left to compare to.

8. Assign one accountable owner. When the historical record belongs to everyone on the deal team, it belongs to no one. Put a name on it.

The deadline is the TSA, not the close

The reason this list is urgent is the Transition Services Agreement. During the TSA, the new company can still reach the old platform. When it expires, typically after 12 to 18 months though often sooner for a single system, that access is gone. Everything on this checklist has to happen inside that window, because the window is the last time both companies can touch the source system.

There is also a cost trap worth naming. The alternative to doing the work is keeping the old platform running purely so someone can still read it. That bill is real, and it recurs every year: the license, the infrastructure, and the staff time to keep a retired platform readable. Across two companies, that temptation doubles. A clean archive each side controls is cheaper than two open-ended subscriptions to a system nobody wants to keep.

A bad separation is not just an audit risk. It is lost value.

There is a second cost to a sloppy separation, and it never makes the deal sheet. Your historical ITSM record is not only an audit obligation. It is a data asset, and it is exactly the kind of asset your new company will want to point AI at: years of resolutions, change-to-outage patterns, and cause and effect that a generic model does not have.

But AI is particular about the data it learns from. Gartner defines AI-ready data as data that is aligned to the use case, governed, and rich with the metadata and relationships that give it meaning, and it predicts that through 2026 organizations will abandon 60% of AI projects that are not supported by AI-ready data. In its April 2026 research on infrastructure and operations, Gartner found that among teams whose AI efforts stalled, 38% pointed to poor data quality or limited data availability as a direct cause.

Here is the connection that matters for a separation. The same properties that make a record audit-ready make it AI-ready: the links, the attachments, the workflow history, the context. Flatten that record into a CSV, or strand it in a dead platform, and you have not only failed the auditor, you have handed any future AI a degraded, contextless version of your own history, or no history at all. A separation that destroys the structure of the record leaves that value on the table at the exact moment you are standing up a company that will want to use it.

Preserving the record intact keeps both doors open. That is a deliberate design choice, not a happy accident.

How Cortex fits the separation

Cortex Archive was built for exactly this shape of problem. It reads the old platform’s database and rebuilds a familiar, read-only interface to it inside a company’s own network, with no changes to the data. In a separation, each side can hold its own archive of its own records, in its own infrastructure, with nothing leaving either company and no dead platform left running. Because the archive is a working system rather than a flat export, with REST API access and AI-powered search on a bring-your-own-model architecture in the 3.1.0 release, the record each company keeps stays ready for the auditor and ready for whatever it builds on that history next. It works the same way across Cherwell, ServiceNow, Ivanti Neurons, and Jira.

For each company, the clean separation pays off three ways. Efficiency: each side ends with one archive of its own records, instead of a shared platform neither wants or two dead systems both keep paying to run. Time: the separation finishes inside the TSA window, and afterward any record is a search away rather than a request to the other company’s IT team. Risk: both sides stay compliant and audit-ready on their own, able to produce a record for a regulator without reaching into systems they no longer control.

Work the list while you still have access to the source. The press release says the companies are separate. The auditor will decide whether the records actually are.

Frequently Asked Questions

What is the difference between a carve-out and a spin-off?

Both separate a business unit from its parent. A spin-off typically distributes shares of the new independent company to existing shareholders, while a carve-out often sells a stake to outside investors or a buyer. For ITSM data, the mechanics are the same: a decade of commingled service-management records has to be divided between two companies, usually under a time-boxed Transition Services Agreement.

What is a Transition Services Agreement (TSA)?

A Transition Services Agreement is a short-term contract in which the parent company keeps providing certain services, including access to systems like the ITSM platform, to the divested business while it stands up its own. TSAs are time-boxed, typically running 12 to 18 months, though access to a specific system like the ITSM platform often ends sooner. For ITSM data, the TSA window is the deadline that matters: it is the last period in which the new company can still reach the parent’s platform to extract and preserve its historical records.

Who keeps the ticket history when a company spins off a division?

The historical records for the divested division generally follow that division, but they physically remain in the parent’s ITSM platform after close. The division owns the data in principle while the parent controls the system. Both sides retain their own retention obligations, so the records have to be separated rather than left in one place.

Do both companies need their own archive after a separation?

Usually yes. Each company has its own retention and audit obligations for its own history, and neither should depend on the other’s systems to meet them. Holding two separate archives, each inside the owning company’s infrastructure, is what makes the separation defensible and complete.

What is the deadline for separating ITSM data?

The Transition Services Agreement, not the deal close. During the TSA the new company can still access the parent’s platform, typically for 12 to 18 months though often less for a single system. When it expires, access ends, and anything not preserved becomes unreachable. The checklist has to be completed inside that window.

Can CSV exports separate ITSM data cleanly?

Not defensibly. CSV strips links, attachments, and form context, and in a separation every included or excluded record is an ownership decision a flat file cannot document. A purpose-built archive preserves the full record and lets the ownership boundary be applied and shown deliberately.

Does a poorly executed separation affect AI readiness?

Yes. AI-ready data depends on the context, metadata, and relationships that a flattened export or a stranded platform strips away. Gartner predicts organizations will abandon 60% of AI projects not supported by AI-ready data through 2026. A separation that preserves records intact keeps each company’s history usable for AI; one that flattens or strands it forfeits that value along with the audit trail.

What is the single test for whether the separation is done?

After separation, each company can answer an auditor’s question about a years-old record, in full context, without depending on the other company’s systems. If both sides can, the separation is finished. If either cannot, it is not, regardless of what the announcement says.

Heading into a carve-out or spin-off? Cortex Archive gives each company a read-only, audit-ready copy of its own historical ITSM record, inside its own network, so the separation is as clean in the data as it is on paper.