Exporting your Collibra data: what the documented paths cover
If a renewal, a pricing change or a data residency requirement means your catalog has to leave Collibra, start by separating what the platform can hand over as files from what it keeps in workflow state. The documented bulk path is table-based export: Collibra exports assets or complex relations from a table view to CSV or XLSX, and the file follows the table's filters, columns and sorting. Build the views you need before you export, because the output only contains what is on screen. For scripted reads, the Core REST API is the supported route for custom integrations, and the Import API covers loading large volumes into Collibra, which matters only if you are moving content in both directions. Note that on-premises Collibra support for commercial customers ended on January 30, 2023, so a self-hosted exit is a migration, not a version rollback.
Relation exports need the most care. Since Collibra 2023.05, relation columns use headers of the form [Source asset type] role [Target asset type], which is what makes a re-import more accurate. Keep that header format in your target loader, and test one relation type end to end before running a full export. Assets, glossary terms and their relations are exportable in this way, but workflow state, approval history, stewardship assignments tied to running workflows, and access configuration are not clearly part of a table export. Confirm with Collibra, in writing, exactly which workflow objects and configuration items your version can export and which must be recreated. Your own export inventory should list each item as transferred, rebuilt or retired.
Plan the handoff before you choose a target. Load the CSV or XLSX output and the REST API results into OpenMetadata or DataHub in a test environment, then compare asset counts and relation counts against the Collibra source for each domain. Ask Collibra and your target vendor to confirm supported export volumes, rate limits and API permissions for the account that runs the scripts. Keep the exported files in encrypted storage under your own control, record who accessed them, and treat them as governed metadata that may still describe sensitive systems.
Which Collibra data can be exported, by method and format
This table compares the export routes for assets, complex relations, glossary content, communities and domains, and the Core REST API. Read each row for the method, the output format and the limits that carry into a migration. The main takeaway is that table exports follow the view on screen, so the scope of each export depends on how the table is set up.
| Collibra data | Export method | Output format | Limits to plan for |
|---|---|---|---|
| Assets from a table view | Table export of selected assets | CSV or XLSX | Follows the table's filters, visible columns and sorting, so set the view before exporting |
| Complex relations | Table export from a relations view | CSV or XLSX | Relation columns use the header form [Source asset type] role [Target asset type] since Collibra 2023.05 |
| Glossary terms and definitions | Table export of glossary assets | CSV or XLSX | Confirm which attributes and relation columns are included in the view for your version |
| Communities and domains | Table export or Core REST API read | CSV, XLSX or JSON | Check how hierarchy and parent links appear in each format before relying on them |
| Assets, relations and attributes by script | Core REST API for scripted reads | JSON from API responses | Paging, rate limits and volume limits should be confirmed with Collibra for your version |
| Bulk loads back into Collibra | Import API | Files prepared outside the table export | Not an export route; listed only so teams do not confuse it with the Core REST API |
What does not come out as a plain export and how to handle it
The table export from Collibra carries assets, relations and their visible columns, but it does not document carrying over everything the catalog holds. The cards below cover the items most likely to be lost in a move to OpenMetadata or DataHub, with a documented path to recover each one and the questions to put to Collibra before you decommission anything.
Workflow definitions and history
Collibra workflows (approval and stewardship steps, their configuration and the record of past runs) are not part of a CSV or XLSX export. Export the workflow instances you still need for audit through the Core REST API and store them as files alongside the migration record. Rebuild the active steps as ownership and approval rules in the target, because neither OpenMetadata nor DataHub runs Collibra's workflow engine unchanged. Ask Collibra which workflow artifacts their export tooling covers and in what format.
Roles, permissions and responsibilities
Community and domain roles, global roles and asset-level responsibilities are access configuration, not table columns, so a filtered export will not list who may edit what. Read role assignments through the Core REST API and map them to owners, stewards and domain membership in the target. Confirm with Collibra which role and responsibility objects the API returns for your version, and whether any resolve to users who no longer exist in your identity provider.
Edge-processed lineage state
Where Collibra Edge ran ingestion or lineage processing inside your network, the lineage it produced may exist only as catalog relations, with the job logic and its schedule held on the Edge site. Export the lineage relations you can see, then confirm with Collibra how Edge stores this state and whether it can be read outside the platform. Re-ingest the source technical metadata with OpenMetadata or DataHub connectors and compare the rebuilt lineage against the exported relations before retiring the Edge site.
Comments and attachments
Discussion threads on assets and files attached to assets are typically not part of a relation or asset table export. Pull comments and attachment references through the Core REST API, where the endpoints and their output format are documented, and keep the binary files in your own object storage with a stable reference back to each asset. Ask Collibra whether attachment content is retrievable through the API for every asset type, and what size limits apply to downloads.
Custom asset types and attribute configuration
Custom asset types, their attribute definitions, validation rules and relation types define how your data was modeled, and a table export only shows the values stored against them. Export the type definitions through the Core REST API, then recreate them as custom entity types or glossary term attributes in the target. Record any type that has no direct equivalent so the governance team can decide how to represent it before the move.
Historical versions and audit trail
Collibra keeps change history for assets, which a table export of current values does not include. Decide with your compliance owner which history must be retained, then request the audit records through the Core REST API or the Collibra administrator and store them outside the new catalog. Confirm with Collibra how far back history can be retrieved, because retention settings differ between deployments and the target catalogs keep their own change logs from the point of import.
The sequence for a complete export, with verification at each step
This sequence takes the Collibra catalog from a full inventory to a checksummed, verified set of exports that can be loaded into OpenMetadata or DataHub without guessing what was lost. Each step ends with a written output that the next step depends on.
Inventory asset types, views and relations
The catalog administrator lists every asset type in use, the communities and domains that hold them, the saved table views that people rely on, and the relation types linking assets, such as ownership and glossary terms. Record the approximate asset count per type from the Collibra UI so you have a baseline. The step is complete when the inventory sheet covers every type and view, and the governance lead has signed off that nothing important is missing.
Set up filtered table exports per asset type
For each asset type and for the glossary, open a table view and apply the filters, columns and sorting you need. Collibra exports assets or complex relations from table views to CSV or XLSX, and the export follows those filters, columns and sorting, so a view that hides a column will also hide it in the file. Name each saved view after its asset type so the export files can be traced back. The step is complete when each view shows the columns the target schema needs.
Export relations with their role headers
Export complex relations as separate files from the relation views. Since Collibra 2023.05, relation columns use headers of the form [Source asset type] role [Target asset type], which keeps the direction and role of each link clear for re-import. Check the header row of each file before you move on, because a missing type name will make the relation harder to rebuild later. The step is complete when every relation file has headers in that format.
Read what tables cannot cover through the Core REST API
Some metadata, such as attribute values across many assets, nested structures or items outside a table view, may not appear cleanly in a CSV or XLSX export. For those, use the Core REST API from the Collibra developer portal in a scripted read, paging through results and writing JSON or CSV locally. The engineer running the script should keep a log of the query used for each dataset. The step is complete when each gap identified in step one has either a scripted export or a documented reason it is out of scope.
Store exports with checksums and a manifest
Move the files into a dated folder on a storage location inside your own environment. Generate a SHA-256 checksum for every file and write a manifest that lists file name, asset type, row count, the view or query used and the export time. Store the manifest with the files so that anyone can confirm later that a file has not changed. The step is complete when the checksum file validates against the stored files on a second machine.
Compare counts and sample records against Collibra
Before any load, compare the row count in each file with the count shown for the same view in Collibra, and note any difference with its cause. Then pick a sample of assets from each type, including assets with many relations, glossary terms with long definitions and assets with special characters, and check their attributes, owners and relations against the live catalog. The governance lead should approve the discrepancy log. The step is complete when every count matches or has a recorded explanation, and every sampled record matches the source.
Confirm the export is complete before loading
Run a final pass that confirms the manifest, checksums, discrepancy log and sample results all refer to the same export date. Keep the Collibra instance read-only for the agreed cutover window or record a change timestamp so later edits can be captured in a delta export. Confirm with the target team, either OpenMetadata or DataHub, which file formats and header conventions their import expects. The step is complete when the signed-off package is ready to load into the target catalog.
Loading the export into OpenMetadata or DataHub
Plan the load as a mapping exercise before anyone runs an import. The CSV or XLSX output from Collibra is a flat table, so each column must be assigned a destination in the target catalog. In OpenMetadata, business terms and their definitions map to glossary and glossary term records, which can be loaded through the glossary CSV import, while tables, columns and dashboards are better handled by re-ingesting the source systems with OpenMetadata connectors and then attaching the exported owners, descriptions and tags to those assets. In DataHub, communities and domains map to DataHub domains, and glossary content is written into the YAML business glossary source. Decide, for each Collibra asset type, which of these two paths it takes, and record that decision in a mapping table that your data governance team signs off.
Relation headers in the export are the part of the file that most affects re-import accuracy. Since Collibra 2023.05, relation columns use the form [Source asset type] role [Target asset type], which tells a reader exactly which end of a relation each column describes. Use these headers to build the crosswalk from Collibra relation types to OpenMetadata or DataHub relationships, and keep the exact header strings in a version-controlled file so the mapping can be reviewed. Custom attributes, stewardship roles and any workflow states have no automatic equivalent in either target. Each needs a named destination, such as an OpenMetadata custom property or a DataHub structured property, a steward assignment, or a documented decision to retire the field. Test the mapping on a filtered export of a few domains first and check the results against Collibra before running the full set.
The loaded metadata will live wherever you deploy the target catalog. OpenMetadata documents production deployments on Kubernetes, including on-premises clusters, and on bare metal, which requires Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. DataHub is deployed with its Helm charts following the DataHub Kubernetes deployment guide, which needs Kafka, a supported relational database, a search index and a graph index. Confirm with your platform team which option fits your data center or private cloud, and size the database and search tiers against the export volume you expect to load, since neither source publishes a sizing rule for your specific catalog.
Which export path fits your situation
If you only need business terms, definitions and their owners, the table export is usually the simplest route. You open the glossary view in Collibra, set the filters and columns so they show the attributes you need, and export the assets to CSV or XLSX. Because the export follows the table's filters, columns and sorting, a clean view produces a clean file. The work is mostly in the spreadsheet: checking that every term has a name, definition and steward, and that synonyms and related terms are present before you load them into the target tool.
- Tooling: the Collibra table export, a spreadsheet editor and the target's glossary import, such as OpenMetadata's glossary CSV import or DataHub's business glossary source.
- Skills: a data steward who knows the terms, plus someone comfortable cleaning CSV files.
- Recurring work: one export per refresh, so rerun the same saved view if terms change during the project.
- Limit: stewardship workflows and approval history do not transfer through a table export.
- Check with Collibra: which attributes your table view can expose on your Collibra version and whether your edition allows bulk export for your role.
Confirm the export columns and the glossary field mapping with a sample before you export the full set.
A full catalog includes assets, their attributes and the relations between them, such as a dataset that feeds a report or a term linked to a column. Relations need more care than flat assets. Since Collibra 2023.05, exported relation columns carry headers in the form [Source asset type] role [Target asset type], which helps re-importing resolve both ends of each link. You export the asset and relation tables separately from the table views, then combine them in a script or a staging database so that identifiers line up across files.
- Tooling: CSV or XLSX table exports for each asset type, plus Core REST API reads to fill gaps such as relation details the table does not show.
- Skills: a data engineer comfortable with joins on identifiers, and a governance lead who can judge whether a relation is still correct.
- Recurring work: a reconciliation step to catch assets renamed or moved between exports.
- Limit: the table export only covers what the view displays, so check each asset type before you assume completeness.
- Check with Collibra: which asset types and relation types your instance uses, and whether custom attributes appear in exports.
Run a small sample across each asset type and confirm that relation counts match what the UI shows.
When the catalog is large, or you need to export more than once to test the target and cut over, scripted reads through the Core REST API are more dependable than manual exports. A script can page through assets, record the timestamp of each run and produce the same files every time. This also makes it possible to compare runs, so you can confirm that a second export matches the first before you cut over. Collibra's APIs also include an Import API for large volumes, which is relevant to the reverse direction, but for reading out your catalog the Core REST API is the path to plan around.
- Tooling: scripts that call the Core REST API, a scheduler or CI job to run them, and object storage or a database for the output.
- Skills: a developer who can handle authentication, pagination and rate limits, and an engineer who can write the mapping into the target's ingestion format.
- Recurring work: repeated runs for test loads and a final delta export at cut over.
- Limit: API access and scope depend on your license and role, so the script cannot assume what it can read.
- Check with Collibra: the authentication method for your deployment, API rate limits and the endpoints available to your edition.
Document each run's record counts so you can reconcile the target against the source.
What to plan before the Collibra contract renewal or termination
An export is only as good as the time and access around it. The cards below cover the decisions that shape a clean exit from Collibra, from the start date and retention terms to the staff time needed for sign-off. Each one connects back to the export steps on this page.
Start exports before the notice date
Work back from your contractual notice deadline and treat the first full export as a rehearsal, not the final run. Export a sample of asset types first, then check the files against the source views. Leave room to re-run exports after filters, columns or sorting are corrected, since the export follows what is on screen. Confirm the notice period and renewal terms with Collibra in writing, not from memory.
Confirm retention and deletion in writing
Ask Collibra, in writing, how long your tenant data is retained after termination, when it is deleted, and whether backups are covered by the same timeline. Ask for the deletion evidence you will receive and who signs it off. Your exports are only a copy, so the contract terms define how long you can rely on the source for reconciliation.
Freeze governance changes during export
Agree a change freeze on glossary terms, domains, communities and relation types for the export window. Stewards editing assets mid-export produce files that do not match each other, and relation headers may shift if asset types are renamed. Record the freeze date and the export timestamp so that every file can be traced back to one state of the catalog.
Keep read access through verification
Keep read access for the people who verify the export until the target catalog is signed off, and do not let access lapse at the notice date. Verification often needs to reopen a source view to compare a count or a relation. Confirm which accounts, roles and Edge-connected sources need to stay active, and plan how read access will be removed afterwards.
Budget internal staff time
Name the people who will map asset types, review relation exports, and sign off each glossary and domain. Most of the effort sits with stewards and catalog owners, not with the export itself. Ask your implementation partner for a written scope that lists these review tasks, and confirm how many hours each owner needs to set aside before the notice date.
Questions teams ask before exporting from Collibra
How much effort does a full export from Collibra take?
The effort depends mostly on the size and shape of your catalog, not on the export format itself. Collibra's table export writes assets or complex relations to CSV or XLSX, and it follows the filters, columns and sorting you have applied on screen, so each asset type, community and domain you want out needs its own pass. The main drivers are the number of asset types, how many relations link them, how many custom attributes and workflows carry governance content, and whether you also script reads through the Core REST API. Ask any quote to break the work into these components: inventory, export runs, field mapping, validation against the target platform, and the load itself. No duration is stated here because none is supported by a source you can rely on, so ask for one in writing against your own export.
Can an internal team export from Collibra without outside help?
Yes, a team with Collibra administrator access and someone who can read the target platform's import formats can run the table export themselves. The export is a documented function of the catalog interface, so the first pass needs no custom code. Outside help becomes useful when you need repeatable scripted reads through the Core REST API, a mapping of Collibra communities, domains and roles to the target model, or validation of relations after re-import. DeployOpen plans, implements and documents this kind of work under a written, fixed scope if you prefer to hand it over, and ongoing support is available as a retainer.
What do data owners and stewards need to provide during the export?
Export is a technical task, but its accuracy depends on the people who know the content. Stewards should confirm which asset types, statuses and attributes are current, and which draft or deprecated assets should be excluded. Data owners should approve the scope of business terms, owners and lineage that move to the new platform. Without this sign-off, an export can carry stale definitions into a new catalog. Plan for these reviews before the export runs, and record decisions so that the migration can be audited later.
Do relations and glossaries export completely from Collibra?
Relations and glossary content can be exported, but you should verify completeness rather than assume it. Since Collibra 2023.05, exported relation columns use headers in the form [Source asset type] role [Target asset type], which helps when you re-import because the source and target types are explicit. Glossary assets export through the same table path, and their relations depend on the columns you include. Check the export against a sample of assets, confirm that every relation type in use appears in a column, and confirm which workflow states, comments and attachments are not included in a table export.
What should we confirm with Collibra about formats and limits?
Confirm these points with Collibra in writing or in your contract documentation before you rely on the export:
- Maximum number of rows and file size for a single CSV or XLSX export
- Which asset attributes, workflow data, comments and attachments are included
- Whether the Core REST API and Import API limits apply to your environment
- Supported character encodings and how multi-valued fields are represented
- Any rate limits or licensing terms that affect scripted reads
Ask for these answers as part of your quote, so the scope reflects your actual tenant and not a general description of the product.
What changes if we run on-premises Collibra?
Collibra ended maintenance support for on-premises environments for commercial customers on January 30, 2023, and states it will continue to support on-premises environments for the public sector. If you run on-premises Collibra as a commercial customer, confirm your current support status and any end-of-life plan with Collibra before scheduling an export, because the timing of your cutover depends on it. Your export method does not change for on-premises instances, but your risk profile does: once support ends, you carry the continuity risk, so an export that you can repeat and validate becomes more important.
Which target should we load the export into, and how is it checked?
OpenMetadata and DataHub are both self-hosted, Apache-2.0 licensed options that can receive governance content from a Collibra export after mapping. Validation should compare asset counts, relation counts and glossary term counts between the export and the target, then sample records for owner, description and relation accuracy. Load the export into a non-production instance first, and keep the original export files under your retention policy. Technical lineage and connector-based metadata usually come from re-ingesting sources rather than from the Collibra export, so plan that separately.
Does exporting Collibra data put sensitive metadata at risk?
A catalog export can contain sensitive descriptions, owner names, classifications and data source details, so treat the export files as confidential records. Store them inside your own environment with access limited to the people running the migration, and delete working copies when the load is verified. Confirm with your security and compliance teams how exported files are classified, encrypted at rest and logged. DeployOpen can prepare these controls and their evidence for a compliance assessment, but independent auditors and certification bodies issue any audit report or certification.
How DeployOpen scopes and delivers a Collibra export and migration
DeployOpen plans the export as a fixed-scope piece of work, agreed in writing before any data leaves Collibra. We then build, test and document the extraction and loading into your chosen self-hosted catalog, inside your own infrastructure.
How we scope
- Inventory which asset types, relations and glossaries the export must cover, using the table views your teams already rely on.
- Confirm the Collibra version and whether your export runs through table CSV or XLSX files, the Core REST API or both.
- Agree the target catalog, hosting location and the deliverables in a written scope before work starts.
How we build
- Build repeatable exports that follow agreed filters, columns and sorting, and check relation headers against the target import format.
- Script Core REST API reads where bulk table exports fall short, and load results into OpenMetadata or DataHub in your environment.
- Test row counts, relations and glossary terms against the Collibra source, and record every mismatch with its resolution.
How we hand over
- Document the export procedure, field mappings, known gaps and the steps to rerun the extraction in your own environment.
- Provide the scripts, configuration files and test evidence so your team can repeat or audit the export without us.
- Walk your data owners and catalog administrators through the loaded content and the open items that need a decision.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the handover.
- Ask for a quote that separates the export work, the target platform setup and any later upgrade or support work.
- Confirm with the vendor and in your own environment which Collibra export limits and API quotas apply to your instance.
