Migrate from Microsoft Purview to OpenMetadata

Migrate from Microsoft Purview to OpenMetadata: what moves and who does the work

A platform team that must leave Purview Unified Catalog, whether because of a billing change, a data residency requirement or a wish to run metadata inside its own network, should plan the move as re-ingestion plus rebuilding governance content, not as a file export. Purview has no one-click catalog export, so the work is to point OpenMetadata connectors at the same Azure and other sources, then recreate or re-link the glossary terms, owners, classifications, data products and data quality rules that the business relies on. The effort depends mostly on three volumes: how many glossary terms and owners need curating, how much lineage must be re-established, and how many data quality rules must be rebuilt and validated. Count those before estimating anything.

Platform engineering usually leads the move, with data owners and stewards signing off on the governance content. Platform engineers own the deployment, connector credentials, network paths and upgrades. Data owners decide which Purview glossary terms, classifications and ownership assignments are still correct and should be carried forward, and which were stale. Ask your OpenMetadata support provider, whether Collate or a services partner, to quote the connector configuration, glossary and data product rebuild separately from the platform install so you can see which parts are one-time and which recur. OpenMetadata is released under the Apache License 2.0 and runs in your own infrastructure, so the software license itself carries no per-asset charge. The recurring costs are the compute, database, search and staff time to operate it.

Which Purview capabilities map to OpenMetadata, and which need rework

This table compares Purview Unified Catalog capabilities with their closest OpenMetadata equivalents and marks each as clean, needs rework or gap. Read the status column as a planning signal, not a verdict, since field-level mappings depend on your own metadata. The main takeaway is that scanning, glossary and lineage move with moderate effort, while data products and Purview-specific billing and quality constructs need design decisions before you migrate.

Purview capability	OpenMetadata equivalent	Status	What to confirm in a pilot
Data Map scanning of Azure sources	Connector-based ingestion from 130+ connectors, including Azure sources	Clean	Confirm connector coverage and version for each Azure source you scan
Scanning of non-Azure sources	Connector-based ingestion across warehouses, BI tools, pipelines and ML platforms	Clean	Check that every non-Azure source you rely on has a supported connector
Glossary terms	Glossaries with term definitions and relationships	Needs rework	Confirm how term names, synonyms and related-term links map during import
Owners	Owner assignment on assets, teams and users	Needs rework	Confirm how Purview owner roles map to OpenMetadata owner fields and whether identities resolve
Classifications	Classifications and tags applied to columns and assets	Needs rework	Confirm classification names, sensitivity labels and how custom classifiers are recreated
Data products	Domains and data products	Needs rework	Confirm how Purview data products and their asset memberships are rebuilt as domains
Data quality rules	Data quality tests, profiling and freshness checks	Needs rework	Confirm which Purview quality rules have an equivalent test and how DGPU-based health controls are reproduced
Lineage	Table, column, dashboard, pipeline and metric lineage with OpenLineage events	Clean	Confirm that lineage from each source reaches the same depth as in Purview
Programmatic access	REST APIs, Python SDK, TypeScript packages and Java libraries	Clean	Confirm that your migration scripts cover the entities you need to move

What data and integrations to carry over, and how

Purview migration is mostly rebuilding rather than copying. Metadata moves through three routes: fresh ingestion from sources, programmatic extraction of curated business content, and manual reconstruction of identity, alerting and integration links. Each card below marks one route and what to verify before cutover.

Re-ingest sources with OpenMetadata connectors

Most technical metadata is cheaper to rebuild by running OpenMetadata connectors against the same Azure sources than to export it from Purview. OpenMetadata lists more than 130 connectors, so check that each Azure service, storage account, SQL database and BI tool you scan in Purview has a supported connector and the source permissions it needs. Compare table and column counts after the first run to catch scope gaps early.

Extract glossary terms and classifications

Business glossary terms, term-to-asset links and classifications are the content people curated by hand, so they carry the most value. Read them through the Atlas-compatible APIs in Purview, write them to a mapping file that records each term's owner, status and linked assets, then load that file into OpenMetadata glossaries and classifications. Confirm which Purview classifications map to OpenMetadata tags, since names rarely line up one to one.

Carry over owners and stewards

Ownership in Purview is attached to assets, collections and terms in ways that do not map directly onto OpenMetadata owner fields. Decide whether owners are users, teams or domains, and build a table of Purview principals to OpenMetadata users before loading anything. Owners who leave the organization or whose accounts are disabled during the move should be reassigned in the mapping file, not discovered later in the catalog.

Rebuild data products and quality rules

Purview data products and data quality rules are configured inside Purview's own model, so they must be redefined in OpenMetadata rather than imported as-is. Document each product's assets, owner and terms, then recreate the quality tests as OpenMetadata data quality tests and confirm that each test runs against the same tables and thresholds. Ask your team to agree on acceptance criteria before turning off Purview scans.

Rebuild SSO, alerts and integration links

Entra ID sign-in, notification rules and links from Azure DevOps and Power BI do not transfer with the metadata. Configure OpenMetadata authentication against your identity provider, recreate subscriptions for stewards and data owners, and update every pipeline, dashboard and wiki page that points to a Purview URL. Test each notification path with a real change before retiring the Purview alerts.

Shape exports by hand

Purview has no one-click catalog export, so the team defines what is extracted, in what shape and in what order. Write scripts against the APIs to produce JSON or CSV files for each object type, then validate them against a staging OpenMetadata instance. Plan this work as a named deliverable with its own owner, because the scripts, mapping rules and review cycles usually take more effort than the data movement itself.

Migration sequence: inventory, pilot, parallel run, cutover and decommission

This sequence moves Purview-governed metadata into self-hosted OpenMetadata one domain at a time, so each step produces evidence that the next step depends on. Every phase ends with a written output that the data owners and the security team can review before Purview scans are turned off.

Inventory sources, glossary, owners and data products
Start by listing every Purview data source, scan schedule, collection, glossary term, classification, owner and data product in the Unified Catalog. Name the owner of each source and note which sources need connectors outside Azure, since OpenMetadata lists more than 130 connectors covering warehouses, BI tools, pipelines and ML platforms. The output is an inventory register with one row per asset group, its owner, its connector and its sensitivity classification. The step is done when each row has a named owner and a connector decision, and the data owners have signed off on the list.
Build the mapping sheet for metadata objects
Map each Purview object to its OpenMetadata equivalent: glossary terms, classifications, owners, domains and data products. Note where the two models differ, such as how Purview scopes collections compared with how OpenMetadata organizes domains, and decide how each difference will be handled. Confirm the export path with your Purview administrator, because Purview has no one-click catalog export and entities, terms and lineage must be read through its Atlas-compatible APIs. The output is a mapping sheet that the glossary owners and the platform team both approve. The step is done when every object type in the inventory has a target and a named reviewer.
Pilot one domain on a self-hosted OpenMetadata
Deploy OpenMetadata in your own environment, using the Kubernetes Helm charts or bare metal paths in the deployment documentation, and connect one business domain end to end. For bare metal, the project lists Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x as prerequisites, with minimum sizing of 2 vCPUs and 4 GB RAM for the server. Ingest that domain's sources, load its glossary and owners from the mapping sheet, and set up the data quality tests the domain already depends on. The output is a pilot report listing what was ingested, what was rebuilt by hand and which gaps remain. Confirm the current production sizing guidance with the vendor before you size hardware.
Reconcile both catalogs in a parallel run
Run Purview and OpenMetadata side by side for the pilot domain and then for the remaining domains. Compare asset counts, owners, glossary links, classifications and lineage between the two catalogs, and record each difference as an exception with a decision. Data owners should review the exceptions for their own domains, and the team should check that OpenMetadata's lineage matches what they expect from their pipelines. The output is a reconciliation report with a count of open exceptions and a named decision for each. The step is done when no open exception blocks a domain from cutover.
Write the cutover runbook for ownership and access
Prepare a runbook that sets the date and order for each domain, names the person who makes each change, and lists the access groups that move from Purview roles to OpenMetadata roles. Include the steps to reassign owners, confirm that consumers can find the glossary and data products in the new catalog, and point any integrations, such as dashboards or documentation links, at OpenMetadata. Define a rollback step for each domain. Have the security team review the role mapping before any change is made. The output is a cutover runbook that has been approved by the data owners and the security team. The step is done when a test user in each role can reach the expected assets in OpenMetadata.
Run cutover for each domain
Execute the runbook one domain at a time, starting with the pilot. Freeze Purview edits for the domain, run a final incremental ingestion into OpenMetadata, reassign ownership and switch consumer links, then confirm the results with the domain owner. Record the time, the operator and any deviations from the runbook. Keep Purview read-only for each domain until the rollback window closes, so that an issue can be reversed without losing curated metadata. The output is a signed cutover log for each domain. The step is done when every domain has a log with no unresolved issue.
Decommission Purview scans and record the closure
Once all domains are cut over and the rollback window has passed, stop the Purview scan schedules, remove the Purview connections that OpenMetadata now replaces, and retain an export of the curated metadata for audit needs. Confirm with your compliance and records owners how long the Purview export and logs must be kept, and check whether any retention rule in your policy requires a different approach. Revoke Purview role assignments and any billing associated with governed assets or data quality processing units, after confirming the billing end date with Microsoft. The output is a decommission record that lists stopped scans, revoked roles, retained exports and the date of final sign-off.

What drives cost and duration, and how to keep each down

This table lists the main drivers of effort and running cost when moving from Purview Unified Catalog to self-hosted OpenMetadata, and how to keep each one manageable. Use it to shape the scope you send for a written quote. The supplied sizing figures are minimums for a bare metal test layout, so production sizing needs a separate assessment of your own volumes.

Driver	Why it changes cost or effort	How to keep it down
Number of sources and connectors	Each Azure and non-Azure source needs a connector, credentials, network paths and a scheduled ingestion pipeline. OpenMetadata lists more than 130 connectors, but each one you enable still needs configuration and testing.	Start with the sources that feed governed assets. Retire stale sources instead of migrating them, and confirm connector coverage for each system before scoping.
Glossary and classification volume	Terms, owners and classifications must be exported from Purview through its APIs, reshaped and imported. Large volumes with inconsistent ownership multiply mapping and review work.	Clean owners and duplicate terms in Purview before export. Agree a mapping table for classifications with your data governance team.
Lineage depth	Table, column and pipeline lineage from OpenLineage events or connector metadata grows with pipeline count. Deep column-level chains take longer to validate and to repair when a source changes.	Set a lineage scope per domain. Prioritize lineage for regulated reports and rebuild the rest after go-live.
Data quality rule count	Purview quality rules are billed through DGPU consumption, while OpenMetadata tests run on your compute. Each rule must be rebuilt as an OpenMetadata test and tied to an owner and alert path.	Rebuild only rules tied to controls or consumers. Review rules that duplicate each other or check nothing downstream uses.
Custom ingestion needs	Sources without a connector need custom ingestion code, which adds build, test and maintenance work. OpenMetadata 2.0 changed custom ingestion images to Python 3.12, so older custom code may need rework.	Inventory custom sources early. Ask the vendor or your integrator to confirm whether an existing connector covers each one.
Kubernetes or bare metal hosting	Production bare metal needs Java 21, PostgreSQL 15 or later or MySQL 8.0.42 or later, and Elasticsearch 9.x or OpenSearch 3.x. The minimum server is 2 vCPUs, 4 GB RAM and 20 GB storage, with database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage (OpenMetadata bare metal deployment docs). Kubernetes adds cluster operations.	Use the documented minimums only as a floor. Ask for a sizing estimate based on your source count, metadata volume and concurrent users, and confirm which hosting model your team already operates.
Upgrades and version changes	OpenMetadata ships maintenance releases about every one to two weeks after 2.0.0, and 2.0 has breaking changes such as the embedding credential block and Databricks auth format. Each upgrade needs regression testing of ingestion and access rules.	Pin a version, schedule a regular upgrade window and ask for upgrade testing to be a line item in the written scope.
Operating staff and support	Self-hosting moves operating work from Microsoft to your team or a partner. Collate offers managed OpenMetadata and premium support as commercial options, which add subscription cost but reduce internal load.	Compare internal run effort with a retainer or Collate subscription. Ask each vendor what support level and response terms their quote includes.

How the move differs by starting point and team

Teams whose data sits mostly in Azure services usually find the connector work the most predictable part of the move. OpenMetadata lists more than 130 connectors for warehouses, BI tools, pipelines and ML platforms, so the Azure sources you already scan in Purview have counterparts to configure, though you should confirm each connector's current support for your specific Azure service and authentication method. Most of the effort moves into the metadata you curated in Purview, since that is what must be carried across by hand or by script.

Connector setup shrinks: Re-running ingestion from each Azure source is usually faster than exporting and reshaping the Purview data for import.
Lineage rebuilds still need checking: Confirm which lineage edges OpenMetadata derives from ingestion and which need OpenLineage events or manual entry.
Ownership and domains grow: Map Purview collections and roles to OpenMetadata owners, teams and domains, which often needs a decision from data owners.
Credentials move to your side: Service principals and secrets become your responsibility to rotate and store.
Scan schedules are yours to rebuild: Recreate the ingestion schedules that Purview ran for you.

Before starting, ask your Azure team to list every scanned source and its authentication method so the connector plan has no surprises.

What usually goes wrong, and how to prevent it

Most failed catalog migrations lose something that was never written down: who owned what, which rules applied, and which access decisions were implicit. The cards below cover the failure points we see most often when moving from Purview Unified Catalog to self-hosted OpenMetadata, and the check that prevents each one.

Lost ownership history

Owner fields often arrive in OpenMetadata as a single current value, with no record of who held the role before. Auditors and data stewards may still ask who approved a definition last year. Before cutover, export owner assignments with their dates from the source, store that history in a separate evidence file, and confirm which owner fields OpenMetadata actually stores on each entity type. Do not assume the import carries the full timeline.

Duplicate glossary terms

Glossary terms that were curated in Purview can be recreated during re-ingestion, especially when a term exists both as a manual entry and as a term synced from a source. The result is two terms with the same name and different owners, and dashboards linked to the wrong one. Agree on a single source of truth for each term, run a name-match report across both catalogs before loading, and merge duplicates before any business user sees the new glossary.

Classifications not mapped

Purview sensitivity labels and classification names rarely match the tag names or classification sets used in OpenMetadata. If mapping is left to the default import, sensitive columns may appear untagged, and any downstream masking or policy logic keyed to the old names will silently stop matching. Build a written mapping table from every source classification to an OpenMetadata classification and tag, then check a sample of personal data columns in each source after load.

Data quality rules not reproduced

Data quality rules defined in Purview do not transfer as runnable tests. Each rule must be rewritten as an OpenMetadata data quality test on the matching table or column, with the same threshold and schedule. Rules that existed only as Purview health checks may have no equivalent at all. Keep a rule inventory with a pass or fail status per rule, and run both systems in parallel for a defined period before you retire the old rules.

Stale lineage after re-ingestion

Lineage captured by Purview scans does not automatically match what OpenMetadata derives from its own connectors and OpenLineage events. Pipelines renamed since the last scan can leave orphaned edges, and column-level lineage may be incomplete for sources OpenMetadata reads differently. Compare lineage for a set of critical reports before and after load, and treat any missing upstream source as a blocker for that data product.

OpenMetadata 2.0 upgrade breaks

If you deploy on OpenMetadata 2.0, several changes can break an otherwise clean migration: embedding credentials moved into an llmConfiguration block, Databricks authentication uses a new format, custom ingestion images must be rebuilt for Python 3.12, and Great Expectations must be migrated to 1.3 before upgrading. Pin your target version, rebuild custom images in a test environment first, and rerun every ingestion workflow once before cutover.

Access rules dropped at cutover

Purview roles, collection permissions and the users who could see curated assets do not map one to one onto OpenMetadata teams, roles and policies. During cutover, the new catalog can open to a wider group than intended, or lock out stewards who need edit rights. Map each Purview role to an explicit OpenMetadata role, test access as a sample of users from each group, and connect sign-in to your identity provider before any production user logs in.

Questions buyers ask before moving from Purview to OpenMetadata

What drives the cost of moving from Purview to self-hosted OpenMetadata?

The cost is driven by the infrastructure you run, the ingestion and integration work, and the staff time to operate the platform. Infrastructure covers Kubernetes or bare metal capacity, a database and a search service. The Purview side stops billing once you exit, but you should check your current governed asset count and data quality processing unit consumption, since those set what you are replacing. Ask any partner for a quote that separates one-time work (connector setup, glossary and classification migration, rebuilding data products and quality rules) from recurring work (hosting, upgrades, on-call support and internal ownership). OpenMetadata itself is Apache-2.0 licensed, so there is no license fee for the open-source edition. If you want Collate's managed service or commercial support, price that separately.

How long does a Purview to OpenMetadata migration usually take?

Duration depends on the number of sources, how many glossary terms and owners need manual review, how many data products exist and how much data quality logic must be rebuilt. The minimum platform footprint is small: OpenMetadata's bare metal documentation lists a server with 2 vCPUs, 4 GB RAM and 20 GB storage, plus database and search services that each need at least 2 vCPUs, 2 GB RAM and 30 GB storage. Those are starting points, not sizing for a production estate. No duration figure is supplied for this migration, so ask any implementation partner for a timeline built from a written scope that lists your sources, their count and the governance artifacts to move. Fixed-scope engagements agree deliverables and timelines in writing before work starts.

What does our internal team need to provide for the migration?

The migration depends on three inputs from your side. First, source access: service principals or credentials with read rights for each Azure and non-Azure source, network paths from the OpenMetadata deployment, and a decision on where ingestion runs. Second, named data owners who confirm which assets, owners and classifications are still correct, because Purview entries often reflect old ownership. Third, glossary decisions: which terms survive, which are merged, and who approves the canonical definition. Without these, the platform can ingest metadata but the governance content will not be trustworthy. Ask any partner to list these inputs in the written scope with an owner and a due date for each.

Can our own engineers do the migration without an outside partner?

Yes, if your team has Kubernetes or bare metal operations experience, database and search administration skills, and someone who can write or adapt ingestion workflows using OpenMetadata's connectors and its REST APIs, Python SDK, TypeScript packages or Java libraries. The source is open, so you can review the code and the documentation before you commit. The main risks in self-running the project are underestimating the Atlas-compatible export work, skipping the data owner review, and leaving no one accountable for upgrades. Before you decide, check whether your team can staff ongoing operations, not only the initial cutover.

What does a fixed-scope DeployOpen engagement cover for this migration?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this migration, a fixed-scope engagement would typically define the sources to connect, the OpenMetadata deployment target, the approach to carrying over glossary terms, owners and classifications, the data product and data quality rebuild, access controls, backup and documentation. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. DeployOpen does not issue audit reports or certifications, so any compliance evidence you need still comes from your independent auditor.

How do OpenMetadata 2.0 changes affect the migration plan?

OpenMetadata 2.0.0 was released on August 24, 2026, and maintenance releases 2.0.1 to 2.0.5 followed, with 2.0.5 released on October 8, 2026. The release notes list breaking changes that belong in your plan: embedding credentials move into an llmConfiguration block, Databricks uses a new auth format, custom ingestion images must be rebuilt for Python 3.12, and Great Expectations must be migrated to 1.3 before upgrading. The 2.0 release also made Dynamic Sampling the profiler default and enabled MCP by default, so review profiling cost and access exposure before go-live. Build the upgrade check into the migration scope, test on a non-production instance first, and confirm the exact upgrade steps for your version in the release notes.

Is OpenMetadata secure enough for regulated data governance?

OpenMetadata's security documentation describes how the platform handles authentication and access, and the security question depends on how you configure it, not only on the software. Confirm single sign-on, role assignments, encryption in transit and at rest, secret storage for connector credentials, and audit logging against your own control set before go-live. DeployOpen can harden and document the deployment and prepare evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Ask your independent assessor which controls they will test so the evidence matches what they expect.

How DeployOpen scopes, runs and supports a Purview to OpenMetadata migration

DeployOpen plans and implements self-hosted OpenMetadata inside your own cloud accounts or data centers, then hardens, documents and supports it. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory which Purview collections, sources, glossary terms, owners and classifications must move to OpenMetadata
Agree in writing which Azure and non-Azure connectors will be re-ingested and which metadata will be rebuilt by hand
Define the deliverables for data products, data quality rules and access roles before any build work begins
Confirm the hosting target, whether Kubernetes with Helm or bare metal, along with database and search footprint requirements

How we build

Deploy OpenMetadata with its database and Elasticsearch or OpenSearch services in your own environment
Configure ingestion pipelines for Azure sources and other connectors, and test lineage and metadata coverage against the inventory
Rebuild glossary terms, ownership and classifications through the OpenMetadata APIs, then validate them with your data owners
Document the Java, database and search prerequisites and the version pinning used for the deployment

How we hand over

Deliver runbooks for deployment, upgrades, backups and restores of the OpenMetadata environment
Provide a reconciliation report comparing exported Purview objects with what appears in OpenMetadata after migration
Train platform and data governance staff on ingestion scheduling, data quality tests and domain ownership
Give your team a written record of decisions, open gaps and items that still need confirmation with your vendors

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Plan OpenMetadata version upgrades against the release notes, including breaking changes and ingestion image rebuilds
Review access to the catalog and its underlying services as part of periodic security testing
Prepare evidence on catalog controls for compliance assessments, while independent auditors issue any formal opinion

Migrate from Microsoft Purview to OpenMetadata