Open-source alternative to the Collibra business glossary

Collibra's documented bulk export path is a table-based export to CSV or XLSX, and the export follows the filters, columns and sorting of the table on screen. That means the view is the export. Before you export terms, set the asset type filter to the glossary assets you need, add the columns that carry definitions, status, owners and relations, and clear any leftover filters that would silently drop rows. Export one asset type at a time so each file has a consistent set of headers. Then open each file and check row counts against the Collibra view to confirm nothing was cut off by a filter or pagination.

For each glossary asset type, confirm that the export includes the term name, definition, status, steward or owner, and the related terms or relations. Relations are the part most likely to be lost, because complex relations are exported through their own relation header format rather than as plain columns on the term. Read the exact headers from your own export and write them down, since column names depend on your Collibra version and your configuration. Do not assume a header from another team's export or from documentation. Keep a short mapping sheet that records each source header, the OpenMetadata or DataHub field it will populate, and any header with no target, so the gaps are visible before loading starts.

Export files contain business definitions, owner names and sometimes sensitive descriptions, and they are copies of your governance record outside Collibra. Store them only in approved storage inside your own environment, restrict access to the migration team, set a retention date, and delete working copies once the import is verified. Record who exported what and when, so the migration has an audit trail. Your security or records team should confirm where these files are allowed to sit before the first export runs.

Approval chains, custom workflow automation and Collibra-specific intake or community structures do not move as files. A glossary export carries terms, definitions, owners and relations, but not the routing rules that decided who approved a term, the status transitions that triggered notifications, or the community hierarchy that grouped stewards. Before you export anything, document each active workflow in Collibra, who initiates it, who signs off, what state it leaves the asset in, and which downstream process depends on that state. That inventory becomes the rebuild backlog, and it is the artifact your governance lead should review, not the CSV.

The target platforms differ in what they ship. OpenMetadata 2.0 adds custom intake forms and replaces the Knowledge Center with the Context Center, so requests for new terms and the surfaces where stewards work may map onto built-in features. DataHub's access request workflows and compliance forms are listed as DataHub Cloud features in the DataHub comparison documentation, so confirm in the self-hosted edition's current documentation and in a test instance whether they exist for you. Check approval depth, per-asset routing, notification behavior and audit history separately, because a form that exists does not guarantee the same approval logic.

Plan to rebuild whatever you cannot confirm. Write each retained workflow as a short, testable specification, including the trigger, the approver role, the expected result and the evidence it leaves. Where the self-hosted edition lacks a feature, decide between a manual step with a named owner, a scripted process using the OpenMetadata or DataHub APIs, or an external ticketing tool, and record that choice in your governance procedures. Ask any implementation partner to walk through the workflow inventory in writing before migration starts, so that scope and acceptance tests are agreed up front.

The license is not the whole cost picture. Both OpenMetadata and DataHub Core are released under the Apache License 2.0, so the glossary code, its API and its import paths can be run, modified and kept inside your environment without a per-seat subscription. The commercial layer sits beside that code. Collate maintains OpenMetadata and sells managed deployment, premium support and AI features, and the company behind DataHub sells DataHub Cloud, which its documentation describes as managed and SLA-backed. Before you commit, ask each vendor in writing which glossary features, connectors and support levels are in the open-source edition and which are paid, and confirm the answer against the current license files in each repository. Also confirm who will be your first point of escalation for a production incident in your own network.

Upgrade discipline is where a self-hosted glossary most often breaks. OpenMetadata 2.0 moved embedding credentials into an llmConfiguration block, introduced a new Databricks auth format and requires custom ingestion images to be rebuilt for Python 3.12. It also asks you to migrate Great Expectations to 1.3 before upgrading. Read the 2.0 release notes line by line, inventory every custom ingestion image and configuration file that touches these keys, and test the change in a non-production stack first. The current point release is 2.0.5, released on October 8, 2026, and the project ships maintenance releases every one to two weeks, so set a fixed review cadence rather than upgrading ad hoc. DataHub handles schema changes differently: its Helm chart runs a system-update job on upgrades that applies schema changes and reindexes search when needed. Plan a maintenance window for that job, monitor it to completion, and confirm the current release, 1.7.0.1 from September 3, 2026, against your pinned chart version.