On-premises Collibra replacement

Why an on-premises Collibra replacement is now a planning decision

If your organization still runs on-premises Collibra, you are working past the point where the vendor's commercial on-prem support path was available: Collibra ended maintenance support for on-premises environments for commercial customers on January 30, 2023. The vendor path now leads to SaaS, so staying with Collibra on your own hardware is no longer a supported plan for most commercial teams. The self-hosted answers are OpenMetadata or DataHub, both of which you can install and operate inside your own data center or private cloud. Collibra's announcement states that it will continue to support on-premises environments for the public sector, so public sector customers have a different constraint than commercial ones. Confirm your organization's classification with Collibra's account team and read the relevant entries in the Collibra release notes before you assume either way. Do not treat a public sector exception as a reason to delay planning, because contract terms and support windows can change.

The reason this is a planning decision rather than a routine upgrade is where your governance metadata lives. Business terms, data owners, stewardship assignments, lineage and classifications all sit in the catalog, and a move to SaaS would place that metadata in a vendor-operated environment. Your first task is to list every metadata category your Collibra instance holds, then confirm which of them must remain inside your network under your data residency and security rules. Also check whether your Collibra Edge sites are part of the current estate, since they change which connectors and credentials need to move. Once scope is agreed, plan for export, parallel running and a cutover date owned by named people in governance and platform engineering. Export is the first gate: Collibra's documented bulk path produces CSV or XLSX files that follow the filters, columns and sorting of the table on screen, so the export you run must be verified against the asset types you need. Start that inventory now, while the on-premises instance is still under your control.

What keeping catalog metadata on-premises requires

Moving off on-premises Collibra means the catalog, its metadata store and its search index all become your responsibility. The five requirements below cover where the software runs, who signs users in, where data lives, who upgrades the platform and how you get your content out of Collibra in the first place.

Operator-controlled hosting

Self-hosted OpenMetadata or DataHub Core runs in your data center or private cloud, so the operator decides the host, network segments and patch windows. OpenMetadata documents production deployment on Kubernetes (including on-premises clusters) and on bare metal. Confirm which topology your security team can approve, and whether ingress, egress and connector traffic can stay inside your perimeter.

Operator-configured SSO

On self-deployed DataHub Core, the frontend server's OpenID Connect settings are configured by the operator, while DataHub Cloud enables OIDC SSO through its interface. Plan the identity provider integration before go-live, including redirect URIs, group claims and how stewards and administrators are mapped to roles. Verify the same requirement against the OpenMetadata security documentation for your chosen deployment.

Metadata stored in your databases and indices

The catalog's content lives in databases and search services you run. DataHub uses Kafka for streaming metadata changes, MySQL or PostgreSQL for storage, and Elasticsearch or OpenSearch for search. OpenMetadata bare metal needs Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. Ask who backs these up, where those backups are kept and how restores are tested.

Operator-owned upgrades

With self-hosted software, the upgrade calendar is yours. OpenMetadata 2.0 includes breaking changes, such as moving embedding credentials into an llmConfiguration block and migrating Great Expectations to 1.3 before upgrading. The DataHub Helm chart runs a system-update job that applies schema changes and reindexes search when needed. Build a staging environment and a rollback plan, and track each release on its GitHub releases page.

A bulk export path out of Collibra

Before you cut over, you need the content out of Collibra. Its documented bulk path is a CSV or XLSX export of assets or complex relations, and the export follows the filters, columns and sorting applied to the table on screen. Set those views deliberately, since they define what leaves the platform. Test the export on a representative domain and confirm the relation format before loading it into the new catalog.

Where the Collibra vendor path leads for commercial customers

Collibra ended maintenance support for on-premises environments for commercial customers on January 30, 2023, and its release announcements state that on-premises support continues for the public sector. For a commercial customer still running an on-premises Collibra instance, the vendor path no longer keeps the catalog in your own data center. The Collibra Platform is delivered as SaaS on AWS and Google Cloud, so the question of where catalog and governance metadata lives moves to the vendor's cloud or to the Edge components that process data inside your network.

Edge is the part of the Collibra architecture that matters most for an on-premises review. Edge sites run processing inside the customer's network, but the governance metadata, workflows and user experience sit in the SaaS platform. Before you assume Edge answers a data residency requirement, ask Collibra in writing which metadata is stored in the cloud, which stays in your network, what the Edge site retains, and how it is licensed and upgraded. Ask your account team to put the answer in the contract or order form, not only in a sales deck.

Confirm current contract terms directly with Collibra before you plan around any date or support position. Check your existing agreement, the renewal terms, whether an on-premises entitlement still applies to your organization, and what happens to your instance at renewal. Your decision then becomes concrete: either accept the SaaS and Edge model with written data handling terms, or start a replacement project such as OpenMetadata or DataHub that keeps metadata in infrastructure you control. Plan the export of your assets and glossaries early, because the replacement path depends on it.

How OpenMetadata and DataHub differ for an on-premises footprint

OpenMetadata is released under the Apache License 2.0 and maintained by Collate, which also sells managed OpenMetadata, commercial support and premium features. For an on-premises footprint, the project documents production deployment on Kubernetes with Helm charts, including on-premises Kubernetes clusters, and on bare metal without Kubernetes. Docker Compose is the route for evaluation rather than production planning.

Bare metal prerequisites: The bare metal guide lists Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x.
Minimum sizing: The guide gives a minimum server of 2 vCPUs, 4 GB RAM and 20 GB storage, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. Production sizing will be larger.
Kubernetes path: Helm charts cover on-premises clusters, so teams already running a private Kubernetes platform can reuse their existing cluster operations.
Version pace: OpenMetadata 2.0.0 was released on August 24, 2026, with maintenance releases through 2.0.5 on October 8, 2026. Upgrade notes include a move to Python 3.12 for ingestion images and a migration of Great Expectations to 1.3 before upgrading.

Confirm the current release and the upgrade notes on the GitHub releases page before you set a baseline, because the project ships frequently.

Options that keep metadata inside your infrastructure

This table compares the three self-hosted open-source options against the on-premises constraint, licensing, lineage and governance coverage, connector counts and trade-offs. Read it as a shortlist: the first two cover a general catalog, while Apache Atlas fits teams already invested in Hadoop and Apache Ranger. Commercial managed tiers are outside the self-hosted scope of this comparison.

Requirement	OpenMetadata	DataHub Core	Apache Atlas
Runs in your own data center or private cloud	Yes, on Kubernetes (including on-premises clusters), on bare metal, or with Docker Compose for evaluation	Yes, on Kubernetes with Helm charts, or with the Docker quickstart for trials	Yes, it is an Apache project built to run on Hadoop clusters you operate
License	Apache License 2.0, maintained by Collate, which sells managed and enterprise tiers	Apache License 2.0, with DataHub Cloud sold separately by the company behind it	Apache License 2.0, from the Apache Software Foundation
Connector coverage	More than 130 connectors for warehouses, BI, pipelines and ML platforms	More than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau	Mostly Hadoop-ecosystem sources; confirm coverage for your warehouses and BI tools
Lineage	Table, column, dashboard, pipeline and metric lineage with OpenLineage events	Column-level lineage from supported connectors and push ingestion	Lineage for Hadoop components such as Hive and Sqoop; confirm for other sources
Governance coverage	Glossaries, classifications, domains, data quality tests and profiling, all in the open-source release	Business glossary, ownership, data quality assertions; compliance forms and access request workflows are reserved for DataHub Cloud	Classification tagging with Apache Ranger enforcing classification-based access control
Infrastructure you run	Database (MySQL or PostgreSQL), Elasticsearch or OpenSearch, and the OpenMetadata server	Kafka, MySQL, PostgreSQL or MariaDB, Elasticsearch or OpenSearch, and a graph index on Neo4j or Elasticsearch	Apache Atlas with its own storage and search backends, plus Ranger for access policies
Trade-off to plan for	Frequent maintenance releases; check breaking changes such as the 2.0 Databricks auth format before upgrading	More moving parts to operate, especially Kafka; the Minikube guide cites more than 7 GB RAM for a trial	Narrower fit outside Hadoop-centered estates; a smaller connector set for modern cloud warehouses
Choose it when	You want a general catalog with broad connectors and built-in data quality, and can run a Kubernetes or bare metal stack	You want a broad integration catalog and can operate Kafka and search infrastructure	Your metadata and access control already center on Hadoop and Ranger

How to deploy OpenMetadata or DataHub inside your data center

This sequence moves the catalog from Collibra's SaaS-only path to a self-hosted platform in your own network, with sizing, platform choice, identity, ingestion, upgrades and operational controls agreed before go-live.

Size the infrastructure from documented minimums
Your platform and infrastructure team sets the capacity plan before any installation. For OpenMetadata, the bare metal documentation lists a minimum server of 2 vCPUs, 4 GB RAM and 20 GB storage, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. For DataHub, the Kubernetes guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, which suits a test, not production. Treat these as floors. Real sizing depends on the number of assets, sources and users you expect, so ask your vendor or partner to model that against your Collibra asset counts. Done when the capacity plan is signed off by the platform owner.
Choose Kubernetes or bare metal for production
Decide the deployment model based on the platform skills you already run. OpenMetadata documents production deployment on Kubernetes with Helm charts, including on-premises Kubernetes clusters, and on bare metal without Kubernetes. DataHub is deployed on Kubernetes with Helm charts from the acryldata/datahub-helm repository, plus a separate prerequisites chart for Kafka, the database, Elasticsearch and the graph index. Confirm which of your clusters, storage classes and database services are approved for governance metadata. Done when the chosen model, cluster location and database service are written into the architecture record.
Configure OIDC single sign-on and access
Connect the platform to your existing identity provider before loading any business data. DataHub supports OpenID Connect providers such as Google, Okta and Azure AD, but on self-deployed DataHub Core the operator configures the frontend server. OpenMetadata's security documentation covers the authentication options for its deployment. Map your Collibra roles to platform roles, and decide who can edit glossaries and domains. Done when a test user signs in through your identity provider and a role check confirms that edit rights match the agreed matrix.
Re-ingest sources with connectors instead of Edge
Collibra Edge processed metadata inside your network, so this step replaces that role with the platform's own connectors. OpenMetadata lists more than 130 connectors, and DataHub lists more than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau. Check each source against the connector list, then run ingestion from inside your network with service accounts scoped to read-only metadata. Confirm lineage sources that have no connector and plan new work for them. Done when every in-scope source has a successful test ingestion and its gaps are logged.
Load glossaries, owners and lineage
Bring governance content across once technical metadata is flowing, so business terms link to real assets. Export from Collibra using the CSV or XLSX path, which follows the filters and columns on screen, then load glossary content through OpenMetadata's glossary CSV import or DataHub's business glossary source. Recreate domains and ownership, then compare a sample of terms and owners against the Collibra export. Workflows such as approvals may not transfer, so record them separately. Done when a reviewer signs off a sample set of terms, owners and lineage paths.
Plan upgrades with the platform's upgrade steps
Write the upgrade procedure before the first production release. DataHub's Helm chart runs a system-update job on upgrades to apply schema changes and reindex search indices when needed, so allow for that job in your change window. OpenMetadata 2.0 introduced breaking changes, including moving embedding credentials into an llmConfiguration block, a new Databricks auth format, rebuilding custom ingestion images for Python 3.12, and migrating Great Expectations to 1.3 before upgrading. Follow the current release notes for your version, and test each upgrade in a non-production copy. Done when a rehearsal upgrade completes in staging and the breaking-change checklist is closed.
Confirm backups and network controls internally
Your own security and operations teams confirm the controls the vendor cannot decide for you. Agree the backup scope for the metadata database, search indices and any graph or streaming components, and test a restore. Confirm network segmentation, egress rules, TLS between components, secret storage and audit logging against your internal control framework. Ask your implementation partner to document each setting as evidence, but note that they prepare evidence and do not issue attestations. Done when a restore test succeeds and the security review signs off the controls.

Evidence that auditors and regulators ask for

Auditors and regulators rarely ask whether a catalog is secure in general. They ask where governance metadata is stored, who can reach it, how it is recovered, and how the platform changed over time. The cards below are the records that answer those questions for a self-hosted OpenMetadata or DataHub deployment that replaces on-premises Collibra. DeployOpen prepares these artifacts; auditors and certification bodies issue any opinion on them.

Architecture and data flow records

A current diagram and written description of where each metadata store sits: the application server, the database, the search index, and, for DataHub, Kafka and the graph index. Mark which connectors reach into source systems, from which network segment, and which outbound calls the platform makes. Auditors use this to confirm that no catalog content leaves your data center or private cloud unless a documented connector or integration sends it. Review it again whenever a connector or component is added.

Deployment manifests and version records

Keep the Helm values, Kubernetes manifests or bare metal configuration under version control, with the exact image tags and chart versions deployed in each environment. For DataHub, record the Helm chart version alongside the prerequisites chart. For OpenMetadata, record the server version and the ingestion image version separately. These records show what ran, when, and whether production matches what was tested.

SSO and access configuration

Document the identity provider integration, the OIDC client settings, the mapping of groups to catalog roles, and the admin accounts that remain outside SSO. On self-deployed DataHub Core the operator configures the frontend server, so this file is part of your own evidence set. Ask for an export of role assignments at each review date and a list of who approved each change.

Backup and restore test records

A backup is only evidence once a restore has been tested. Record the database backup schedule, the search index rebuild procedure, and the dates and results of restore tests into a separate environment. Note whether restored metadata matched the source, including glossary terms, owners, domains and lineage. Auditors often ask for the last successful test, not the policy alone.

Upgrade logs and change records

Keep a log of each upgrade with the release notes reviewed, the breaking changes assessed, the pre-upgrade backup reference, and the approver. OpenMetadata 2.0 changed several settings and required rebuilding custom ingestion images, so the log should show those steps were done. For DataHub, record that the system-update job completed and whether search reindexing ran. Upgrade logs show change control was followed, not just planned.

Collibra export files as migration evidence

Retain the CSV or XLSX exports taken from Collibra before cutover, together with the filters, columns and sort order used, since the export follows the table on screen. Keep the row counts, the mapping from Collibra assets and relations to the new platform, and a reconciliation report showing what was loaded and what was not. This record shows the migrated content, and any gaps, are documented rather than silently lost.

Questions buyers ask before planning an on-premises replacement

Does Collibra still support on-premises for commercial customers?

No. Collibra ended maintenance support for on-premises environments for commercial customers on January 30, 2023, according to its release announcements. The vendor says it will continue to support on-premises environments for the public sector, so the option depends on your customer type. Commercial teams still running an on-premises instance should confirm their current support position in writing with Collibra and their account team, and should check Collibra's release announcements for any later changes. Treat the end of maintenance as the starting point for planning, because a version that no longer receives fixes carries growing security and compatibility risk.

Why does the vendor path lead to Collibra SaaS instead of staying on-premises?

For commercial customers, the vendor's current delivery model is the Collibra Platform as SaaS, run by Collibra on AWS and Google Cloud, with Edge sites for processing inside your network. An Edge site keeps some connector work local, but the catalog and governance metadata are hosted in Collibra's cloud. If your requirement is that catalog metadata, glossary content and lineage remain in your own data center or private cloud, a SaaS upgrade does not meet it. Before any commercial discussion, write down whether the residency rule covers the metadata itself or only the source data, because that answer decides whether Edge is enough.

What does the internal team need to run OpenMetadata or DataHub?

The team needs platform engineers who can operate Kubernetes or a bare metal host, a database administrator for the metadata store, and someone who owns search and, for DataHub, streaming. OpenMetadata lists Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x as bare metal prerequisites. DataHub's Kubernetes guide lists GMS, the MAE Consumer, the MCE Consumer and the Frontend, plus Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch for search and a graph index on Neo4j or Elasticsearch. Data stewards and catalog owners also need time to define domains, ownership and glossary terms, which is a business task rather than an infrastructure one.

How long does a migration off on-premises Collibra take?

Duration depends on the volume of assets, the number of source systems, the complexity of relations and workflows, and how much governance content your stewards want to carry over. No general figure applies, so ask for a timeline in a written, fixed scope before work starts, with deliverables listed by phase: export, glossary load, connector setup, validation and cutover. Ask the provider to state which parts depend on your stewards and approvals, because those are the usual sources of delay. A small pilot with one domain and one source is a useful way to test the estimate before committing to the full catalog.

What drives the cost of replacing an on-premises Collibra catalog?

Cost has five main components: infrastructure, connector work, glossary migration, upgrades and staffing. Infrastructure covers the Kubernetes cluster or hosts, the metadata database, and the search and streaming services, which recur monthly in your cloud or data center. Connector setup is largely one-time per source, but it grows with the number of systems and any custom lineage you must rebuild, since Edge connectors do not transfer directly. Glossary migration is one-time and depends on how many terms, relations and approval workflows you carry over. Upgrades and staffing recur. Ask any provider for a quote that separates these components and states which items are one-time and which recur, and compare that against your current Collibra subscription and Edge costs.

Can we do this migration with our own team alone?

Some teams can, particularly if they already run Kubernetes, a relational database and Elasticsearch, and have a steward group ready to define the target model. The harder parts are usually the migration of relations and workflows that do not transfer one-to-one, validation of lineage, and the first upgrade cycle. Consider a fixed-scope engagement for the plan, the deployment and the cutover, then hand over operations with runbooks. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, and supports them through retainers, so you can choose which phases to keep in-house.

Does a managed OpenMetadata or DataHub tier break the on-premises constraint?

Usually yes, if the managed tier runs in the vendor's cloud. Collate offers managed OpenMetadata, and DataHub Cloud is the managed product from the company behind DataHub, which its documentation describes as SLA-backed with no infrastructure for you to run. Both place the metadata service in the provider's environment, so they face the same residency question as Collibra SaaS. Check where the metadata is stored, which regions and subprocessors are involved, and whether any private connectivity option keeps data inside your network. If the constraint is on-premises or private cloud only, the self-hosted Apache-2.0 editions deployed in your own infrastructure are the option that satisfies it, and that choice should be confirmed with your compliance and legal teams.

How do we confirm the self-hosted catalog can be upgraded safely?

Read the release notes for each version before scheduling an upgrade, and test on a non-production copy first. OpenMetadata 2.0 changed several things that need planning: it moved embedding credentials into an llmConfiguration block, introduced a new Databricks auth format, required rebuilding custom ingestion images for Python 3.12, and asked for Great Expectations to be migrated to 1.3 before upgrading. DataHub's Helm chart runs a system-update job on upgrades to apply schema changes and reindex search when needed, so plan capacity and a maintenance window for that job. Ask your provider to document the rollback path, backup procedure and the test evidence for each upgrade, since these are the controls auditors and your own change board will ask for.

How DeployOpen deploys under an on-premises constraint

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own data center, private cloud or air-gapped network. For an on-premises Collibra replacement, that means the catalog, its databases, search indices and connectors run in infrastructure your team controls, and the work covers the parts that a SaaS vendor would otherwise run for you: cluster build, identity integration, backup and restore, patching and upgrade paths. The first decision is where the platform will run, because a Kubernetes cluster on your own hardware, a private cloud account and a bare metal footprint each change the scope of the work.

Most engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, and that document should name the catalog choice (OpenMetadata or DataHub), the database and search services, the connectors to be re-ingested from your sources, the single sign-on configuration and the backup targets. Ask for the written list of what is excluded as well as what is included, since glossary migration, steward workflows and connector authoring are often the items that expand. Ongoing support, upgrades and continuous testing are available as retainers, which suits a catalog that will receive regular releases. DeployOpen does not publish a price list, so a quote follows from the written scope.

DeployOpen prepares systems, controls and evidence for compliance assessments, such as access logs, backup test records, configuration baselines and change records for the catalog. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm early with your auditor which evidence they will accept and in what format. DeployOpen does not hold a partnership with Collate or DataHub, so any vendor support, commercial add-on or managed service question should be taken to that vendor directly.