Exit prep: documenting your systems and data history for buyers

What belongs in the systems section of a data room?#

The systems section of a data room should hold five things: a register of every system that stores company records, a history map showing how those records moved over time, proof that each history can be exported, the vendor terms that govern each system, and a rights file for the data itself. Together they let a buyer judge the records without logging in to anything.

Most sell-side data rooms already cover IT security, software licenses and infrastructure cost. What they usually miss is history. A buyer planning integrations, an AI roadmap or a data license wants to know whether years of tickets, deals or job records still exist in usable form, and that question rarely has an owner inside the company.

How do you build a system register buyers will trust?#

A trustworthy system register lists every system that holds records, not only the ones IT pays for. Shadow tools matter: a sales team's old HubSpot portal, a shared drive of estimates, or a retired on-premise ERP still running on a server nobody wants to switch off.

Build the register from three sources and reconcile them: accounts payable for paid subscriptions, single sign-on or identity logs for active apps, and short interviews with department heads for everything else. Record unknowns as unknown. A buyer forgives a blank field more readily than a confident answer that diligence later disproves.

• 1System name, vendor and product edition or plan tier.
• 2Business owner and every current administrator, listed by role rather than personal email.
• 3Record types held, such as tickets, deals, jobs, invoices, issues or drawings.
• 4Earliest record date still retrievable, checked inside the system rather than remembered.
• 5Integrations that copy data in or out, and which system is the system of record.
• 6Contract term, renewal date, notice period and what happens to data on cancellation.
• 7Export route: built-in export, API, vendor service request or database backup.

Mapping data history: migrations, gaps and legacy archives#

A history map is a timeline of where each record family lived and when it moved. It shows, for example, that support tickets sat in one help desk until a migration, that only open tickets were carried over, and that the earlier closed tickets survive as a JSON archive on a file server.

Write down what each migration dropped. Common losses include attachments, internal notes, field history, call recordings and the links between records, such as a ticket's link to the engineering issue that fixed it. HubSpot is a common case. Its knowledge base says a record export carries each record's current property values and its associations, while calls, notes and other activities come out through a different method. An archive made only from record exports can therefore lack the conversations behind the deals.

Then check what is deleting history today. Zendesk admins can set up ticket deletion schedules that remove archived tickets once they reach a chosen age, and Zendesk cannot restore tickets deleted this way. Settings like that are easy to forget and painful to discover in the middle of diligence.

Which data rights questions will buyers ask?#

Buyers ask data rights questions because records the company cannot use freely are worth less to them. The rights file should let the buyer's counsel answer each question by opening a document instead of sending another information request.

Vendor terms deserve a careful read because they change. When HubSpot updated its Developer Terms, its changelog said they limit AI and machine learning training on data pulled through its APIs, apart from legitimate single-customer uses, and that customer data belongs to the customer rather than to HubSpot or app developers. Counsel on the other side will want to see that the company read the version that applies to it.

Pre-exit IT cleanup that helps rather than hurts#

Pre-exit IT cleanup should make records easier to verify, not smaller. The instinct to delete old data before a sale can destroy history a buyer values, and it can cause real problems if any records are subject to a legal hold, a pending dispute or a customer contract that requires them to be kept.

• 1Do move admin rights from departed employees to role-based accounts the company controls.
• 2Do run and log a test export from every core system, noting the format and what came out.
• 3Do document retention and deletion settings as they stand, with screenshots and dates.
• 4Do consolidate scattered archives into one documented location with a simple index.
• 5Do not shorten retention periods or run bulk deletions until counsel has reviewed holds and contracts.
• 6Do not cancel a legacy subscription until its history has been exported and checked.
• 7Do not describe history as complete when a migration dropped fields or attachments.

Illustrative: a vertical software company prepares its systems folder#

Illustrative: a fictional maker of scheduling software for landscaping contractors is preparing for a sale run by its private equity owner. Its records sit in Jira, GitHub, Zendesk and HubSpot, plus a Salesforce org the company left during an earlier CRM migration.

The operating partner asks the CTO to build the history map first. It shows that the Salesforce org still holds early deal history on a single remaining admin license, that the help desk migration carried closed tickets but not their attachments, and that an admin had switched on a Zendesk deletion schedule for archived tickets during a cost review. Counsel reviews the schedule and the company pauses it while the sale process runs.

The result is a systems folder that answers the buyer's first round of IT questions without follow-up calls. The rights file shows no existing data licenses and no exclusivity, and the history map explains the attachment gap in a short note instead of leaving it to be found.

How SourceX connects to exit preparation#

SourceX helps companies understand and license their operational records, and the documentation it relies on overlaps with a good systems folder. Each package that moves through the SourceX five-step transaction, Supply, Rights, Preparation, Approval and Delivery, is documented in a SourceX Evidence Packet covering provenance, licensing rights, permitted use, the privacy record and release authorization.

For a company preparing for sale, that means any data license signed before exit is recorded in the terms a buyer's counsel will ask about. The initial fit check uses metadata only, such as system names, years of history and record types, so nothing is shared while the owners decide whether licensing belongs in the exit plan at all.