Open Data Infrastructure

Open Data Infrastructure Contract Language for Exit Rights

Buyer contract-language checkpoints for data platform exit rights across table access, catalog export, metadata portability, policy migration, and assistance.

The wrong time to negotiate exit rights is after your data platform has become your data architecture.

Exit rights need technical detail

A data platform contract can say the customer owns the data and still leave the customer trapped. Ownership without practical export, metadata portability, catalog access, policy migration, and transition assistance is not much of an exit plan.

Open Data Infrastructure gives buyers a better checklist. Ask which table contracts, catalog APIs, metadata exports, lineage records, policy definitions, workload histories, and operational assistance rights survive the end of the vendor relationship.

Core idea: Exit-rights language should specify the infrastructure contracts that move, not only the files that can be exported.

Open contracts are the buyer protection

The Apache Iceberg table specification and REST Catalog specification show why table metadata and catalog operations are distinct contracts. OpenLineage, DataHub, OpenMetadata, and OPA show adjacent evidence categories buyers should ask about: lineage, metadata, governance, and policy decisions.

This is not legal advice. It is the technical checklist a buyer should hand to counsel and procurement so the contract covers real platform control.

Patterns that work

  • Require export of data, table metadata, catalog namespaces, table identifiers, snapshots, and schema history.
  • Specify catalog-access rights during transition, including API access and documented rate limits.
  • Require metadata, lineage, policy, access-log, and audit export in documented formats.
  • Name transition assistance duties for workload migration, validation, and incident support.
  • Define exit test criteria before signing, including a pilot export and restore drill.

For adjacent ODI context, read vendor portability tests, procurement scorecards, true cost of lock-in.

What breaks first

  • The contract allows data export but not catalog metadata or policy history.
  • Exit support depends on professional services language with no technical deliverables.
  • The vendor can provide files but not the table semantics needed to read them correctly.
  • Metadata exports omit lineage and ownership, so the receiving platform inherits blind spots.

Questions to ask

  • Which exact artifacts leave with the customer at exit?
  • Which APIs stay available during transition?
  • How are table, catalog, metadata, lineage, and policy exports validated?
  • What assistance does the vendor owe if the export fails the agreed test?

Sources to start with

These primary sources anchor the technical claims in this guide.

Exit rights are only real when the architecture can pass the exit test.

ODI hub Article library Use the scorecard Vendor portability tests
Get started with Apache Iceberg, today! Want to learn more? Visit https://www.opendatainfrastructure.com/