Open Data Infrastructure
Open Data Infrastructure Exit Tests for Platform Mergers
How exit tests for platform mergers should cover table portability, catalog export, policy translation, lineage, workloads, and owners.
Platform mergers are where vague openness goes to be audited. Two teams can both claim portability and still spend months moving metadata by hand.
Mergers expose hidden lock-in
Open Data Infrastructure matters during consolidation because the merger does not only move data. It moves table contracts, catalogs, policies, lineage, semantic definitions, workloads, and ownership. If those pieces cannot move, the data is less portable than the architecture claimed.
Open standards help. The Iceberg REST catalog specification defines a catalog API boundary. OpenLineage defines a model for lineage events. W3C PROV gives a vocabulary for provenance. Those standards still need practical exit tests.
Exit tests make control concrete
An exit test should prove that tables can be read by another approved engine, catalog metadata can be exported or reconstructed, policies can be translated, lineage can be preserved, workloads can run in the target environment, and data product owners remain clear.
The test should be run before the merger becomes urgent. Waiting until contract renewal or acquisition close turns architecture into negotiation theater.
Core idea: Platform merger readiness is an exit test for data, metadata, policy, lineage, workload behavior, and ownership.
The ODI consolidation pattern
Open Data Infrastructure should make consolidation less dramatic. Tables should preserve meaning. Catalogs should preserve control. Policies should be understandable outside one platform. Lineage should tell the migration team what depends on what.
For adjacent context, read the data infrastructure exit strategy, vendor-neutral data architecture, and migrating without downtime.
What breaks first
- Tables are portable but catalog permissions are not.
- Lineage exports exist but do not preserve enough identifiers for impact analysis.
- Semantic definitions move separately from the models that depend on them.
- Ownership changes faster than the incident and support paths.
Questions to ask
Ask which twenty data products prove merger readiness. Ask whether another engine can read them, another catalog can govern them, and another team can operate them without private tribal knowledge.
The exit test is the only honest portability demo.
Sources to start with
These primary sources anchor the technical claims in this guide.
- Apache Iceberg REST catalog specification
- Apache Iceberg table specification
- OpenLineage object model documentation
- W3C PROV overview
Portability is not a promise until it survives a move.