Systems and records
IT due diligence: system inventory and data history checklist for acquisitions
By SourceX Editorial · Updated
Short answer
An IT due diligence checklist for an acquisition should record, for every system the target runs, its owner, plan, depth of history, export path, contract terms and data rights. Standard IT diligence covers security, cost and integration; adding history and rights shows whether the target's records survive the deal and can be used, migrated or licensed.
Key takeaways
- List every system that holds records, including retired ones and archives, not only those in the current IT budget.
- History depth means what can still be exported today, not how long the company has used the system.
- Vendor terms decide export routes, access after termination and whether an account can be transferred.
- Data rights diligence asks where records came from, what customers agreed to and whether any data is already licensed.
- Findings belong in the integration plan, with renewal and termination dates on one calendar.
What the system inventory should capture#
The system inventory should capture seven facts for each system: system name, business owner, plan, history depth, export path, contract terms and data rights. Those seven columns turn a list of software into a view of which records the target actually controls.
Use the same columns for every target in a buy-and-build program, so findings can be compared across deals and rolled into one post-close plan.
| Column | What to record | Red flag |
|---|---|---|
| System | Product, edition, hosting and the records it holds | Business-critical records in a tool nobody listed |
| Business owner | Who uses it daily and who administers it | Admin rights held by a departing founder or contractor |
| Plan | Subscription tier, seats, renewal date and notice period | Auto-renewal shortly after the expected close |
| History depth | Earliest record still exportable, and any gaps | History lost in a past migration or purged by a retention setting |
| Export path | Report export, API, bulk export or database access | No tested route for full history |
| Contract terms | Data ownership, post-termination access, deletion, assignment | Account cannot be assigned in an asset deal |
| Data rights | Whose data it is and what use is permitted | Customer data used beyond what contracts allow |
Which systems belong on the list?#
Every system that holds business records belongs on the list, including those the target no longer pays for. Targets tend to report the systems in the current IT budget, while useful history often sits in a retired helpdesk, an old ERP database on an office server or a founder's personal cloud account.
- Finance and operations: ERP, accounting, billing, inventory and warehouse systems.
- Customer-facing: CRM, helpdesk, chat, call recording and customer portals.
- Delivery: field service, dispatch, project management, TMS and WMS.
- Engineering: code repositories, issue trackers, build pipelines and incident tools.
- Knowledge: wikis, shared drives, email and team chat, with their retention settings.
- People: HR, payroll and applicant tracking, which carry the most personal data.
- Retired systems, backups, data warehouses and spreadsheets that run real processes.
Data history: questions standard IT diligence skips#
Data history diligence asks how much of the past is still retrievable and in what shape. A target that says it has run its helpdesk for many years may hold far less, because an earlier migration kept only open tickets or a retention rule deletes old chat messages.
Ask for the earliest exportable record in each core system, how past migrations were handled and whether backups can be restored without the original software. Test one export route on one or two core systems before signing, even with a small sample, because export paths that exist on paper often fail on volume or attachments.
Record the answers as facts with dates and sources, not as management impressions. They will drive the post-close archive plan and any later discussion of what the records are worth.
| Vendor behavior to check | What the documentation says | Diligence question |
|---|---|---|
| Helpdesk deletion schedules | Zendesk admins can set ticket deletion schedules that delete archived tickets; deleted tickets cannot be restored | Is any deletion schedule active, and since when? |
| Plan-gated exports | Zendesk's account export tools are not available on Team plans, though the REST API works on every plan | Does the target's plan include the export route you are counting on? |
| Deletion after cancellation | Smartsheet says paid Pro and Business data is permanently deleted 30 days after cancellation takes effect | Has any tool with history been cancelled or downgraded recently? |
| Exports that are not backups | GitLab says project export files should not be used as backups, and after export only the latest merge request diff version is visible | Is the code history held anywhere other than a project export? |
Data rights checklist: provenance, consent and restrictions#
Data rights diligence checks whether the target can use, move and license the records it holds. The Data & Trust Alliance's Data Provenance Standards, written to support dataset selection for AI model training, group dataset metadata into Source, Provenance and Use, and the Use group covers items such as consent documentation location, license to use and intended data use. Those headings make a practical frame for an acquirer's questions.
Request documents rather than summaries. A clause in one customer master agreement can decide whether a whole record family is usable after close.
| Check | Documents to request | Why it matters |
|---|---|---|
| Provenance | System inventory, migration history, data flow diagrams | Shows where records came from and whether they are complete |
| Customer contracts | Master agreements, data processing terms, confidentiality clauses | May limit use of customer data or require deletion at term end |
| Vendor terms | Subscription agreements and order forms for core systems | Set export routes, post-termination access and assignment |
| Privacy notices and consents | Current and past notices, consent records, opt-out logs | Govern what personal data may be used for |
| Personal data handling | Data map, retention schedule, de-identification practice | Drives the preparation effort for any reuse |
| Prior data licenses | Data sharing, licensing or exclusivity agreements | Existing exclusivity can block future licensing |
| Third-party content | Open-source policies, client deliverables, licensed content | Records the target holds but does not own |
Running the checklist inside a deal timeline#
The checklist fits a deal timeline when it is split into a data room request, structured interviews and a short list of tests. Keep requests specific so the seller's small IT team can answer without hiring a consultant.
- Data room: system list with plans and renewal dates, core vendor agreements, privacy notices and any data licenses.
- Interviews: the person who administers each core system, not only the founder or IT head.
- Tests: one sample export from the ERP or CRM and one from the helpdesk or code host.
- Legal review: assignment and change-of-control clauses in vendor and customer contracts.
- Output: a findings table with severity, owner and a pre-close or post-close action.
Illustrative: a platform company reviews an industrial distributor#
Illustrative: a fictional lower-middle-market fund's distribution platform is acquiring a regional industrial distributor. The standard IT review covers security and software costs. The operating partner adds the history and rights columns.
The inventory finds that order history from before a past ERP switch survives only as a database backup that needs the old software to read, the helpdesk plan limits bulk export, and the CRM runs on an account registered to the founder personally. Customer contracts include confidentiality clauses that cover order data.
The fund adds an export of the legacy database and a transfer of the CRM account to the closing deliverables, and schedules a helpdesk export before renewal. After close, the integration team works from complete history, and a later review of licensing options starts with the rights already mapped.
Turning findings into a post-close plan#
Diligence findings become a post-close plan when every system has a decision, an owner and a date tied to its contract. Put renewal dates, notice periods and post-termination access windows on one calendar, because the first system retirement often arrives before integration planning is finished.
Default to archiving before migrating. A complete, owner-controlled export of each core system protects history whatever the integration plan becomes, and it gives the value creation team a clean starting point for any data initiative.
How SourceX connects to data diligence#
The SourceX Evidence Packet uses five headings, provenance, licensing rights, permitted use, the privacy record and release authorization, that map closely to the rights columns of this checklist. A portfolio company that completes the checklist during diligence already holds most of the inputs a licensing review needs.
SourceX does not take part in the acquisition itself. After close, each portfolio company can run a metadata-only fit check, and any package follows the SourceX five-step transaction, with the portfolio company's own signer approving every step.
Frequently asked questions
Who should fill in the system inventory?
The seller's IT lead or controller drafts it, and the buyer's advisor verifies it through interviews and tests. Sellers know where systems are; buyers know which answers matter. A shared template with fixed columns keeps the work fast and comparable across targets in a buy-and-build program.
Should data rights sit in the IT or the legal workstream?
Both, with a clear handoff. IT identifies which systems hold which records and how they flow; legal reviews the contracts, notices and licenses that govern them. One findings table, owned jointly, keeps rights questions from falling between the two workstreams.
Does a SOC 2 report answer these questions?
No. A SOC 2 report describes a service organization's controls over areas such as security and availability, either at a point in time (Type 1) or over a period (Type 2). It does not show how much history exists, whether exports work or what customers agreed to about data use. Treat it as one input to security diligence.
What if the target's history sits with a former parent company?
Carve-outs often leave records in the parent's systems. Write access to historical records, export assistance and retention into the transition services agreement, with dates, and confirm the parent's own vendor terms allow the handover.
Is AI training use now a diligence item?
It is worth checking. Some customer contracts and vendor terms now address AI training or analytics use directly, and some targets have already shared or licensed data. Both affect what the acquirer can do with the records after close.
Sources
- Zendesk admins can create ticket deletion schedules that delete archived tickets after a set period; deleted tickets cannot be restored. Source
- Zendesk's account data export tools are not available on Team plans, but customers on every plan can export data through the Zendesk REST API. Source
- When a paid Smartsheet Pro or Business plan is canceled, all data is permanently deleted 30 days after the cancellation's effective date. Source
- GitLab says project export files should not be used to back up data, and after import or export only the latest diff version and latest pipeline in merge requests are visible. Source
- The Data & Trust Alliance's Data Provenance Standards (version 1.0.0 specification) define dataset metadata in three groups: Source, Provenance and Use, and say this metadata is needed to enable proper dataset selection for AI model training. Source
- The Use group of the Data Provenance Standards includes elements for confidentiality classification, consent documentation location, privacy-enhancing technologies applied, license to use, intended data use, and copyright, patent and trademark status. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.