IT due diligence questions about data exports and history depth

Why history depth needs its own diligence questions#

History depth needs its own diligence questions because a target's age, its system list and its retrievable records are three different measures. A company founded decades ago may hold only a short run of usable order history after an ERP migration, while a younger company on a single help desk may have every ticket since its first customer.

Depth matters for integration, reporting, AI projects and any later decision to license operational records. Acquirers who learn the true depth after closing often find that a legacy server, a lapsed subscription or an auto-delete setting had already decided the answer for them.

Map the systems of record first#

A systems of record map lists, for each business function, the system that holds the authoritative history and the date that history begins. Ask the target to fill it in as a table rather than describe it on a slide, because gaps in the date column are the first sign of lost history.

Include systems inherited from earlier add-on acquisitions, even if no one uses them day to day. Acquired businesses often keep a legacy instance running for reference, and it rarely appears on the main IT asset list or in the budget.

Retention settings that quietly delete history#

Retention settings are configuration choices that delete or archive records automatically, and they are often set once and forgotten. Ask which of the following exist in each system and when each was last changed.

Request screenshots or exports of the actual settings, not the policy document. A written policy that says records are kept for many years means little if the mail system purges messages much sooner.

Settings are often split in ways a policy document hides. Microsoft Purview, for example, treats Teams channel messages and Teams chats as separate retention policy locations, so chat history can follow a different rule from channel history. Samsara lets customers set camera retention from 3 days to 4 years, with defaults that depend on region and sign-up date, so check the account's actual setting rather than assuming the default.

• 1Mail and chat retention policies that purge messages after a set period.
• 2Help desk archiving rules that move or delete closed tickets.
• 3CRM storage limits that pushed teams to delete old activities or attachments.
• 4Plan tiers that cap how far back history or audit logs remain visible.
• 5Backup rotation schemes that overwrite older copies.
• 6Legal holds that override deletion for some mailboxes or matters.

Export capability: how the records actually come out#

Export capability decides whether history that exists can be used outside the system, and it varies sharply by route. The same help desk can produce a rich, linked dataset through its API and a flat, lossy spreadsheet through its reporting screen.

Ask who has run each route, when and with what result. A target that has never exported its own data is assuming a capability it has not tested.

Years of history versus years you can use#

Years of history and years you can use differ because migrations, truncated imports and broken links reduce usable depth. Ask the target to state, for each system, the years held, the years exportable and the years in which records still link across systems, such as tickets to accounts or jobs to invoices.

Legacy systems deserve their own line in the answer. An old ERP on a server in a back room, a read-only help desk instance or backup files from a retired system may hold the deepest history in the company, and their support contracts or hardware may be close to failing.

Vendor lock-in and post-termination access#

Vendor lock-in, in data terms, means the contract, file format or cost makes history hard to retrieve once the relationship changes. Review data return clauses, post-termination access, proprietary formats and any fees for exports or archived instances.

Many SaaS contracts give only a limited window to retrieve data after termination, so check each agreement and the vendor's documentation rather than assuming access continues. Flag every system the integration plan intends to retire, because retirement is when history is most often lost.

Licenses for the software itself matter as well. A perpetual license for an on-premises system may not transfer to a new owner without consent, and some vendors charge to reactivate an archived instance. Ask for the license agreements, not just the invoices.

Illustrative: a 3PL target with two warehouse systems#

Illustrative: a fictional private equity platform is acquiring a regional 3PL that moved to a new warehouse management system some years before the deal. The portfolio CIO's questions show that only open orders and recent history were migrated.

The older order, inventory adjustment and exception history sits in the legacy WMS, still running on an on-premises server under a support contract about to lapse. The deal team obtains a pre-closing commitment from the seller to keep the server running, and the integration plan includes a full database export with a data dictionary before the server is retired.

After closing, the preserved history supports exception analytics across both systems and, later, a metadata-only fit check on licensing the de-identified exception records.

How SourceX uses a diligence systems inventory#

SourceX uses the same kind of systems inventory at the Supply step of the SourceX five-step transaction. System names, date coverage, record families and export routes are metadata, so a fit check can run on them without any files being shared.

Large archives stay in the company's own storage or ship on encrypted drives, because SourceX never hosts multi-terabyte datasets. A CIO who documents export routes and data dictionaries during diligence has already done much of the preparation any later licensing work depends on.