Why an acquisition needs a data catalog before consolidation starts
An acquirer that inherits a target with a poorly documented data estate faces a deal timeline that will not wait for the documentation to catch up. A self-hosted OpenMetadata or DataHub instance, deployed inside the acquirer's or the target's controlled environment, gives a discovery inventory with named owners, lineage and personal data flags before any migration or system consolidation begins. Both platforms are licensed under Apache-2.0, so the cost question shifts from licensing to infrastructure, connector setup and steward time. The catalog is an evidence and planning tool, not a migration tool. It tells the integration team what exists, who answers for it, where it flows and where personal data sits, so that decisions about which systems to retire, merge or keep are based on recorded facts rather than interview notes.
Start with three questions the catalog must answer for the target before anyone plans a cutover: which systems hold data that feeds financial reporting or regulated processes, which datasets have an identifiable owner, and which tables or columns carry personal data. OpenMetadata's connector library covers warehouses, BI tools and pipelines, and its lineage supports tables, columns, dashboards and pipelines through OpenLineage events, which lets the team trace a report back to its sources. Confirm with the chosen platform's documentation which connectors the target's actual systems need, because connector coverage determines how much of the estate is discovered automatically and how much must be catalogued by hand.
Deployment location matters as much as the platform choice. Target data often cannot leave its current jurisdiction or contractual boundary during due diligence, and the catalog's own metadata can contain sensitive detail such as column names, sample values and owner contacts. Decide early where the instance runs, who holds administrator rights, and whether the acquirer's staff may read target metadata before the deal closes. Those decisions, and the sizing and database prerequisites in the platform's bare metal or Kubernetes deployment guides, should be written into the scope before the discovery work starts.
Which regulations and controls shape the acquisition inventory
This table maps each regulation or control in the supplied research to what it asks of an acquisition inventory and which catalog fields it affects. Read each row as a scope decision: what must be discovered, owned and documented before consolidation work begins. The main takeaway is that the inventory serves several audiences at once, so the catalog needs fields for financial reporting, third-party risk, personal data and transfers from day one.
| Requirement or control | What it means for inventory scope | Catalog fields to capture |
|---|---|---|
| SEC ICFR treatment of an acquired business | Management may exclude a newly acquired business from its internal control assessment for up to one year and no more than one annual report. The exclusion and its significance must be disclosed, so the inventory must identify which financial data flows belong to the acquired entity. | Acquired entity tag, acquisition date, financial reporting relevance, owner, exclusion status |
| SEC Release 33-8810 IT general control areas | Program development, program changes, computer operations and access to programs and data are the example areas. Only systems that feed financial reporting risks need evaluation, so the inventory should flag those first. | System category, financial reporting flag, change owner, access owner, operations owner |
| NIS2 Article 3(4) notification | Entities must give their competent authority their name, contact details, IP ranges, sector and service Member States, and report changes within two weeks. Post-deal changes to these facts must be traceable to the inventory. | Legal entity, contact owner, IP ranges, sector, Member States served, change date |
| DORA Article 28(3) register of ICT arrangements | Financial entities must keep a register of all ICT service arrangements at entity, sub-consolidated and consolidated levels. Acquired ICT contracts and providers need to be merged into that register before consolidation. | Provider, contract reference, service supported, entity level, critical or important function flag |
| DORA Article 28(8) exit strategies | Services supporting critical or important functions need tested exit strategies and transition plans. The inventory should show dependencies that would make migration of acquired services harder. | Upstream and downstream dependencies, lineage to critical functions, exit plan reference |
| EU Data Act switching rules | Data processing providers must support switching to another provider or on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, no switching charges apply. Inventory exportable data and contract switching terms for every hosted acquired service. | Hosting provider, exportable data sets, notice terms, transitional period, switching charge status |
| EDPB Guidelines 05/2021 on remote access | Remote access to EU personal data from a third country, including for support or administration, counts as a transfer. Acquirer staff outside the EEA who can view target systems need a Chapter V transfer tool, so the inventory should record access locations. | Personal data flag, access locations, staff or group access, transfer tool reference |
| GDPR Articles 28 and 30 | Processors act only on documented controller instructions, including for transfers. Records of processing must describe Article 32 security measures where possible, so acquired processing activities and their processors need to be catalogued and linked to records. | Controller and processor names, processing purpose, data categories, Article 32 measures, transfer destinations |
| 45 CFR 164.314(a) HIPAA business associate terms | Business associate contracts must require Security Rule compliance, flow terms down to subcontractors handling ePHI and report security incidents. The inventory should identify which acquired vendors handle ePHI and whether those contracts contain the required terms. | Business associate flag, subcontractor chain, ePHI system tag, contract term reference, incident contact |
Which systems and datasets an acquired company's catalog must cover
The catalog has to cover every system that produces or transforms data the combined company will rely on, and the first list is almost never complete. An acquired company's estate usually includes an ERP and finance ledgers that feed reports relevant to internal control over financial reporting, customer and claims databases, a warehouse with BI tools on top, pipelines moving data between them, shared drives full of exports, SaaS tools with their own reporting, and shadow spreadsheets that a few people maintain by hand and that quietly feed board packs. Start by agreeing with the target's finance and risk leads which reports matter most for the deal and which systems sit upstream of them, then scan for everything else. Discovery should capture system owner, technical owner and business owner for each dataset, because a dataset without a named owner cannot be scoped, classified or retired safely.
The hardest work is rarely the connectors. It is owner assignment and definition mapping. Two companies can both report an active customer and mean different things, one counting any account with a login in ninety days and the other counting paying subscribers. A catalog can show both definitions side by side, link each to the tables and dashboards that use it, and record which business owner signed off. Build that glossary before anyone merges tables, because a silent merge of two definitions produces numbers that look correct and are not comparable. Confirm with the target's controllers how they document these definitions today, since that record often exists only in people's heads or in a spreadsheet.
Lineage into consolidated reporting matters before any system is retired. A legacy ledger or reporting tool may look redundant, yet it may be the only place where a figure in an acquired entity's close process is derived. Column-level lineage from source to report lets the integration team see which fields and transformations would break if a system were switched off, and it gives auditors a traceable path if a control depends on that figure. Confirm early which lineage the target's pipelines can emit, whether through built-in connectors or the OpenLineage events that OpenMetadata supports, and which pipelines will need manual documentation instead. Treat any system with no traceable lineage as blocked for retirement until someone has explained its outputs.
Which open source catalogs fit an M&A inventory and why
An acquisition inventory needs a catalog that can be stood up quickly inside the buyer's or target's environment, read connectors and lineage from the systems the target actually runs, and record owners and personal data tags. The cards below cover the two metadata catalogs that fit this work, the pipeline tools that feed lineage, and the checks to run before choosing.
OpenMetadata for mixed estates
OpenMetadata is Apache-2.0 licensed and lists more than 130 connectors for warehouses, BI tools, pipelines and ML platforms, which matters when an acquired company runs systems the buyer has never seen. It records table, column, dashboard, pipeline and metric lineage, with OpenLineage event integration, plus classifications, glossaries and domains that help map overlapping definitions. Confirm that each connector the target uses is supported at the version it runs, and test a read-only metadata account against one system first. The latest release supplied is 2.0.5, published October 8, 2026.
DataHub as the alternative catalog
DataHub is also Apache-2.0 licensed and is a fit when the buyer already runs a metadata graph or wants a catalog with a strong developer API surface. Its metadata model and ingestion framework can cover the target's sources, but coverage differs by connector, so the team should compare each source type against the target's inventory before committing. Ask who will operate the search and graph backends after handover. The version supplied is v1.7.0.1, published September 3, 2026.
Airflow and Dagster for pipeline lineage
Pipeline lineage often lives in the orchestrator rather than the warehouse. Apache Airflow (Apache-2.0) and Dagster (Apache-2.0) define which jobs move data between systems, so their metadata shows where an acquired dataset is produced and consumed. Neither replaces the catalog, but connecting them to the catalog gives the integration team a view of dependencies before consolidation. Check whether the target's DAGs or assets are versioned, and whether job names map to business owners.
CKAN only for a published portal
CKAN is the right choice only when the goal is a published open data portal, not an internal inventory of an acquired company's systems. An M&A inventory is about discovering internal assets, owners and personal data, which a governance catalog handles better. If the buyer later needs to publish selected datasets to the public, CKAN can be considered for that separate purpose. Confirm the publication goal in writing before the project scope is fixed.
Confirm the target's connector list
Before selecting a catalog, request the target's system inventory, including database engines, BI tools, orchestrators, file stores and SaaS applications, along with versions and hosting locations. Compare that list with the connectors each candidate supports, and record gaps as manual inventory tasks. Unsupported systems still need owners and personal data classification, so plan a spreadsheet fallback. Ask the target to confirm which systems are contractually restricted from metadata extraction.
Deployment constraints when the target sits in another jurisdiction
The catalog itself is a set of personal data pointers. Table names, column descriptions, sample values, owners and lineage can reveal where customer records live and how they move, so the catalog should be treated as a system that is in scope for the same transfer and sovereignty analysis as the systems it describes. Under EDPB Guidelines 05/2021, remote access to EU personal data from a third country, including for support or administration, counts as a transfer. If a non-EEA acquirer's staff can log in to a catalog that profiles EU target systems, that access needs a Chapter V transfer tool before it is granted. Decide where the catalog will be hosted, which tenant or namespace holds the target's metadata, and who in the acquirer may view it before any cross-border sharing begins. Scope read access to named roles, and keep sample data and profiling output out of shared views unless the transfer position has been documented.
Hosting the catalog in the target's own infrastructure or in an EU-controlled account keeps that decision simple. For OpenMetadata, the bare metal deployment documentation lists Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. The documented minimum for the server is 2 vCPUs and 4 GB RAM, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. These are floors, not production sizing, and the size of the target's estate will drive the real figures. OpenMetadata also documents production deployments on Kubernetes, including AWS EKS, Azure AKS, Google GKE and on-premises clusters, so the choice between cluster and bare metal should follow the target's existing platform team and hosting contracts.
Before go-live, confirm the network segmentation with the target's security team. Check that the catalog, its database and its search cluster sit in a segment reachable only from the discovery connectors and approved administrators, that outbound traffic is restricted, and that any federated login or identity provider trust is documented and limited to the people named in the access scope. Confirm which logs record catalog access and who reviews them, because those logs become evidence if a supervisor or data protection authority asks who viewed target personal data. Ask your implementation partner to write these controls into the deployment design and to show them working in a test environment before any acquirer user is onboarded.
How the discovery inventory is rolled out in phases
The sequence moves from agreed legal boundaries to an isolated catalog, then to the highest-risk systems, ownership, personal data review and lineage, and ends with a register the acquirer can keep after integration. Each phase closes with a named output so that consolidation decisions rest on evidence rather than on assumptions.
Scope systems and set legal boundaries
Counsel, the target's data protection lead and the acquirer's security and integration leads agree which entities, systems, jurisdictions and data categories are in scope before any connection is made. This step also records what the acquirer may access before closing, because remote access to EU personal data from a non-EEA party can count as a transfer that needs a transfer tool. The output is a signed scope note listing in-scope systems, permitted access levels, and the named owner for each legal question. Confirm the boundary with counsel for each jurisdiction involved.
Deploy an isolated catalog environment
DeployOpen's team installs OpenMetadata or DataHub in an environment that the target's and acquirer's production networks cannot reach by default, usually within the target's cloud account or data center so metadata stays under the controlling party's control. The team configures single sign-on, role-based access and audit logging for the catalog itself, and confirms the database and search prerequisites documented for the chosen platform. The output is a tested, access-controlled instance with a documented architecture and an access list approved by the scope owner.
Onboard connectors for highest-risk systems first
The team connects metadata sources in order of risk, starting with systems that hold regulated financial, health, payment or customer personal data, then ERP and billing, then analytics and file stores. Connectors are set to read metadata and sample data only where the scope note permits. The output is a connector inventory showing each source, its owner, the ingestion status and any sources that could not be connected, with the reason recorded. Ask the platform vendor to confirm connector coverage for each system type before the work starts.
Bootstrap owners and glossary terms
Using ingested schemas, query logs and interviews with the target's business and IT leads, the team assigns an accountable owner and a steward to each dataset and proposes glossary terms for overlapping definitions, such as two companies defining the same customer or revenue measure differently. Owners confirm or correct proposed assignments. The output is a list of datasets without an owner, a draft glossary with conflicting definitions flagged, and a record of who approved each entry.
Classify personal data with human review
Automated classification runs on column names and sampled values, and the results are treated as candidates rather than findings. A privacy reviewer checks high-confidence and low-confidence tags, particularly on free-text fields and identifiers, and maps confirmed personal data to the target's records of processing. The team records the confidence threshold used and the reviewer's decision for each tag. The output is a reviewed personal data inventory with the reviewer's sign-off and a list of systems where personal data was found outside the documented processing activities.
Capture lineage into reporting outputs
The team traces table, column and pipeline lineage from source systems into the finance, regulatory and management reports that the acquirer will need to rely on during and after integration. Where lineage cannot be captured automatically, such as manual spreadsheet steps, the gap is recorded as a manual node with an owner. This shows which reports depend on which source systems and where internal control over reporting may need attention. The output is a lineage map for the in-scope reports with documented gaps, reviewed by the report owners.
Hand over the discovery register
The team compiles the findings into a discovery register covering systems, owners, overlapping datasets and definitions, personal data locations, transfers, lineage gaps and open legal questions, then transfers catalog administration to the acquirer's data governance function. The register is structured so it can serve as an input to the acquirer's third-party and ICT service inventories where those apply. The output is a signed register, a runbook for the catalog, and a list of open items with named owners.
Evidence the deal team, auditors and regulators will ask for
This table lists the evidence items an M&A deal team, an external auditor or a regulator is likely to request from a catalog-based inventory of an acquired company's data, and the catalog component that produces each one. Read it as a checklist to agree with the acquirer's counsel, auditors and compliance leads before discovery starts, since the required format depends on the regime that applies. The main takeaway is that the catalog produces inputs and records, while independent auditors and regulators decide what the evidence proves.
| Evidence item | Catalog component that produces it | What the reviewer will test |
|---|---|---|
| Owner-assigned system register | Ownership and domains on each asset, fed by connector inventory | Every production system has a named owner, a business purpose and a status |
| ICFR exclusion scoping memo | Lineage from financial reports to source systems, plus scope notes | Whether the acquired business is excluded and disclosed within the permitted period |
| IT general control mapping | Asset tags linking systems to access, change and operations owners | Which systems feed financial reporting and which controls cover them |
| DORA-style ICT arrangement register entries | Vendor and service assets linked to systems and data domains | Each third-party service supporting the acquired data flows is recorded and classified |
| GDPR Article 30 inputs | Personal data classifications, lineage and storage location tags | Categories of personal data, purposes, recipients and locations are documented |
| Transfer assessment for remote access | Access and location attributes on datasets, linked to access requests | Whether staff in a third country can reach EU personal data, and under which transfer tool |
| Data sensitivity and confidentiality labels | Classification tags and glossary terms reviewed by data stewards | Labels match the classification policy and reviewers signed off the results |
| Log of catalog changes | Audit history of edits, ingestion runs and ownership transfers in the catalog | Who changed what, when, and whether changes were approved |
What do buyers ask about cost, time and effort for an M&A catalog?
What drives the cost of an M&A data catalog project?
The main drivers are the number of source systems to connect, how deep lineage must go (table, column, or pipeline), how many dataset owners are reachable, how many records need personal data review, and where the platform is hosted. OpenMetadata and DataHub are released under Apache-2.0, so the software itself carries no license fee. The spend goes to infrastructure (database and search services), connector and lineage setup, curation of owners and definitions, and operations. Ask any partner for a quote that lists each source system, the lineage depth per system, the expected reviewer hours for personal data, and the hosting assumptions, so you can compare scopes rather than totals.
Can our own team build the M&A data catalog without a partner?
Yes, if you have engineers who can run Java and database services, operate connectors, and keep credentials and access in your own hands. OpenMetadata documents Docker for trials, Kubernetes deployments on managed and on-premises clusters, and bare metal installs with defined prerequisites. The harder part is usually not installation but getting system access, owner time and agreed definitions during a deal, when staff are stretched and legal scope is still moving. Many buyers split the work: internal staff own the decisions and stewardship, while an implementation partner handles connectors, deployment and hardening under a written scope.
What must the acquirer and target supply before the catalog work starts?
The team needs read access to candidate systems (warehouses, databases, BI tools, pipelines), named technical owners for each system, and a business contact who can confirm definitions for overlapping metrics. Legal must confirm what the acquirer is allowed to inspect before the deal closes, since reviewing personal data may be restricted by agreements and by data protection rules. Plan for owner time in the form of short review sessions, not full days. Ask the partner to list every access request, credential type and approval step in the scope document before any connection is made.
How quickly can an M&A catalog start, and what sets the pace?
The start depends on access approvals, the number of systems in scope, and whether the target's infrastructure can be reached from a network the acquirer controls. This page does not give a duration, because none is supplied for this work. Ask for a phased plan with a discovery milestone, a list of systems ranked by business criticality, and the approval dependencies that could delay each phase. Early phases often run inventory and ownership capture while legal and security reviews continue in parallel.
Is the catalog still useful if the deal does not close?
Usually yes, because the inventory of systems, owners, definitions and personal data locations documents the target's estate regardless of the outcome. However, the target's data may be held under restrictions that limit what can be kept, so retention and access rules must be agreed in writing before work begins. If the deal stops, ask the partner how the catalog is archived or removed, who holds the credentials, and how copies of metadata and sampled data are deleted or returned.
How does the M&A catalog support EU Data Act switching and DORA exit planning?
The catalog gives you a current map of which systems hold which data, how it flows, and who owns each service, which is the starting input for both obligations. The EU Data Act requires data processing service providers to support switching, including porting of exportable data, and sets a date of 12 January 2027 for no switching charges, according to Regulation (EU) 2023/2854. DORA Article 28(8) requires tested exit strategies for services supporting critical or important functions, and Article 28(3) requires a register of ICT arrangements. The catalog does not produce either document, but it supplies the dependency and ownership facts your legal and risk teams need. Confirm with counsel how these obligations apply to your entity.
What happens to the catalog after handover to the buyer?
After handover, the buyer owns the platform, credentials, connector configuration and the stewardship process, so the handover plan should name those owners and cover runbooks for connector failures, upgrades and backups. OpenMetadata publishes release notes with breaking changes, so upgrades need a tested plan. Ask the partner for documentation of the deployed architecture, a list of connectors and their schedules, the owner-by-dataset register, and an agreed support model, whether that is internal, a retainer, or both.
What to ask an implementation partner before the deal team commits
Start with the target's stack, because the catalog is only as complete as its connectors. Ask the partner which connectors they will configure for the acquired company's warehouses, BI tools, pipelines and identity sources, and which ones they expect to build or script by hand. Ask how they will confirm coverage: a written connector inventory that lists every system in scope, the source credentials needed, and the systems they could not reach. For lineage, ask whether it comes from OpenLineage events emitted by the target's pipelines, from query log parsing, or from manual mapping, and what lineage depth (table, column, pipeline) they commit to for the datasets that feed financial reporting or regulated reports.
Next, ask how owners and glossary terms will be bootstrapped when the target's people are unavailable, leaving, or under a sale-period restriction. A credible answer names the sources they will use, such as database ownership fields, job schedules, access logs and existing documentation, and explains how every inferred owner is marked as provisional until a named business owner confirms it. Ask how personal data will be tagged for records of processing: whether classification is rule-based on column names, entity recognition on sampled data, or both; how confidence thresholds are set; and who reviews the tags before they feed any Article 30 record. Request a sample of tagged results from a non-production copy before you agree the scope.
Finally, ask how access will be restricted for cross-border staff, including acquirer personnel outside the EEA who need to browse the catalog. Remote access to EU personal data from a third country can be a transfer under EDPB Guidelines 05/2021, so the partner should show role-based access that hides personal data details from non-approved users and a plan for the transfer tool if access is needed. Ask how OpenMetadata 2.0 breaking changes and future upgrades will be handled, including the embedding credential move into llmConfiguration, the Python 3.12 ingestion image rebuild and the Great Expectations migration. Last, confirm what the partner will not do: they prepare systems, controls and evidence, but they do not issue audit opinions or attestations, so ask which conclusions remain with your auditors.
How DeployOpen scopes and supports an M&A catalog
The sequence turns an acquisition inventory request into a written scope, a catalog running inside the client's environment, and documented evidence that the acquirer's own teams can maintain after the engagement closes.
Agree the scope in writing
DeployOpen and the client agree a fixed scope in writing before work starts. The scope names the acquired systems in or out of the inventory, the connectors to configure, the lineage depth required (table, column, pipeline), the personal data classes to tag, the deliverables and the timeline. Your own legal and compliance teams confirm which regulatory views the catalog must support, such as internal control, data protection or sector rules. The step closes when the signed scope document lists every deliverable and the people who approve each one.
Confirm the environment and access model
DeployOpen reviews where the catalog will run and who can reach it. This covers the cloud accounts, data centers or network segment the client controls, the identity provider used for single sign-on, and the service accounts that connectors will use against source systems. Any access granted to acquirer or target staff across jurisdictions is documented first, since remote access to personal data can itself count as a transfer. The step closes when the access model and network paths are written down and approved by the client.
Deploy the catalog inside the client environment
DeployOpen installs OpenMetadata or DataHub in the client's controlled infrastructure, with the metadata database and search service the chosen deployment method requires. The team checks the platform's prerequisites and sizing against the scope before installation, and records the versions deployed. Credentials for each source system are stored in the client's secrets management. The step closes when the platform is reachable through single sign-on and a test ingestion run completes against a non-production source.
Connect sources and capture inventory
DeployOpen configures connectors for the acquired systems in scope and runs metadata ingestion for databases, warehouses, BI tools and pipelines. Each discovered asset is linked to a candidate owner from system documentation, contracts or interviews, and owners are confirmed by the client. Lineage is captured where the connectors and pipeline integrations allow it, and gaps are logged. The step closes when an inventory report lists every in-scope system, its asset count, its owner status and its known lineage gaps.
Map overlaps, definitions and personal data
DeployOpen works with data stewards from both organizations to map datasets that overlap, define shared terms in the glossary and record conflicting definitions side by side. Automated classification flags likely personal data, and reviewers confirm or reject each tag before it is used for records or consolidation decisions. The step closes when the glossary, the overlap map and a reviewed list of personal data locations are approved by the client's data owners.
Harden and document the catalog
DeployOpen applies the platform's security settings, restricts roles and domains to the scope, enables audit logging and sets backup and restore procedures for the metadata database and search index. The team writes the runbook, the data ownership procedures, the onboarding steps for new stewards and the change record for the deployment. The step closes when a hardening checklist is signed off and the documentation is handed over to the client's operations owner.
Hand over evidence for assessors
DeployOpen compiles the evidence the client's assessors and auditors will ask for, such as the inventory snapshot, owner assignments, classification decisions, access reviews and the configuration record. This evidence is prepared to support the client's own assessments. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors or certification bodies make those determinations. The step closes when the evidence package is delivered and the client confirms which items its auditors will review.
Retain upgrades and support if needed
After handover, the client can choose an optional retainer covering platform upgrades, security patching, connector maintenance and operational support. Upgrades need care because major releases can include breaking changes that affect ingestion and credentials, so each upgrade is tested before it reaches production. The retainer scope, response expectations and reporting are written into the agreement. The step closes when the client either signs the retainer or confirms that its own team will run the catalog.
