Open Data Infrastructure
Open Data Infrastructure Catalog Exit Drills
How catalog exit drills test metadata export, policy migration, ownership transfer, workload cutover, and recovery.
A vendor exit clause means very little until somebody runs the drill.
Exit rights need operational proof
Buyers ask for portability. Vendors promise openness. Contracts mention export rights. None of that proves a team can leave a catalog without losing table metadata, policy meaning, ownership, credentials, workloads, or recovery evidence.
A catalog exit drill is a practical test. Pick representative tables and namespaces. Export metadata. Reconnect another engine or catalog path. Rebuild policy and ownership evidence. Cut over a workload. Restore from backup. Measure what had to be rebuilt manually.
Core idea: ODI catalog exit drills turn catalog portability from a procurement claim into operational evidence.
Open catalogs give buyers something to test
The Apache Iceberg REST Catalog specification defines a REST-based API for catalog operations. Apache Polaris documentation describes an open catalog implementation path for Iceberg. OpenMetadata documentation provides metadata and governance concepts that can support portability review.
The drill should not claim that every catalog can replace every other catalog with no work. That would be nonsense. The drill should show which data, metadata, policy, ownership, and workload controls survive the move.
Run the drill before renewal pressure
- Choose tables that represent critical formats, policies, owners, and workloads.
- Export catalog metadata, ownership, policy rules, credentials, lineage, and audit logs.
- Reconnect a second engine or catalog path using documented interfaces.
- Replay allow and deny decisions after migration.
- Measure manual rebuild effort and add it to procurement scorecards.
This extends the ODI buyer guide, contract language for exit rights, and vendor portability tests. Exit should be a tested capability, not a heroic project started during a renewal fight.
What breaks first
- Tables move, but policy and ownership do not.
- Metadata exports exist but cannot recreate useful catalog behavior in another environment.
- Workload cutover depends on private APIs that were never part of the exit plan.
- Recovery evidence stays trapped in the old platform.
Questions to ask during the drill
- Which catalog objects can be exported in documented formats?
- Can another engine or catalog path use the exported table metadata?
- Which policies, owners, and audit logs survive the move?
- How many manual steps are required before a critical workload runs again?
Sources to start with
These primary sources anchor the technical claims in this guide.
Portability is not real until the exit drill works.