Export your catalog from Microsoft Purview

How to export your catalog from Microsoft Purview: what comes out and what does not

Taking your catalog out of Purview Unified Catalog is not a one-click job. There is no single export button, so the work is a set of API-based reads of the Data Map plus rescanning the sources you already connected. A renewal, a billing change or a residency requirement usually forces the decision, but the technical question is narrower: which parts of the catalog can be read as structured data, and which parts must be recreated by hand in the target platform. Start by inventorying what you govern today (collections, glossary terms, classifications, owners, data products and data quality rules) so you know which items have an API path and which do not.

Through the Atlas-compatible Data Map APIs, you can read entities (tables, files, columns and their attributes), glossary terms with their definitions and links, and lineage relationships between assets. Those three groups are the material that carries over most directly into OpenMetadata or DataHub. Owners and classifications usually travel as attributes on the entities or terms, so confirm with your Purview administrator which of them appear in the responses you actually receive. Data quality rules, governance workflows, approval steps, access settings and role assignments are a different category. Expect to recreate them in the target tool using its own model, and treat any Purview-specific configuration as a specification to rebuild rather than data to copy.

The output of this work is a structured copy of your metadata, not a backup of the Purview service. It does not restore Purview, and it does not capture history, audit trails or the state of every workflow. Before you cut over, run a reconciliation: compare entity counts, glossary term counts and a sample of lineage paths between Purview and the new platform, and have data owners sign off on a representative set of assets. Keep the Purview account read-only until that sign-off is complete, and confirm your contract's notice and data retention terms so the read window is not cut short.

Which Purview objects can be read out, and by which path

This table maps each Purview object type to the API path that returns it, the JSON output your team would write to files, and the limits to confirm before you plan an export. Use it to decide which objects you can pull programmatically and which need a rescan or manual rebuild. The main takeaway is that asset metadata and lineage are the most readable, while owners, quality rules and some governance links need to be checked against your own tenant.

Object	Documented read path	Output and limits to confirm
Entities and attributes	Atlas-compatible Data Map APIs, entity and bulk lookups by GUID or qualified name	JSON entity objects with typeName and attributes. Confirm which attributes each source type returns and how custom attributes appear.
Classifications	Atlas-compatible Data Map APIs, classification fields on entities and classification definitions	JSON arrays on each entity plus a separate type list. Confirm whether classification values on columns are returned in the same call.
Glossary terms and their links to assets	Purview REST APIs for glossary and governance objects, including term-to-asset relationships	JSON term records with relationship lists. Confirm how linked assets are paged and whether term relationships need a second call.
Lineage relationships	Atlas-compatible lineage endpoints by entity GUID, with depth set per request	JSON graphs of nodes and edges. Confirm the maximum depth you can request and whether column-level lineage is returned for your sources.
Owners and contacts	Returned on entity or governance objects where the API includes contact fields	JSON contact lists, sometimes empty for older assets. Confirm per source type whether owners are in the entity payload or only in governance records.
Data products, domains and quality results	Purview REST APIs for governance objects, where your tenant exposes them	JSON records that may change between API versions. Confirm availability and schema in the current Purview API reference before scripting.

What does not export from Purview and the workaround for each

Purview's bulk export covers entities, glossary terms and lineage through its Atlas-compatible APIs, but several kinds of state sit outside that path. The cards below cover each gap, the workaround that fits it, and what to check before you decommission the Purview service.

Data quality rule definitions and history

Data quality rules, their thresholds and their run history are tied to the Purview service and its data quality processing units, and no documented bulk export covers them. Treat the rule logic as a specification to rebuild, not as data to move. Before rebuilding, export the rule definitions you can reach through the APIs and save the last run results as a dated record for your auditors. In OpenMetadata, rebuild tests on the table or column and review the new results against the old ones for a sample period.

Health and governance workflow state

Open tasks, approval steps, verification status and health findings in Purview are workflow state, not catalog metadata, and they do not export as a set. Record the open items in a spreadsheet with owner, asset, status and due date before cutover, and close or re-open them in the target tool. Confirm with Microsoft exactly which workflow objects the APIs return in your tenant, because the list can change between service releases.

Custom access policies

Data access policies, including the rules that govern who can see or request data, are enforced by Purview and the systems it connects to. They do not translate directly into OpenMetadata or DataHub. The target platforms govern discovery and ownership, while enforcement stays in the warehouse, lake or identity layer. Inventory each policy, identify the enforcing system, and recreate the rule there or document it as a control in the new catalog.

Collection and role assignments

Purview collections, their hierarchy and the role assignments on each collection determine who can edit glossary terms and approve changes. Those assignments are tied to Microsoft Entra ID groups and to Purview's own role model. Export the collection tree and role members through the available APIs, then map each role to an OpenMetadata or DataHub team or role. Check group membership at cutover, because stale assignments carry over unnoticed.

Technical metadata: rescan instead of export

Schemas, column types, row counts and pipeline definitions already exist in the source systems, so rescanning usually costs less than exporting Purview's copy and then repairing it. Point the OpenMetadata or DataHub connectors at each source, run a scan, and compare object counts with Purview's inventory for each source. Human-authored descriptions and tags are the exception: export those from Purview and reapply them after the scan.

Billing and governed-asset records

Billing records, governed-asset counts and data quality processing unit consumption belong to the Purview subscription and are not catalog content. Export the consumption reports from the Azure portal for your finance and audit files before cancellation, and keep the invoices for the period you were billed. The counts do not need to move. Use them to size the target platform by asset count and to set a baseline for the cost comparison.

Export sequence from Purview to a verified copy

This sequence produces a complete, file-based copy of your Purview catalog in a fixed schema, with a check at every step confirming that counts, sampled records and lineage match the source. Each stage can be re-run, so the copy can be refreshed before cutover.

Inventory collections, sources and asset types
The Purview administrator lists every collection in the Data Map, every registered source under each collection, and the entity types present in each source. This inventory becomes the scope document for the export and records which collections hold glossary terms, owners and classifications. The step is complete when the list matches what the portal shows in the collection hierarchy and the team has signed off on the scope in writing.
Register an app with read access to the Data Map
The Purview administrator registers a Microsoft Entra ID application, grants it read permissions on the relevant collections in the Data Map, and stores its secret in your organization's secrets manager rather than in scripts. The export runs under this identity, so access is limited to what it was granted and can be revoked without affecting user accounts. The step is complete when a test call returns entities from one collection and a denied call against a collection outside the grant confirms the boundary.
Export entities by collection and type
The engineer runs the Atlas-compatible Data Map API calls per collection and per entity type, following the continuation tokens until each query returns no further pages. Each page is written to a file with the source collection, type, qualified name, GUID and last-modified timestamp kept as fields. The step is complete when the record count per type matches the counts shown in the portal for the same collection, and any gap is explained before moving on.
Export glossary terms and their asset links
The engineer pulls each glossary with its terms, definitions, status, stewards and the assets linked to each term, writing one file for terms and one for term-to-asset links. Terms are keyed by GUID and qualified name so that links can be resolved after import. The step is complete when the term count per glossary matches the portal, and a sample of terms has its definition, steward and linked assets compared field by field against the portal view.
Export lineage per asset set
The engineer requests lineage for each exported asset set, depth and direction stated in the query, and writes source, target and process nodes as edges in a separate file. Lineage is exported after entities so that every edge can reference an asset already in the copy. Lineage that is missing or shallow in Purview is often cheaper to rebuild by rescanning the source with the target platform's own connectors, so the team should decide per source. The step is complete when a sample of edges is traced in the original source system, such as a pipeline run log or a dbt manifest, and the edge is confirmed or flagged.
Write files in a fixed schema
The engineer writes all extracts as JSON Lines or CSV files that follow one published schema, with the same field names, date formats, encoding and null handling across every type. A manifest file records the export date, the scope, the file names and the record count for each file, so the copy can be checked later without the Purview API. The step is complete when a validation script reads every file against the schema, reports zero malformed rows, and the manifest counts match the files.
Map fields to OpenMetadata or DataHub formats
The engineer maps each schema field to the ingestion model of the target platform, covering owners, classifications, glossary links, domains and data quality definitions, and records any field with no direct equivalent as a known gap. Mapping is tested by loading a small collection into a non-production instance of the target. The step is complete when the loaded sample reproduces the counts and a field-by-field comparison of sampled records shows only the gaps already documented, with the owner signing off before any production load.

How to shape Purview output for import into OpenMetadata or DataHub

The export is only useful if the identifiers survive the move. Purview assigns each entity a GUID and a qualified name, and the qualified name often encodes the source system, account, database and schema. Neither is a stable key in OpenMetadata or DataHub, which build their own fully qualified names from the connector configuration. Before writing any transform, decide where each target identifier will come from, and build a crosswalk table that maps every Purview GUID and qualified name to the target's entity reference. Keep the GUID in a custom property or a note so later reconciliation is possible, but do not use it as the join key in the target. Verify the mapping on a sample of tables from each source system, including any source whose qualified name changed when it was first registered.

Glossary links, owners and classifications need normalizing before load. Glossary links are many-to-many, so build a term-to-asset table with one row per term and asset pair, and resolve term names to the target's glossary identifiers in a separate step. Owner values in Purview can be Entra ID object IDs, group names or free text, so map them to users or teams that already exist in the target's identity source. Classifications and sensitivity labels rarely share a vocabulary across the two catalogs, so write the mapping as a reviewed table that a data steward signs off on, and record any Purview classification with no target equivalent instead of dropping it silently. Lineage edges need both endpoints resolved through the same crosswalk, and any edge whose endpoint has no match should go to an exception list.

Both targets offer a load path, so choose one before writing the transform. OpenMetadata exposes REST APIs, a Python SDK, TypeScript packages and Java libraries, which suits a scripted loader that writes glossary terms, owners and lineage directly. DataHub provides ingestion sources and APIs, so curated metadata can be emitted through its ingestion framework or APIs as well. Either way, the target's own connectors will rescan most sources, and that rescan will create the technical metadata itself. Your export therefore needs to carry only what the rescan cannot recover: curated glossary links, ownership decisions, classification mappings and lineage that falls outside what the connectors capture. Confirm the exact API endpoints and SDK versions against the target documentation for the release you deploy.

What to rescan at the source and what to export from Purview

Purview holds two kinds of content that behave differently in a move. Technical metadata can usually be regenerated by the target's connectors, while curated business content exists only in Purview and has to be extracted before the subscription ends.

Technical metadata: rescan first

Tables, columns, file paths, pipelines and their schemas are read directly from each source system, so the target platform can ingest them again with its own connectors. Rescanning usually avoids building export jobs for content that the source already describes. Confirm connector coverage for every source type in your estate before deciding, since some Purview scan rules may cover sources that a target connector handles only partly or not at all.

Glossary definitions must be exported

Business terms, their definitions, synonyms and approval status were written by stewards inside Purview and exist in no source system. Extract them through the Atlas-compatible Data Map APIs as structured data, and keep the term IDs so that links from assets can be rebuilt on import. Treat the export as the only copy until the target has been checked against it.

Owners, domains and descriptions

Asset owners, domain assignments, stewardship roles and hand-written descriptions are curated content that a connector scan will not restore. Map each Purview domain or collection to the target's domain or team model before import, because the two products organize ownership differently and an unmapped owner becomes an orphaned record.

Classifications and sensitivity labels

Custom classifications and any labels applied by stewards or rules are governance decisions, not properties of the source. Export them with the asset they apply to, and confirm whether the target can store the same classification names and rule logic, or only accept them as tags. Access control that depends on these labels needs its own review before cutover.

Lineage: rebuild some, carry some

Edges that a target can derive from query logs, pipeline definitions or the OpenLineage events are better rebuilt by ingestion. Manually curated edges, or lineage that Purview captured from sources the target does not scan, must be exported as explicit lineage records. List each edge type in a spreadsheet and mark it rebuild or carry before any import runs.

Data quality rules and results

Quality rules written in Purview and their historical results are tied to its data quality processing and do not transfer as-is. Export the rule definitions as documentation, then re-create the checks with the target's data quality tests. Keep the historical results in an archive, since the target will start a new history.

Questions teams ask before exporting from Purview

How much effort does exporting a catalog from Purview take?

The effort depends mainly on what you export and how much you need to verify, not on a single fixed figure. The main drivers are the number of collections, the size of the glossary, the volume of lineage you need to keep, and how many custom attributes and classifications your teams have added. Each of these adds scripting work and a comparison step. Purview has no one-click catalog export, so every category is read through the Atlas-compatible Data Map APIs and reshaped for the target platform. Ask your team to inventory these four categories before estimating anything, because that inventory sets most of the work.

Can our team export from Purview without outside help?

Often yes, if two conditions hold. Someone on the team needs read access to the Purview Data Map and the APIs, and an engineer needs to write and maintain API scripts that page through entities, glossary terms and lineage. The heavy part is usually verification rather than extraction: confirming that counts, owners, classifications and lineage edges in the output match what Purview shows, and deciding what to rebuild rather than copy. If your team lacks time for that comparison, or no one has run a bulk API read before, a partner can take on the scripting and checks under a written scope. Either way, a named reviewer in each data domain is required to sign off.

How long does a Purview catalog export take?

No fixed duration applies, because the timeline is set by scope and verification. Extraction of a small catalog can be quick, while a large estate with many collections, long lineage chains and heavy custom metadata needs more scripting, more reconciliation and more review cycles with data owners. Verification usually takes longer than extraction because each domain must confirm that exported terms, owners and classifications are accurate. Ask any provider to break the timeline into discovery, extraction, verification and import, and to state which of those phases depends on your data owners' availability.

What does the export need from our organization?

Three things matter most. First, API access: a service principal or account with read permissions on the Data Map, plus approval to call those APIs at volume. Second, a named data owner for each domain who can confirm glossary terms, ownership assignments and classifications before they are imported. Third, a freeze window on Purview changes, so the export reflects a stable snapshot and you can compare results against a known state. Without the freeze, edits made during extraction will create gaps that are hard to trace. Confirm these requirements with your Azure administrators and governance leads before work starts.

Can we back up Purview itself instead of exporting?

The documented route is the API read, not a service-level backup of Purview. Microsoft's Purview Data Map APIs let you retrieve entities, glossary terms and relationships, and that output is what you can keep and import elsewhere. Purview is a managed SaaS service, so you should not expect to take an image or database snapshot of its internal store. Confirm with Microsoft what retention, export and recovery options apply to your account and tenant, and treat the API output as your portable copy. Keep the raw API responses with timestamps so you can prove what the snapshot contained.

Does a self-hosted catalog need a backup of the exported data?

Yes. Once metadata is in OpenMetadata or DataHub, that platform becomes the system you must back up and restore. OpenMetadata stores metadata in MySQL or PostgreSQL and indexes it in Elasticsearch or OpenSearch, and DataHub relies on MySQL or PostgreSQL, Elasticsearch or OpenSearch, and Kafka. Each store needs its own backup plan and restore test. Search indices can often be rebuilt from the database, but you should confirm that path in your own environment rather than assume it. Plan the backup schedule, retention and restore drills as part of the export scope.

What should we ask a partner for in a written quote?

Ask for a fixed scope written in terms you can check. The quote should list the Purview entities, collections, glossary terms, lineage depth and custom attributes in scope, the target platform and version, the deliverables for each phase, and the verification method, including how differences are reported and resolved. It should name what your team must provide, such as API access, data owner reviews and the freeze window, and what happens if those are late. Ask which items are one-time work and which recur, such as support or upgrades, and whether any retainer is optional. DeployOpen plans fixed-scope engagements with scope, deliverables and timelines agreed in writing before work starts, and it does not publish a price list, so the quote follows from that written scope.

What to plan before the Purview contract ends

The export itself is the easy part. The risks sit around it: the contract clock, the snapshot you export from, the read access you keep, and the people who run the target afterward. Work through these six items before anyone deletes a Purview resource.

Confirm billing end date and notice

Read the billing end date and the notice terms in your Microsoft agreement before you plan any export window. Confirm who in your organization can give notice, how far in advance it must be given, and whether Purview charges continue to accrue during a parallel run. Take every date from your own contract, not from this page.

Freeze the export snapshot date

Pick one cutoff date and export every entity, glossary term and lineage record as of that point. Without a frozen date, the catalog keeps changing during extraction, and the exports will not agree with each other. Record the date in the migration log so later reconciliation compares like with like.

Keep Purview read access until verification

Do not remove read permissions, service principals or Data Map API access until the target catalog passes your entity and glossary checks. Re-exports are often needed after a gap is found. Keep the access scoped to read only, and log who uses it during the wind-down.

List objects without an export path

Some curated objects may not come back through the Atlas-compatible APIs in a usable form, such as custom scoring, certain data product attributes or access-related artifacts. Inventory them early, decide whether each is rebuilt by hand, rescanned from the source, or retired, and document the decision for each.

Name the target platform owner

Assign one team to run OpenMetadata or DataHub after go-live, including ingestion schedules, upgrades, backups and access groups. Ownership should be settled before the cutover, because a catalog with no operator loses trust quickly. Ask the vendor or partner which upgrade notes apply to your chosen version before you set the schedule.

Schedule a parallel run

Run Purview and the new catalog side by side for a fixed window and let stewards search both for the same assets. Compare owners, glossary links and lineage on a sample of high-use tables before switching users. Agree the length of the window with stakeholders in writing and plan it against your notice period.

Which export path fits your team

A team with a data engineer who can script calls against the Atlas-compatible Data Map APIs can pull entities, glossary terms and lineage into files and load them into OpenMetadata or DataHub. This path is reproducible and scales to large catalogs, but the script becomes code your team must maintain and test.

Pull by object type first: Export glossary terms, then entities, then lineage, so relationships resolve when you import.
Store raw responses: Keep unmodified JSON from each call so you can reshape the output without calling the API again.
Build a mapping layer: Translate Purview GUIDs and qualified names into OpenMetadata entity names or DataHub URNs before import.
Load into a test deployment first: Run the import against a non-production OpenMetadata or DataHub instance, using the OpenMetadata REST APIs or Python SDK, or DataHub's ingestion framework.

The main risk is long-running exports that hit paging, throttling or token expiry, and mapping errors that look correct until someone checks a lineage graph. Confirm in your own tenant which API versions, permissions and rate limits apply before writing the script.

How DeployOpen works on this

DeployOpen approaches a Purview export as a fixed-scope piece of work: we agree in writing which entities, glossary terms, owners, classifications and lineage will be pulled out and in what shape. We then build and test the extraction and import path into a self-hosted OpenMetadata or DataHub environment inside your own infrastructure.

How we scope

Written scope lists the Purview collections, asset types and glossary terms to extract, agreed before any work starts.
We confirm which Data Map API calls your tenant permissions allow, and which objects must be rescanned instead of exported.
The scope names the target platform, OpenMetadata or DataHub, and the field mapping for owners, domains and classifications.

How we build

We write and test read-only extraction scripts against the Atlas-compatible Data Map APIs in a non-production copy first.
We shape the output into the import formats for your chosen target and run test imports into a staging deployment.
We reconcile counts and lineage edges between the source export and the target, and record every gap in a shared log.

How we hand over

Deliverables include the extraction code, mapping specification, reconciliation report and a runbook for repeating the export.
We document which items were rebuilt by hand, such as data quality rules and data products, so your team knows what to re-create.
Handover sessions walk your engineers through the import, the rollback steps and the open items agreed in the written scope.

How we support

Fixed-scope engagements end at the agreed handover, with the deliverables and acceptance steps written into the scope.
Ongoing support, upgrades and continuous testing of the target platform are available as a retainer.
Before you request a quote, confirm your Purview license model, source count and retention needs so the written scope is accurate.