Migrate from Collibra to OpenMetadata

Migrate from Collibra to OpenMetadata: what the move involves

Moving from Collibra to self-hosted OpenMetadata is a staged project covering data, connectors and process, not a single export and import. It usually starts with a renewal date, pressure to keep catalog metadata inside your own network (Collibra's Edge sites are one way to process data locally, but the platform itself is SaaS on AWS and Google Cloud), or the fact that Collibra ended maintenance support for on-premises environments for commercial customers on January 30, 2023. The work is led by the catalog owner and data platform engineers, with stewards responsible for the business content, and an implementation partner is useful for fixing the scope in writing before anyone exports anything. The data side has three streams. Assets and complex relations can be exported to CSV or XLSX, and that export follows the filters, columns and sorting of the table on screen, so teams should build the views deliberately and check the output against a sample before a full run. Business glossaries are loaded through OpenMetadata's CSV glossary import, which means terms, owners and relations must be reshaped to its columns first. Technical metadata should not be copied at all: re-ingest sources with OpenMetadata connectors (more than 130 are listed) and treat Collibra's Edge agents as retired once each source is verified. Confirm current connector coverage for each of your sources in the OpenMetadata documentation, since some Collibra integrations may have no direct equivalent. Risk concentrates in stewardship workflows, custom attributes and access rules, which rarely transfer in a file. Plan the target platform first: OpenMetadata's production deployments run on Kubernetes (including on-premises clusters) or bare metal, with Java 21, a PostgreSQL or MySQL database and Elasticsearch 9.x or OpenSearch 3.x as prerequisites for bare metal. Run both catalogs in parallel for a defined period, agree acceptance checks with stewards, and confirm the exact effort and schedule in a written, fixed scope rather than from any general estimate.

Which Collibra capabilities map to OpenMetadata, and where the gaps are

This table maps the main Collibra capabilities to their closest OpenMetadata equivalents and labels each as a clean fit, a rework or a gap. Use it to plan which content moves directly, which needs redesign, and which features you must confirm in a trial before committing.

Collibra capability	OpenMetadata equivalent	Status	What to confirm in your environment
Asset types and custom asset model	Entity types for tables, dashboards, pipelines, glossary terms and domains, with custom properties on supported entities	Needs rework	Confirm which custom asset types you use and map each to a supported entity or a custom property before export
Business glossaries and terms	Glossaries and glossary terms with CSV glossary import, plus definitions, owners and related terms	Clean	Test the CSV import with a sample export, including term relations and synonyms, before loading the full glossary
Domains and communities	Domains for grouping assets and teams; Collibra communities have no one-to-one object and usually become domains or teams	Needs rework	Decide how each community maps to a domain, and confirm how ownership is assigned at domain level in your version
Relations between assets	Relationships are expressed through entity references and lineage edges, not a free-form relation model	Needs rework	Inventory custom relation types in your export and confirm how each one is represented after import
Technical lineage	Table, column, dashboard, pipeline and metric lineage, with OpenLineage event integration	Clean	Confirm that your pipelines emit lineage through supported connectors or OpenLineage, and that column lineage covers your critical tables
Data quality rules	Data quality tests, profiling, freshness checks and sampling on supported sources	Needs rework	Recreate Collibra data quality rules as OpenMetadata tests and confirm which rule types your sources support
Classifications and sensitivity tags	Classifications and tags applied to assets and columns	Clean	Confirm that your tagging taxonomy and any automated classification rules can be reproduced in your target version
Stewardship roles and ownership	Owners, teams and roles, with permissions set through OpenMetadata policies	Needs rework	Map each Collibra steward role to an OpenMetadata role and policy, and test access with non-admin accounts
Edge-based ingestion	OpenMetadata connectors and ingestion pipelines run in your own Kubernetes or bare metal environment, with no Edge component	Needs rework	Confirm network access from the ingestion runtime to each source, especially VPC-locked or on-premises systems
REST access and scripted reads	REST APIs, Python SDK, TypeScript packages and Java libraries	Needs rework	Rewrite Collibra API scripts against OpenMetadata endpoints and confirm authentication for each integration
Governance workflows and approvals	Workflow and approval features vary by version and add-on, so they are not a direct replacement for Collibra workflows	Gap	List every active Collibra workflow and confirm in a trial whether OpenMetadata provides an equivalent, or plan a manual or external process

What data moves out of Collibra, and which export path carries it

A Collibra move depends on four kinds of content: assets and relations, business glossaries, source connections and the governance structure around them. Each one leaves Collibra by a different path, and each path needs its own checks before OpenMetadata receives anything.

Assets and complex relations in CSV or XLSX

Collibra's documented bulk export writes assets or complex relations to a CSV or XLSX file, and the output follows the filters, columns and sorting of the table on screen. Set up the view you need before exporting, because a column hidden in the table may be missing from the file. Check that relation headers and asset IDs survive the round trip, since OpenMetadata mapping depends on them.

Scripted reads through the Core and Import APIs

Table exports are flat, so relations with several targets or nested attributes often need a scripted read instead. Collibra's Core REST API can return assets and relations as structured data, which a migration script can transform into OpenMetadata entities. Confirm the exact endpoints, rate limits and authentication method for your Collibra version with your administrator, since these details are not covered in this page.

Glossary terms through OpenMetadata CSV import

Business glossary terms, definitions, owners and related-term links can be exported from Collibra as a glossary asset list, then reshaped into the glossary CSV format that OpenMetadata imports. Map Collibra statuses and term relations to OpenMetadata fields before loading, and confirm which owner identities resolve to users in your OpenMetadata instance. Stewardship workflows and approval history do not transfer with the terms.

Source connections rebuilt as OpenMetadata connectors

Collibra Edge sites run inside the customer's network and feed metadata from on-premises sources back to the platform. OpenMetadata does not use Edge, so each source needs an OpenMetadata connector running in your environment with its own service account and schedule. Inventory every Edge-connected source first, because a source with no connector equivalent will need a custom ingestion path.

Domains and stewardship roles recreated by hand

Collibra communities, domains and steward assignments are not exported as an automatic mapping for OpenMetadata. Recreate domains and ownership in OpenMetadata, then assign owners through the bulk paths that exports make possible. Record each Collibra role and its permissions in a mapping sheet so reviewers can confirm that access in OpenMetadata matches the original intent.

Lineage and quality history as a validation gap

Table exports carry asset and relation records, but they may not preserve the full history of lineage runs, quality results or workflow comments. Decide which of these records you must keep for audit, export them separately, and store them outside the new catalog if OpenMetadata will not hold them in the same form. Ask your compliance lead which evidence must be retained before the Collibra tenant is closed.

Migration sequence from inventory to decommission

This sequence moves a Collibra catalog into a self-hosted OpenMetadata instance one domain at a time, proving each stage with reconciliation before stewardship and connectors cut over. It ends with Collibra decommissioned only after retention and audit evidence is secured.

Inventory assets, relations, glossaries, roles and sources
Catalog owners, the governance lead and the platform team list every asset type, relation type, glossary, domain, community, steward role and source connection in the current Collibra environment. Record which items are actively used, which are stale and which carry regulatory retention obligations. The output is a signed inventory with a mapping sheet that lists each Collibra object and its intended OpenMetadata counterpart, including the items that will have no direct equivalent and need a documented workaround.
Export a pilot domain from Collibra
Choose one business domain with a bounded set of assets and glossary terms. Export its assets and complex relations to CSV or XLSX from the Collibra table views, making sure the filters, columns and sorting on screen match the fields you need, and use the Core REST API where scripted reads are required. Validate row counts and identifiers against the inventory. The output is a versioned export package for the pilot domain, stored in an approved location with access restricted to the migration team.
Stand up a pilot OpenMetadata instance
The platform team deploys OpenMetadata in your own environment, either on Kubernetes with the Helm charts (on Amazon EKS, Azure AKS, Google GKE or on-premises clusters) or on bare metal, following the documented prerequisites for Java, the database and the search service. Confirm the current minimum sizing and version in the deployment documentation before provisioning. Load the pilot domain through the glossary CSV import and the asset loading path, then review the results. The output is a working pilot instance with the domain loaded, a documented deployment baseline and a record of any import errors fixed.
Run a parallel period with reconciliation
Keep Collibra as the system of record while the pilot domain is maintained in both catalogs. Stewards compare asset counts, glossary term definitions, owners, domain assignments and relations between the two systems, and log each discrepancy with a disposition. Re-export from Collibra on a fixed schedule agreed by the governance lead so differences are tracked, not guessed. The output is a reconciliation report per domain that shows zero open discrepancies or an accepted list of known gaps signed by the data owner.
Re-ingest sources and cut over connectors
Replace Collibra Edge-based collection with OpenMetadata connectors for each source system, configuring them inside your network with credentials held in your own secrets store. Run ingestion, check lineage coverage against the pilot inventory and confirm that profiling and data quality configurations match the stewardship intent. Where a source has no supported connector, record it as a gap and plan an alternative such as OpenLineage events or a custom ingestion job. The output is a connector register with owners, schedules and a passing ingestion run for every source in scope.
Cut over stewardship roles and workflows
Recreate domains, ownership and steward roles in OpenMetadata using the mapping sheet, then move stewards for each completed domain to the new instance and confirm they can perform their daily tasks. Document which Collibra workflows, approvals or attestations have no direct equivalent and agree interim manual processes with the owners. Repeat the cutover domain by domain until all in-scope areas are covered. The output is a signed cutover record per domain showing the steward roster, access groups and the workflow replacements in use.
Decommission Collibra after evidence is secured
Before turning off Collibra, archive a final full export, the reconciliation reports, the cutover records and the access and configuration history to storage that meets your retention rules, and confirm the retention period with your legal and compliance owners. Ask your auditors which evidence they expect to see for the migration and the decommissioned system. Only after that evidence is accepted, disable Collibra access, remove connectors and close the subscription or on-premises support as contracts allow. The output is a decommission certificate covering the archive location, the evidence list and the date access ended.

How the parallel run and cutover work

Run both catalogs for a defined period before anyone switches off Collibra. During the parallel run, the same sources feed OpenMetadata through its connectors while Collibra keeps receiving its usual Edge ingestion. Compare counts of databases, schemas, tables, columns, glossary terms, domains and owners between the two systems for the same sources, and record every mismatch with a reason, such as a filter that excludes a schema or a term that was never exported. Glossary terms need a line-by-line check against the CSV import results, because definitions, related terms and steward assignments are the content most likely to drift silently. Confirm how long the parallel run must last with your governance lead, your audit team and the business owners of each domain. That period depends on how often stewards change definitions, which approval workflows still run in Collibra, and how many downstream reports depend on catalog metadata. Do not assume a fixed duration from another team's project.

Redirect users and integrations in a deliberate order. Start with read access: publish the OpenMetadata URL to stewards and data consumers, and keep Collibra visible for their existing bookmarks and saved reports. Then move write work, such as new glossary terms, ownership changes and certification requests, to OpenMetadata once stewards have been trained on its roles and domains. Inventory every script, scheduled job, API client and webhook that calls Collibra's REST endpoints, and repoint each one to the OpenMetadata API only after its output has been compared with the Collibra version. Any tooling that writes to both systems during the overlap needs an owner, because two writable catalogs will diverge quickly.

Keep a read-only Collibra instance after cutover for lineage questions and audit. Auditors and incident responders often ask what a report looked like, who approved a term, or where a number came from on a past date, and those answers may exist only in Collibra's history. Decide with your compliance team which exports, screenshots or read-only access satisfy those requests, and document where the retained evidence is stored and who can open it. Confirm with Collibra what your contract and environment allow for read-only access and for how long, because this is a commercial term that your agreement governs, not something this page can assume. Set a retirement date for that access only after the audit and records retention requirements in your own policy are signed off.

What drives cost and duration

A Collibra exit costs less in licences than it does in the work around them. The cards below separate the subscription you stop paying from the infrastructure, connector, glossary, upgrade and staffing work you take on, and name the drivers that push each one up or down.

Subscription exit and overlap period

The Collibra subscription is the cost you stop, but the timing is what matters. Running Collibra and OpenMetadata in parallel during validation means paying for both, so the overlap length is a cost decision. Ask your Collibra account team in writing for the end date, the export support available during notice, and what happens to data after the term ends. Shorten the overlap by fixing the export and glossary load steps before the renewal date, not after.

Asset volume and relation complexity

Export and load effort grows with the number of assets and the number of relations between them. Each relation type in Collibra needs a mapping to an OpenMetadata equivalent, and a single high-volume asset type with many relations can dominate the load window. Profile your catalog first: count assets by type and count relations by type. Export in batches by domain so failures are isolated and re-runs stay small.

Custom asset types and workflows

Custom asset types, attributes and approval workflows in Collibra have no one-to-one counterpart in OpenMetadata, so each one needs a design decision: map it to an existing entity, model it with custom properties, or retire it. Every custom type you keep adds schema work, validation and testing. Inventory these types early and mark each as map, rebuild or drop before estimating build hours.

Sources that need new connectors

Sources that Collibra reached through Edge or custom ingestion need an OpenMetadata connector, a service account and network access from the OpenMetadata side. A source with a supported connector and a standard credential is routine; a legacy or custom source may need a scripted ingestion path. Sort sources into supported, configurable and custom, and confirm each connector version against the OpenMetadata connector list before scheduling.

Stewardship redesign and glossary load

Stewards, owners and approval steps must be re-created as OpenMetadata ownership, domains and glossary roles, and Collibra workflow history does not carry over. Glossary terms are the easier part once exported to CSV or XLSX and loaded through the glossary import. The cost driver is the decision work: who owns each domain, who approves a term, and which steps are retired. Agree these rules with business stewards before the load starts.

Infrastructure, upgrades and the people who run it

Self-hosting moves hosting cost, upgrade effort and on-call duty onto your team or an implementation partner. OpenMetadata's bare metal documentation sets minimum sizing for the server and for its database and search services, and production sizing will be larger. Upgrades carry breaking changes, so each release needs a test environment and a rollback plan. Ask for the named owner, the upgrade cadence and the backup approach in any scope.

How the migration changes by starting point

If Collibra is the SaaS platform and most of your sources are cloud warehouses, BI tools and pipelines, the migration is mainly a data movement and rebuild exercise. You export assets and relations from the Collibra table views to CSV or XLSX, or script reads through the Core and Import APIs, then load them into OpenMetadata. Your technical metadata is usually simplest to re-create because OpenMetadata connectors can read the same sources directly, so you do not need to copy Collibra's ingested copies.

Connector re-creation: List every source Collibra ingests from and confirm that OpenMetadata lists a connector for each one. Test credentials and scopes against a non-production run first.
Lineage sources: Pipelines that feed Collibra through a lineage integration may need OpenLineage events or a different connector. Confirm this per source.
Export scope: Exports follow the filters, columns and sorting of the table on screen, so build a saved view per asset type before you export.
Hosting decision: Your new OpenMetadata instance runs in your own Kubernetes cluster or cloud account, which moves metadata storage out of the vendor's cloud.
Access model: Recreate roles and domain ownership in OpenMetadata before users log in, because SaaS permissions do not transfer automatically.

Before cutover, ask your team to compare asset counts and ownership fields between Collibra exports and OpenMetadata for a sample of each asset type.

Questions buyers ask before moving from Collibra to OpenMetadata

What does a migration from Collibra to OpenMetadata cost?

The cost is a mix of one-time migration work and recurring infrastructure and staffing, and no supplied figure sets the total for your estate. The one-time parts are exporting Collibra content, rebuilding domains and stewardship roles, writing connector configurations, loading glossaries and testing. The recurring parts are the Kubernetes or server infrastructure, the database and search services, upgrades and the people who run the catalog. Your size, the number of sources and how much governance workflow you rebuild drive each line. Ask any provider for a written quote that lists these components separately, so you can compare it with your current Collibra subscription and Edge costs.

How long does it take to move from Collibra to OpenMetadata?

The duration depends on the scope you agree, and no supplied figure gives a standard timeline. The biggest variables are how many assets, relations and glossary terms you export, how many sources need new OpenMetadata connectors, how many Collibra workflows must be redesigned and how much validation your stewards and auditors require. A parallel run, where Collibra and OpenMetadata both serve users for a period, adds time but lowers cutover risk. Confirm the timeline in writing before work starts, along with the milestones that mark each stage.

What does my team need to provide for the migration?

You need named owners who can decide how Collibra concepts map to OpenMetadata, including domains, data owners, stewards and glossary approvers. You also need engineers with access to every source system so connectors can be configured and credentials managed, and someone who can run a self-hosted platform after handover. Plan for business reviewers to check exported glossary terms and lineage against what users expect. Ask your provider to list these roles in the scope document so you can assign people before the work begins.

Can our own team migrate from Collibra to OpenMetadata without an outside partner?

Yes, a capable internal team can do the work, since OpenMetadata is Apache-2.0 licensed and its REST APIs, Python SDK and CSV glossary import are open for use. The main questions are capacity and skills: exporting from Collibra, deploying on Kubernetes or bare metal, configuring connectors, and operating the platform after cutover. Many teams split the work, keeping business content review in-house and bringing in outside help for deployment, hardening and connector setup. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your own infrastructure under a written, fixed scope, which is one option to compare with doing it internally.

Which Collibra workflows have no direct equivalent in OpenMetadata?

Some Collibra workflows will need redesign, and you should inventory them before choosing a target. Start with approval workflows, custom asset types, operating model rules and any stewardship process tied to Collibra-specific roles. OpenMetadata supports glossaries, classifications, domains, ownership, data quality tests and lineage, so those areas map most directly. OpenMetadata 2.0 also added custom intake forms, which can cover some request flows, but you should confirm each workflow in a proof of concept rather than assume a match. Record every gap so the business can accept it, rebuild it or keep a separate process for it.

How does Collibra Edge get replaced when we re-ingest sources?

Collibra Edge processes metadata inside your network, while OpenMetadata connectors run as ingestion jobs that you deploy and schedule in your own environment. OpenMetadata lists more than 130 connectors for warehouses, BI tools, pipelines and ML platforms, and it also supports OpenLineage events from pipelines. For each source, confirm that a connector exists, that it can reach the source from your network, and that its credentials and permissions are handled according to your policy. Sources without a connector will need a custom approach, so identify those early.

Does OpenMetadata need a managed service, or can we self-host it?

OpenMetadata can be self-hosted. The project documents production deployment on Kubernetes, including Amazon EKS, Azure AKS, Google GKE and on-premises clusters, and on bare metal without Kubernetes. Its bare metal prerequisites include Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. Collate offers managed OpenMetadata, commercial support and AI features, so a managed option is available if you want one. Choose based on your staffing, data residency rules and upgrade capacity, and confirm the chosen platform's current requirements in the official deployment documentation.

What to confirm with Collibra and OpenMetadata before you commit

Before you commit to the migration, confirm the export ceiling for your own asset volume. Collibra's documented bulk path is a CSV or XLSX export that follows the filters, columns and sorting of the table on screen, so a large estate may need to be exported in several filtered passes. Ask Collibra, in writing, whether a single export has a row or file size limit in your tenant, and test a representative slice before you plan the full run. Then confirm that the Core REST API and Import API cover every object type you need, including relations, communities, domains, custom asset types, responsibilities and any workflow or stewardship data that you intend to carry over. Coverage of the API is the question that decides whether the migration is a scripted job or a manual rebuild.

Next, check the target side. Read the OpenMetadata release notes and breaking change notes for the exact version you will deploy, not the latest release. The 2.0 notes list changes that affect deployments, including the move of embedding credentials into an llmConfiguration block, a new Databricks auth format, rebuilt custom ingestion images for Python 3.12, and a Great Expectations 1.3 migration that must happen before upgrading. Confirm the bare metal or Kubernetes prerequisites for your chosen version with your platform team, and decide whether you will run the glossary CSV import and connector ingestion in a staging instance first. If you use Collate's managed offering or its AI features, get the license terms, support scope and data handling commitments in writing, because they are separate from the Apache License 2.0 that covers the open-source project.

Finally, confirm your data residency and access requirements before any metadata leaves Collibra. Catalog exports can contain owner names, steward assignments, lineage that reveals system topology, and descriptions of sensitive data sets, so classify the export files and decide where they are stored, who can read them, and how they are deleted after loading. Confirm that the OpenMetadata instance, its database and search service will sit inside the networks and regions your policies require, and that connector credentials for each source will be held in a secrets store you control. Record the answers in the migration plan so that the auditors and data owners can trace each decision.

How DeployOpen scopes and runs the Collibra to OpenMetadata migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so OpenMetadata runs in your cloud account, data center or air-gapped network. Engagements are fixed-scope, with the export path, glossary load, connector setup and handover agreed in writing before work starts.

How we scope

Inventory the Collibra assets, relations, domains, communities and roles that the written scope will cover.
Confirm which export method applies to each object type, using CSV or XLSX tables or the Core REST API.
Agree which Edge-processed sources will be re-ingested with OpenMetadata connectors, and which will be retired.

How we build

Deploy OpenMetadata on Kubernetes with Helm or on bare metal, sized to the prerequisites in the agreed design.
Load business glossaries through the glossary CSV import, then re-create domains and stewardship roles in OpenMetadata.
Re-ingest sources with OpenMetadata connectors and test lineage, ownership and classification results against Collibra before cutover.

How we hand over

Document the export scripts, import files, connector configurations and the mapping from Collibra objects to OpenMetadata objects.
Provide runbooks for deployment, backup, restore and the OpenMetadata upgrade path, including breaking changes listed for the target release.
Walk your administrators and data stewards through the new catalog and record what did not transfer from Collibra workflows.

How we support

Support after handover can be covered by a retainer for upgrades, patches and continuous testing of the catalog.
Retainers can cover ongoing connector maintenance as sources change, with the scope agreed in writing.
Ask for a quote built from the written scope so cost components, recurring work and responsibilities are explicit.

Migrate from Collibra to OpenMetadata