Migrate from Collibra to DataHub

Migrate from Collibra to DataHub: what the move involves

The move from Collibra to self-hosted DataHub is a content and integration migration, not a file copy. Collibra stores assets, relations, workflows and stewardship roles in its own model, and DataHub uses a different one, so each piece must be mapped, converted and re-ingested. Teams usually arrive here because of a renewal, a data residency concern about a SaaS catalog, or lock-in to a vendor model they cannot easily leave. Collibra's on-premises maintenance for commercial customers ended on January 30, 2023, so a commercial customer still running an on-premises instance has no maintained path to stay put and should plan the move on its own timeline.

The work is normally shared between the data platform team, which owns connectors and the DataHub deployment, the governance team, which owns communities, domains and glossary content, and the security team, which owns SSO, roles and the hosting boundary. An implementation partner often carries the mapping and conversion scripts. Effort and risk depend less on the volume of assets than on how much of the catalog is hand-curated: glossary definitions, ownership, and approval history have to be reviewed, while technical metadata can usually be regenerated from sources. Ask any partner to confirm the scope of each category in writing before work starts.

Collibra's bulk export is a table-based CSV or XLSX file that follows the filters, columns and sorting applied on screen, so an export is only as complete as the view it was taken from. Before exporting, the team should build one saved view per asset type and confirm that relation columns are included, since those drive lineage and domain membership in the target. Keep an inventory of Collibra workflows, such as approvals and attestation tasks, because DataHub does not reproduce them one for one and those processes will need a design decision rather than a conversion step.

Which Collibra capabilities map to DataHub and which need rework

This table compares the main Collibra capabilities with their closest DataHub open-source equivalents and marks each as clean, needs rework or gap. Read the status column as a planning signal, not a verdict: confirm exact workflow behavior in the DataHub version you deploy before scoping the migration.

Collibra capability	DataHub equivalent	Status
Communities and domains	DataHub domains and ownership groups, recreated from your Collibra community and domain structure	Needs rework
Assets and technical metadata	Entities ingested through DataHub connectors, with 150+ integrations including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau	Needs rework
Business glossary terms and definitions	DataHub business glossary, loaded from YAML source files converted from a Collibra glossary export	Needs rework
Column-level lineage from technical sources	Column-level lineage populated by supported connectors; confirm coverage for each source you run	Clean
Lineage from custom or uncovered pipelines	No connector for every Collibra lineage source; plan custom ingestion or lineage emission for the gaps	Gap
Ownership and stewardship roles	Ownership on datasets and glossary terms; steward role models and approval chains must be rebuilt and confirmed in your version	Needs rework
Data quality rules and results	Data quality assertions and monitoring; re-create rules and confirm which results you need to keep as history	Needs rework
Custom workflows and approvals	Not documented as a feature of open-source DataHub; rebuild outside the catalog or confirm with the project	Gap
Access request workflows and compliance forms	Reserved for DataHub Cloud, not in the open-source edition	Gap

What data moves out of Collibra and what gets rebuilt

Collibra content does not move as one bundle. Assets and relations leave through table exports, glossary terms need reshaping into DataHub's source format, and technical metadata is rebuilt by connectors rather than copied from Edge. Each piece has a different owner and a different check before cutover.

Asset and relation exports

Collibra exports assets or complex relations to CSV or XLSX, and the export follows the filters, columns and sorting applied to the table on screen. That makes it the documented bulk path out of the catalog, but it is only as complete as the view you export. Before you export, confirm the filters capture every community and domain in scope, and that the relation columns you need are visible. Keep a row count per asset type so you can verify the import later.

Glossary conversion to YAML

Business terms, definitions, owners and relations must be reshaped into DataHub's YAML business glossary source before ingestion. Exported glossary rows rarely map one to one, so plan a short mapping table that pairs each Collibra attribute with a DataHub field. Check term relations and ownership separately, because a term that loads without its owner or parent looks correct in a quick review but fails stewardship checks.

Technical metadata re-ingested by connectors

Collibra's Edge sites move metadata from your network to the Collibra cloud, but DataHub does not use Edge. Each source needs a DataHub ingestion connector configured in your environment, with credentials held in your own secret store. Start with the sources that carry the most lineage and ownership value, then compare asset counts per source against the Collibra baseline before retiring any Edge site.

SSO on self-deployed DataHub Core

DataHub supports single sign-on through OpenID Connect providers such as Google, Okta and Azure AD. On self-deployed DataHub Core, the operator must configure the frontend server, while DataHub Cloud enables OIDC through its interface. Plan the identity callback URLs, group mappings and session settings as part of the platform build, and test a break-glass admin path before users move over.

Workflows that need rebuilding

Collibra workflows such as custom approval chains, stewardship tasks and certification cycles do not transfer as exported data. DataHub Core covers ownership, domains and glossary governance, but access request workflows and compliance forms belong to DataHub Cloud. Inventory each Collibra workflow now, mark it as migrated, rebuilt in your own process, or retired, and assign an owner before cutover.

Operating the Kubernetes footprint

Self-deployed DataHub runs GMS, the MAE and MCE consumers and the frontend alongside Kafka, a relational database, Elasticsearch and a graph index. These components need sizing, backup and upgrade routines that Collibra previously handled for you. The Helm chart runs a system-update job on upgrades to apply schema changes and reindex search, so schedule upgrades in a maintenance window and rehearse them in a non-production cluster first.

Migration sequence from inventory to decommission

This sequence moves Collibra governance content into self-hosted DataHub in controlled stages, so each stage produces a checked artifact before the next one starts. The final stage retires Collibra only after its exports are archived and stewards have signed off on the new catalog.

Inventory assets, relations, communities and domains
Before any data moves, the migration lead and data stewards list every Collibra community, domain, asset type, relation type, business glossary and stewardship role in scope. Each Collibra community and domain is recorded alongside the DataHub domain it will map to, along with the owners who must confirm the mapping. Ask your Collibra administrator which exports you can run under your current permissions, and confirm the export path with your Collibra contact. The output is a mapping document that lists every source object, its target in DataHub and the named owner who approved it.
Run a pilot on one domain
Choose one domain with a bounded set of assets and a single technical source, such as one warehouse connection, then stand up a self-hosted DataHub instance for the pilot. Export the chosen assets and relations from Collibra as CSV or XLSX, convert the business terms into DataHub's YAML business glossary source, and ingest the technical metadata with one DataHub connector. Compare what appears in DataHub against the Collibra export for that domain, and record each gap, such as an attribute with no matching DataHub field. Pilot is complete when the stewards for that domain have reviewed the results and agreed the gap list is either closed or accepted.
Expand the mapping and ingestion across domains
Using the lessons from the pilot, the team extends the mapping document to the remaining domains and adds one DataHub connector per source system. Glossary terms, owners and tags are converted in batches, and each batch is loaded into a non-production DataHub environment first. The team also confirms the Kubernetes sizing, database and search components needed for the full metadata volume, because the DataHub Kubernetes guide lists Kafka, a relational database, Elasticsearch and a graph index as required components. The output is a loaded DataHub environment with a per-domain record of ingested objects.
Reconcile both catalogs in a parallel run
Collibra and DataHub run side by side for a period agreed with the governance committee, and both catalogs stay available to users. A reconciliation job compares asset counts, relation counts, glossary term definitions and owner assignments between the two systems for each domain, then lists every difference. Stewards resolve each difference by correcting the DataHub load, the Collibra record or the mapping rule, and the reconciliation is repeated until the differences are cleared. The output is a reconciled asset count per domain and a signed-off glossary, approved in writing by the business glossary owners.
Cut over stewardship and access
Stewardship responsibilities, ownership assignments and user access move from Collibra roles to DataHub roles and group mappings, and the identity provider is connected to DataHub through OpenID Connect. On self-deployed DataHub Core, the operator configures the frontend for OIDC, so the platform team tests login, group assignment and permission scope with a small set of users first. Workflows that DataHub does not provide directly, such as approval routes or attestations, are documented as manual procedures with named owners. The output is a cutover checklist, signed by the data governance lead and the identity team, that shows each Collibra role, its DataHub equivalent and the test evidence.
Archive Collibra exports and decommission
Before the Collibra subscription or on-premises environment is retired, the team saves final CSV or XLSX exports of all assets, relations and glossaries, along with the mapping document, reconciliation reports and the cutover checklist. These archives go into storage that the records retention policy covers, and an auditor or legal reviewer confirms they can be read later. Ask your Collibra contract owner which termination and data return terms apply, since those terms are not covered here. Decommissioning is complete when the archive is verified, access to Collibra is removed and the decommission record is approved by the data governance lead.

What drives cost and duration in a Collibra to DataHub move

This table breaks down the cost components of moving Collibra governance content to self-hosted DataHub, showing who is paid for each, what recurs and what drives effort up or down. Use it to structure a written scope and to compare quotes on like-for-like terms. Resource figures come only from published minimums, so production sizing must be confirmed in your own environment.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Kubernetes and database infrastructure	Your cloud or data center team, and any partner who sizes and deploys the Helm charts	Recurring (compute, storage, backups) with a one-time sizing and deployment effort	Production sizing is not fixed by published figures. The Minikube guide cites more than 7 GB of RAM and the Docker quickstart cites 8 GB, which are evaluation minimums only. Confirm production sizing for GMS, consumers, Kafka, MySQL or PostgreSQL, Elasticsearch and the graph index.
Kafka, search and graph index	Your platform team for hosting, plus any managed service fees you choose	Recurring for hosting and operations; one-time for initial topology decisions	Metadata volume, ingestion frequency and retention drive streaming and index load. Ask the partner to state assumptions about event volume in the quote.
Connector setup per source	Your data engineers or a partner, per source system	One-time per source, with recurring maintenance when source APIs or versions change	Number of sources, source complexity and whether credentials and network paths already exist. DataHub lists more than 150 integrations, but each one still needs configuration and testing.
Glossary and relation mapping	Your governance team for decisions, and the implementer for transformation scripts	One-time	Volume of Collibra assets and relation types, how many relations have no direct DataHub equivalent, and how much of the export must be reshaped into the YAML business glossary source.
Stewardship and workflow redesign	Your governance and data owners, with implementer support for access and approval designs	One-time, with ongoing ownership upkeep	Number of Collibra workflows that must be rebuilt outside DataHub Core, such as approvals and attestations, and whether you accept manual processes or build custom tooling.
SSO configuration	Your identity team, with the implementer configuring the frontend OIDC settings	One-time, with recurring changes when identity providers or policies change	Identity provider choice (for example Okta, Azure AD or Google), group mapping and how many roles need distinct access. On self-deployed DataHub Core the frontend must be configured by the operator.
Upgrades and the system-update job	Your platform team, with an implementer if you buy upgrade retainers	Recurring, each release cycle	The Helm chart runs a system-update job that applies schema changes and reindexes search when needed. Reindexing time and rollback planning depend on your data volume and test coverage. Ask for a documented upgrade runbook.
Staff who run the platform	Your internal platform, data and security staff	Recurring	Operational scope, on-call expectations and whether backups, monitoring and security testing are in house. Ask the partner to separate build effort from run effort in the quote.

What usually goes wrong in a Collibra to DataHub migration

Most failed catalog migrations lose something in the handoff rather than in the software itself. The six risks below cover governance workflows, exported data, glossary ownership, connector coverage, upgrades, and access, and each one has a check you can run before cutover.

Lost stewardship workflows

Collibra approval workflows, certification steps and stewardship tasks do not move as data. They have to be redesigned in DataHub, where the open-source edition covers ownership, domains and assertions but not every Collibra approval path. Before cutover, list each active workflow, record who triggers it and who signs off, and mark which ones DataHub can express directly and which need a process owner to replace them manually.

Relation loss in flat exports

Collibra's CSV and XLSX exports are table-based and follow the filters, columns and sorting on screen. Relations between assets can be flattened or dropped if the export view does not include the relation columns. Compare row counts and sample relations for each asset type against the source before you load anything into DataHub, and keep the export configuration with the migration record.

Glossary terms without owners

Business terms exported from Collibra often carry steward and owner relations that do not map cleanly onto DataHub's business glossary and ownership model. Terms can arrive with definitions but no accountable person, which makes them look governed while nobody answers for them. Before loading the YAML glossary source, confirm that every term has an owner value that resolves to a real DataHub user or group, and reject terms that cannot be assigned.

Connectors that miss Edge coverage

Collibra Edge runs collection inside the customer network, so some sources may be reached today through Edge capabilities that have no one-to-one DataHub ingestion recipe. Build a source inventory from Collibra's Edge configuration, match each source to a DataHub connector, and test each recipe in a non-production environment. Sources without a connector need a documented gap and an owner for a custom ingestion job.

Search reindexing during upgrades

DataHub's Helm chart runs a system-update job on upgrades that applies schema changes and reindexes search indices when needed. On a catalog with large metadata volumes, that reindex window can make search slow or unavailable. Schedule upgrades outside business hours, confirm the Elasticsearch or OpenSearch capacity and the Kafka retention for your metadata volume, and back up the MySQL or PostgreSQL database before each upgrade.

SSO misconfiguration

On self-deployed DataHub Core, the frontend server must be configured by the operator for OpenID Connect, so redirect URIs, client secrets and group claims are set by hand. A mismatch can lock out stewards or grant the wrong role, and Collibra users who relied on directory groups may not map to DataHub roles. Test login with a steward, a read-only user and an administrator account, and confirm group claims before opening access to business users.

Parallel runs that drift

Keeping Collibra and DataHub live side by side invites stewards to edit in both places, and the two catalogs diverge within days. Set a freeze date for Collibra edits, publish a single owner for each domain during the parallel period, and run a scripted comparison of asset counts, glossary terms and ownership between the two systems before retiring the Collibra subscription.

How the migration differs by catalog size and starting point

If Collibra is used mainly as a business glossary, with terms, definitions, owners and relations that data stewards maintain, the migration centers on content transfer rather than pipelines. The glossary is the first deliverable, because business users and stewards will judge the new catalog by whether their terms are present and correct. Technical metadata can follow in a second wave, which keeps the first milestone small and checkable.

Export first: Use table-based CSV or XLSX exports from Collibra, which follow the filters and columns on screen, so the export scope is set deliberately before any conversion starts.
Convert to DataHub's glossary source: Map terms, categories and relations into DataHub's YAML business glossary format and review the output with the stewards who own each term.
Limit the first wave: Load only the terms and owners that the business has signed off, and defer rebuilding approval steps until the content is verified.
Plan stewardship separately: Ownership and review cycles usually need to be re-established in DataHub by hand, so budget steward time as a distinct workstream.

Before starting, confirm with your steward group how many terms, relations and custom attributes are in scope, because that count drives the conversion and review effort more than the number of systems.

Questions buyers ask before a Collibra to DataHub migration

What drives the cost of moving from Collibra to self-hosted DataHub?

Cost depends mostly on how much governance content you move, how many sources you reconnect and how much of the Collibra workflow you must rebuild. The main components are the infrastructure to run DataHub (Kubernetes, Kafka, a MySQL or PostgreSQL database, Elasticsearch or OpenSearch and a graph index), the connector setup for each source, glossary and domain conversion, stewardship redesign, and the staff who run and upgrade the platform. Infrastructure is recurring, while the migration work is largely one-time. The DataHub Kubernetes guide notes that more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, which is a useful floor for a test environment rather than a production sizing. Ask any partner for a quote that itemizes these components separately.

How long does a Collibra to DataHub migration take?

Duration follows scope, not a fixed template. The biggest variables are the number of communities and domains, the volume of assets and relations to export, how many technical sources need new DataHub connectors, and whether lineage must be rebuilt rather than carried over. A narrow move of a glossary and a few sources is a very different project from a full catalog with custom Collibra workflows. Most engagements are fixed-scope, so the written scope should state the phases, deliverables and timelines before work starts. Ask for the timeline to be tied to named sources and content volumes.

What does our team need to provide for the migration?

You need to supply access and decisions that only your organization can give. That includes Collibra exports or API access, a list of communities, domains and stewards, the approved business glossary owners, credentials and network paths for each data source, and a cloud or data center environment where DataHub will run. Your team also needs to decide which Collibra workflows must survive, which access rules apply, and who signs off on the target model. Confirm early who owns each source system, because connector setup stalls when those owners are not identified.

Can our internal team migrate from Collibra to DataHub without a partner?

Yes, many engineering teams can do this in-house, especially with a small catalog and experience running Kubernetes and data pipelines. The work is mainly export transformation, YAML business glossary authoring, connector configuration and operations. Internal teams usually struggle with the parts that are unfamiliar: sizing and hardening the Kubernetes deployment, configuring OIDC SSO on self-deployed DataHub Core, planning upgrades (the Helm chart runs a system-update job to apply schema changes and reindex search), and rebuilding governance workflows. Be honest about that skill gap when you estimate internal effort. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and can cover the parts your team does not want to own.

How do we run Collibra and DataHub in parallel during cutover?

Run both catalogs in read-only overlap for a defined period, with Collibra remaining the system of record until DataHub has been validated. Load the same domains and glossary terms into DataHub, reconcile asset counts and ownership between the two, and compare lineage for the sources you care about most. Keep stewards working in one catalog at a time to avoid conflicting edits, and set a written date after which Collibra becomes read-only. Plan for Collibra subscription and Edge costs to continue during the overlap, since those are contract terms you should confirm with the vendor.

Do Collibra workflows transfer to DataHub?

Assets, relations, domains, ownership, glossary terms and many technical lineage paths can be moved or re-created, but Collibra-specific workflow engines do not transfer as-is. DataHub covers column-level lineage, a business glossary, ownership, and data quality assertions, and it provides governance and discovery features in the open-source edition. However, DataHub's access request workflows and compliance forms are reserved for DataHub Cloud, so approval flows and attestation forms built in Collibra need to be rebuilt with other tooling, process changes or DataHub Cloud. Map each Collibra workflow to a DataHub feature, a custom process or a gap before you commit to scope.

How does DataHub Cloud differ from open-source DataHub for this migration?

DataHub is Apache-2.0 licensed and self-hosted, and the company behind it also sells DataHub Cloud, which its README describes as managed, SLA-backed and enterprise-ready with no infrastructure to run. Per DataHub's comparison documentation, DataHub Cloud adds data quality monitoring, AI anomaly detection, compliance forms, access request workflows, a 99.5% uptime SLA and AWS PrivateLink, none of which are in open source. If you need those features or a contractual uptime commitment, factor DataHub Cloud into the decision. If you choose self-hosting, you own the operations, upgrades and the gaps listed above. Confirm current feature availability with DataHub before deciding.

How DeployOpen scopes and runs a Collibra to DataHub migration

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted DataHub inside your own infrastructure, whether that is your cloud account, a private data center or an air-gapped network. The work covers the Kubernetes deployment with the Helm charts, the prerequisite services DataHub depends on (Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch or OpenSearch for search, and a graph index), the connectors for your technical sources, the single sign-on configuration for the frontend, and the runbooks your operators will use after handover. Because the open-source edition is Apache-2.0 licensed and runs on infrastructure you control, the scope is about your environment and your data flows, not about a vendor-hosted tenant. Most engagements are fixed-scope. Before work starts, the written scope should name the Collibra communities, domains and asset types in the migration, the export format used for each (CSV or XLSX from the table view, or scripted reads through the Core REST API), the DataHub connectors to be configured, the glossary files to be loaded, and the acceptance checks that show the migrated content matches the source. Ask for deliverables and timelines in writing and make the cutover criteria explicit, including which Collibra workflows will be retired and which will be rebuilt by your stewards. Ongoing support, upgrades and continuous testing are available as retainers, which matters because DataHub upgrades run a system-update job that applies schema changes and reindexes search when needed, and those changes should be planned rather than discovered in production.

On compliance, DeployOpen prepares the systems, controls and evidence that an assessment will look at, such as access configuration, backup and restore records, change history and documented roles for the catalog. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so ask your auditor early which evidence they expect for the catalog and which control references apply to your program. Confirm with your own compliance lead whether migrated Collibra governance records (ownership, classifications, approvals) need to be retained in a particular form for the period your policy requires, because the export is a copy and the source may still hold the authoritative history during parallel running.

Migrate from Collibra to DataHub