Legacy ITSM Data in a TSA Exit: Best Practices
A TSA sounds like plenty of time, and on paper it is. It rarely feels that way by the end, because the clock did not start when the data workstream got a project manager. It started the day the deal closed, and the historical record stayed nobody’s job while the cutover consumed everyone’s attention.
This is the field-guide follow-on to who owns the ticket history after a divestiture. That post covers the ownership question. This one is the playbook: how to keep the legacy ITSM data from being the thing that blows the TSA timeline.
Why legacy data falls through the cracks
A TSA exit plan is built around live operations, not history. The typical plan covers:
-
Standing up the new tenant and moving active users
-
Cutting over email, identity, and endpoints
-
Migrating open tickets and the live CMDB
-
Decommissioning access on schedule
None of that touches the decade of closed records in the old system. The migration moves what the business needs on Monday. It does not move what the auditor needs in two years. So the historical record sits in a blind spot: still readable today, gone the day the TSA expires.
Best practices for the data workstream
Pull the legacy data out of the migration plan, run it as its own workstream, and work these practices in order:
-
Start on day one of the TSA, not the final stretch. The work itself is short. Almost every failure is a late start, discovered with no time left to validate.
-
Give it one accountable owner. When the record belongs to everyone on the cutover plan, it belongs to no one. The owner need not be senior, just named.
-
Scope ownership deliberately and write the rule down. In a carve-out the database is commingled. A documented, repeatable boundary you can show an auditor beats a perfect one you cannot reconstruct later.
-
Preserve the whole record, not a CSV. You get one pass at the source. Flattening drops the links, attachments, and form context that make a record auditable. (What flattening loses.)
-
Stand it up in your own infrastructure. The point of a divestiture is independence. An archive that depends on the parent’s environment, or on a third party hosting your data, is not independence.
-
Validate before access ends. “We ran the export” is not done. “We searched the archive, opened a known record in full context, and a compliance reviewer signed off” is, and it only works while the source is still live to check against.
Common mistakes to avoid
-
Burying the data in the migration plan, where it becomes a single bullet nobody owns.
-
Calling a CSV export “archived.” A spreadsheet of values is not a record.
-
Keeping the old platform alive “just in case” — an open-ended bill for the system you are trying to leave.
-
Validating in the final week. Once the TSA expires, there is no source left to check the archive against.
Definition of done
The workstream is finished when one statement is true:
The divested entity holds its own complete historical ITSM record, intact and searchable, inside its own infrastructure, confirmed by a compliance reviewer to answer audit questions without access to the parent’s systems.
Until that is true, the exit is not done, no matter what the migration tracker says.
That is what Cortex Archive is built to deliver on a TSA timeline. It rebuilds a familiar, read-only view of the old platform from its own database, inside your own network, so the workstream ends with a record you own instead of a file share you hope is complete. Same approach whether the source is Cherwell, ServiceNow, Ivanti Neurons, or Jira.
The window is plenty, if the data is a workstream from day one. It is nowhere near enough if you discover it in the final stretch, after the cutover work has eaten the calendar.
Frequently Asked Questions
What is a TSA exit in a divestiture?
A Transition Services Agreement is a short-term arrangement where the parent company keeps providing certain services to the divested company while it builds its own systems. A TSA exit is the project of standing those systems up and ending the dependency before the agreement expires. TSAs typically run 12 to 18 months, though access to a specific system like the ITSM platform often ends sooner. Access to the parent’s platforms, including the ITSM system, typically ends when the TSA does.
Why does legacy ITSM data need its own workstream?
Because it falls between the cracks of the migration plan, which covers live operations: active users, open tickets, current CMDB. The historical record of closed incidents, changes, and attachments is not part of standing up the new platform, so it goes unowned unless it is broken out as a separate workstream with a named owner and its own definition of done.
Can we just export the data to CSV before the TSA ends?
You get one pass at the source, so a flat export is a risky way to spend it. CSV strips the links, attachments, and form context that make a record auditable, and you cannot go back for what you missed once access is cut. Preserving the full record while the source is still live is the safer use of the window.
What is the definition of done for the workstream?
On the day the TSA ends, the divested company can answer an auditor’s question about a years-old record, in full context, without logging into the parent’s systems. If it can, the workstream is done. If it cannot, the gap is now permanent and far more expensive to fix.
Related reading
-
Who Owns the Ticket History After a Divestiture? — the ownership question behind this workstream
-
Carve-Out and Spin-Off ITSM Archive Checklist — the full separation checklist
-
CSV Export vs. Purpose-Built Archive — why one export pass should not be a flat file
-
Cherwell EOL Data Retention: Audit-Readiness Guide for Public Companies — the obligations that outlive the TSA
When a TSA clock is running, Cortex Archive rebuilds a read-only copy of the legacy ITSM platform inside the divested company’s own network, so the exit ends with a complete, searchable, audit-ready record it controls.