How to inventory data after an acquisition.

The first ninety days are a preservation window. They are not a cleanup window.

An acquisition closes. The purchase agreement is signed. The integration plan lands on a shared drive. Meanwhile the data that came with the deal sits on aging hypervisors, in orphaned SaaS tenants, on external drives in a former employee’s closet, and in backup tapes no one has cataloged since 2018.

The instinct is to migrate, consolidate, or delete. The discipline is to inventory first. Every system, every custodian, every provenance thread must be recorded before the decommissioning calendar takes over. This article walks the field steps for the first thirty to ninety days.

Locate the dormant archives before they disappear.

Data hides in predictable places. The list below is a starting point for the discovery sweep. Treat it as a living document. Add entries as custodians surface new locations.

• On-premises file shares and application servers that predate the current directory structure.
• Virtual machine images stored on hypervisor datastores or copied to cold storage.
• Database backups retained by the previous DBA team under separate retention policies.
• SaaS exports: CRM, ERP, marketing automation, ticketing, HRIS, and any shadow IT tools purchased by business units.
• Cloud object buckets created for one-time migrations and never deleted.
• Email archives: journal mailboxes, PST collections, and e-discovery exports held by legal.
• Developer artifacts: Git repositories, CI/CD artifact stores, container registries, and package feeds.
• Ex-employee endpoints: laptops, external SSDs, personal cloud sync folders, and mobile device backups.
• Physical media: LTO tapes, optical disks, and encrypted drives stored in offsite vaults.
• Third-party data rooms used during due diligence that were never closed out.

For each location, record the system name, the hosting environment, the access path, the credential holder, and the last known write date. That record becomes the first row in your data inventory.

Build the custodian register before the org chart changes.

People are the primary metadata layer. When a system owner leaves, the context leaves with them. The custodian register captures who knows what, while they are still reachable.

Create a register with these fields:

Field	Purpose
Custodian name	Legal name and preferred contact.
Current role	Title at time of interview.
Former role	Title at acquired entity.
Systems owned	List of systems, databases, or SaaS tenants they administered.
Data domains	Business domains they can speak to (billing, clinical, telemetry, etc.).
Access status	Active, suspended, revoked, unknown.
Interview status	Not started, scheduled, completed, follow-up needed.
Key artifacts	Exports, diagrams, runbooks, credential vaults they control.
Provenance notes	Oral history: why a schema exists, what a column means, where a feed originated.
Freeze authority	Whether they can authorize a write freeze on their systems.

Schedule interviews in batches. Prioritize custodians of systems slated for decommissioning within sixty days. Record the interview date, attendees, and a summary in the register. Store the register in a controlled location with version history. This register feeds the rights and provenance register later.

Classify by system, not by business unit.

Business units reorganize. Systems persist. Classification by system yields a stable framework for inventory, deduplication, and eventual licensing decisions.

For each discovered system, capture:

• System identifier (internal name, vendor product, version).
• Deployment model (on-prem, hosted, SaaS, hybrid).
• Data categories (transactional, analytical, reference, log, backup, archive).
• Volume estimate (row counts, file counts, storage footprint).
• Retention policy reference (policy ID or document link).
• Known PII fields (column or attribute level).
• Integration points (upstream feeds, downstream consumers, APIs).
• License status (perpetual, subscription, expired, unknown).
• Decommissioning date (planned or actual).
• Custodian reference (link to register entry).

Group systems into families: ERP, CRM, BI, telemetry, document management, legacy custom applications. This taxonomy drives the sampling plan for metadata recovery and deduplication. It also informs the dataset preparation scope when licensing becomes a topic.

Freeze writes before you snapshot.

A snapshot of a live system is a moving target. The freeze protocol is simple: stop writes, verify quiescence, then capture.

1. Identify the system owner and the change control board.
2. Request a write freeze with a documented effective timestamp.
3. Confirm application services are stopped or placed in read-only mode.
4. Verify replication and backup jobs have completed their last cycle.
5. Capture the manifest: file list, database row counts, schema version, checksum set.
6. Record the freeze authorization, timestamp, and verifier in the provenance register.
7. Store the manifest alongside the inventory.

Do not skip step six. The provenance register is the evidentiary backbone. It answers “who said we could stop writes” and “what did the system look like at that moment.” Without it, the inventory is hearsay.

Capture metadata while the schema is still legible.

Metadata recovery is time-sensitive. Data dictionaries rot. ER diagrams go stale. Tribal knowledge evaporates.

For each prioritized system:

• Export the information schema (tables, columns, data types, constraints, indexes).
• Extract the data dictionary if one exists in the application layer.
• Pull the ETL or ELT lineage: source tables, transformation logic, target tables.
• Collect sample rows (top one hundred by primary key, plus a random stratified sample).
• Document enum value mappings and code tables.
• Note any encrypted or tokenized fields and the key management system.

Package these artifacts into a sample manifest. The manifest lists each artifact, its source system, the extraction date, the extractor, and a hash. This manifest travels with the inventory and supports later review by legal, privacy, and commercial teams.

Deduplicate at the inventory layer, not the storage layer.

Deduplication at the storage tier hides provenance. At the inventory tier, it clarifies scope.

Compare manifests across systems using:

• File hashes for identical exports.
• Row count and schema fingerprint for database dumps.
• Column profile overlap (name, type, cardinality, null rate).
• Known key columns (customer ID, transaction ID, device ID).

Record duplicate groups in the inventory. Note the canonical source system and the derivative copies. This mapping prevents double-counting in any future valuation and preserves the chain of custody for each copy.

Record the decommissioning evidence before the kill switch.

Every system that will be shut down leaves a trail. Capture it while the system still runs.

• Final backup verification report.
• Last successful restore test date.
• Data retention schedule cross-reference (what must be kept, for how long, in what jurisdiction).
• Regulatory hold notices that apply to the system.
• Contractual obligations to third parties (data processors, joint controllers, licensors).
• Export of audit logs for the final ninety days.
• Signed decommissioning authorization from the data steward and legal.

File this evidence in the provenance register. It is the last word on what existed, what was preserved, and what was lawfully destroyed.

Checklist: First ninety days inventory sprint.

• Initiate discovery sweep using the location list above.
• Populate the custodian register; schedule interviews for top twenty systems.
• Classify all discovered systems by the system taxonomy.
• Issue write freeze requests for systems with decommissioning dates within sixty days.
• Capture manifests and metadata exports for frozen systems.
• Build sample manifests for each system family.
• Run deduplication comparison across manifests; log duplicate groups.
• Collect decommissioning evidence for each system on the shutdown calendar.
• Consolidate inventory, register, manifests, and evidence into the review package.
• Run a readiness check to confirm the package is complete for stakeholder review.

The inventory is the foundation. The review is the decision point.

You now have a documented, reviewable data asset set: an inventory, a custodian register, a provenance register, sample manifests, and a deduplication map. Licensing is a separate conversation. The work to this point is procedural, auditable, and reversible.

When the integration team asks what data came with the acquisition, you hand them the package. When privacy counsel asks what personal data exists, you point to the PII mapping in the inventory. When the commercial team asks what can be licensed, you show them the rights and provenance register.

Start the review with a structured brief. Request a readiness review at /accession/.