Purview Unified Catalog: switch or self-host

Why a self-hosted data catalog is now a decision on your billing terms

If you are an existing Azure Purview customer, you face a choice: accept the pay-as-you-go billing consent that Microsoft requires before you can use Unified Catalog, or stay on the classic Data Catalog. The alternative to both paths is to rebuild your catalog on self-hosted OpenMetadata or DataHub, running in your own infrastructure. This page compares those options so you can decide which path fits your renewal date, your data residency rules and your team's capacity to operate the platform.

The supplied research describes the open-source side in detail: licensing, connector counts, deployment prerequisites, Kubernetes components and release history. It describes the Purview side only at the level of the consent requirement. It does not establish how Purview bills per governed asset or per data quality processing unit in your tenant, or how long the classic Data Catalog will receive support. Before you sign anything, confirm both points directly with Microsoft, and ask for the rates, meters and end-of-support dates in writing, applied to your own asset counts.

Treat the consent as a decision with a deadline, not a formality. Pull your current governed asset count, your data quality volume and your list of Purview integrations, then ask what each would cost under Unified Catalog and what classic support covers over the next contract period. If you plan to self-host, start a parallel evaluation now. Confirm with your platform team that the chosen open-source platform fits your database, search and identity standards, and that you can staff its upgrades. A clear answer to those questions is more useful than a fast consent.

What the switch decision requires you to settle

The move from Purview classic Data Catalog to Unified Catalog, or to a self-hosted platform, is a set of decisions that depend on each other. Settle the contract and billing questions first, then the inventory, the metadata export, the operating owner and the fate of the classic catalog.

Review the billing consent in writing

Pay-as-you-go billing for Unified Catalog is a consent step, so the first item is a written review of what your organization is agreeing to. Ask Microsoft or your reseller to confirm in writing how governed assets and data quality processing units are metered, which subscription and tenant the charges land on, and who in your organization can accept the terms. Keep the consent record with the decision file, because it defines the cost baseline for any comparison with self-hosting.

Inventory governed assets and quality rules

Count what Unified Catalog would govern today, not what the catalog contains on paper. List governed assets by source, owner and business domain, and list every data quality rule and its schedule. Both counts drive the metered cost on the Microsoft side and the ingestion and profiling load on a self-hosted side, so an unverified inventory makes any cost comparison unreliable.

Plan the export or rescan for glossary and lineage

Decide, per object type, whether glossary terms, owners, classifications and lineage will be exported through the Atlas-compatible Data Map APIs or rebuilt by rescanning sources. Curated content such as term definitions and ownership assignments usually needs export, while structural metadata is often cheaper to re-ingest. Test the export on a single domain first and check that owners and term links survive the mapping before you commit to a cutover date.

Name an operating owner for the platform

Whichever platform you choose, one team must own upgrades, connector maintenance, access control and incident response. On Unified Catalog that team manages billing and configuration. On OpenMetadata or DataHub it also runs the database, search, Kafka where applicable and the Kubernetes cluster. Write the owner, the on-call path and the upgrade cadence into the decision record before purchasing or provisioning anything.

Set the retention plan for the classic catalog

Decide what happens to the classic Data Catalog and its metadata after the switch. Document whether it stays read-only for a defined period, how audit trails and lineage history are kept, and where exported copies are stored under your records policy. Confirm with Microsoft the current retention behavior of the classic catalog during any transition, since it determines whether you can roll back and how long evidence remains available.

Check the chosen platform's dependencies

If the decision leads to self-hosting, confirm the platform's infrastructure prerequisites against the current deployment documentation before sizing anything. Confirm database, search and streaming components, Kubernetes or bare metal footprint, and the SSO setup your identity provider requires. Treat these as checks to complete in your own environment, not as assumptions carried over from this comparison.

Which option fits each constraint: Purview, OpenMetadata or DataHub

This table compares three paths for a current Azure Purview customer: accepting Unified Catalog billing, staying on the classic Data Catalog, or self-hosting OpenMetadata or DataHub. Read each row against your own constraints, such as who must operate the platform and how billing scales with governed assets. Confirm Microsoft's current feature differences between classic and Unified Catalog directly with Microsoft before deciding.

Option	Who hosts and operates it	Billing model	What the supplied facts say	Main trade-offs
Accept Unified Catalog billing	Microsoft hosts the SaaS catalog; you manage configuration and governance content	Pay-as-you-go per governed asset and per data quality processing unit (DGPU)	Billing is metered per governed asset and DGPU, so cost follows catalog size and data quality activity	Least rebuild work, but cost grows with scope and you stay tied to Microsoft's feature roadmap
Stay on classic Data Catalog	Microsoft hosts the service; confirm the support window with Microsoft	Confirm the classic billing terms with Microsoft before assuming any difference	Feature differences between classic and Unified Catalog must be confirmed with Microsoft	Avoids immediate consent to new billing, but may defer a migration Microsoft is steering customers toward
Self-host OpenMetadata	Your team, on your Kubernetes or bare metal infrastructure, with optional Collate support	Apache-2.0 software with no license fee; you pay for infrastructure, staff and any Collate support	Apache-2.0 licensed; Collate offers managed and commercial support and premium features	You own upgrades, database and search operations, and rebuilding glossary, owners and data quality rules
Self-host DataHub Core	Your team, on Kubernetes with Helm charts or Docker quickstart for evaluation	Apache-2.0 software with no license fee; you pay for infrastructure, Kafka, databases, search and staff	Apache-2.0 licensed; DataHub Cloud adds an SLA and features not in open source	Operating Kafka, MySQL or PostgreSQL, and Elasticsearch adds footprint; SSO on Core must be configured by your operators
DataHub Cloud (managed)	The company behind DataHub operates the managed service	Commercial subscription; confirm terms and pricing in a written quote	Adds data quality monitoring, compliance forms, access request workflows, a 99.5% uptime SLA and AWS PrivateLink	Lower operating load, but a commercial dependency and features outside the open-source edition
Data residency and network reach	Depends on the option: Microsoft's SaaS region or your own network	Confirm where Purview processes metadata and DGPU work for your region	Self-hosted options run entirely in your infrastructure, including air-gapped networks if you need them	Confirm Microsoft's data location commitments with your account team before choosing SaaS
Existing Azure source coverage	Purview scans Azure sources natively; confirm coverage for your sources	Scan and governance costs follow the billing model above	OpenMetadata lists more than 130 connectors; DataHub lists more than 150 integrations	Confirm connector support for each source you run, including sources outside Azure

What the rebuild work covers when you leave the Purview billing model

The rebuild is the main cost of leaving Purview billing, and it is driven by how many sources you connect and how much custom logic sits around them. Start by inventorying every source, the connector or ingestion method each one uses today, and every custom scan, script or API client that writes to the catalog. OpenMetadata lists more than 130 connectors and DataHub lists more than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau, so many standard sources have a native path. Sources without a matching connector, and sources reached through custom Purview scan rules, will need ingestion work of their own. Confirm each connector's version support and authentication method against the platform's current documentation before you commit to a source list.

Metadata that people curated by hand is what you must carry over, and it does not move on its own. Glossary terms, owners, classifications and domains each need a mapping from Purview's model to the target's model, plus a decision on which items are still current. Lineage and data quality tests are rebuilt rather than copied. OpenMetadata supports table, column, dashboard, pipeline and metric lineage with OpenLineage events, plus data quality tests and profiling, and DataHub documents column-level lineage and data quality assertions. Plan to recreate each rule and check it against the source data, because a passing rule in one tool does not prove the same rule works in another.

If you use OpenMetadata, the 2.0 release adds breaking changes that affect custom work. Embedding credentials move into an llmConfiguration block, Databricks uses a new auth format, and custom ingestion images must be rebuilt for Python 3.12. Great Expectations must be migrated to 1.3 before the upgrade. Any custom pipeline, script or Helm values file that touches these items needs a change and a test run. Ask your team to list every custom component before sizing the project, and confirm the current release notes for the version you plan to deploy.

What OpenMetadata and DataHub each ask you to run

OpenMetadata runs as a set of services with a relational database and a search index behind them. For production, the project documents Helm charts on Kubernetes, including Amazon EKS, Azure AKS, Google GKE and on-premises clusters, and a bare metal path that does not require Kubernetes. Docker Compose is intended for evaluation. The bare metal prerequisites set the baseline your platform team must provide.

Runtime: Java 21 on the server hosts, installed and patched by your team as part of the base image.
Database: MySQL 8.0.42 or later, or PostgreSQL 15 or later, holding the metadata store. Your team owns its backups, restore tests and version lifecycle.
Search: Elasticsearch 9.x or OpenSearch 3.x, which powers discovery across assets and needs its own storage planning.
Minimum sizing: 2 vCPUs, 4 GB RAM and 20 GB storage for the server, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage.
Kubernetes path: Helm charts add cluster, ingress, secret and storage configuration to your existing platform practices.

The sizing figures are minimums to start the services. Confirm production sizing with a load test that uses your source count, ingestion schedule and user numbers before you commit to node or instance types.

How to deploy the chosen platform inside your own network

This sequence takes you from choosing a target platform to a cut-over that keeps your current catalog running until the open-source replacement has proven itself. Each step ends with a check you can show your security and data teams.

Confirm the target platform and deployment model
Your platform engineering lead and data platform owner decide between OpenMetadata and DataHub, then pick the deployment model. OpenMetadata documents production deployments on Kubernetes (including Amazon EKS, Azure AKS, Google GKE and on-premises clusters) and on bare metal, with Docker Compose for evaluation only. DataHub is deployed on Kubernetes with Helm charts from the acryldata/datahub-helm repository. Write down the cluster or host layout, the namespaces or accounts, and the network paths to your Azure and other sources. The output is a signed-off architecture note that names the platform version you will test against.
Provision database, search and Kafka tiers
Your cloud or infrastructure team provisions the backing services in your own accounts or data center. OpenMetadata bare metal needs Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x, and the documented minimums are 2 vCPUs and 4 GB RAM for the server, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. DataHub adds Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch for search and a graph index on Neo4j or Elasticsearch. Ask your infrastructure team to size these tiers for your asset count, since sizing is driven by metadata volume and ingestion schedule. The output is a running set of services with backups, encryption and access restricted to the catalog workloads.
Configure OIDC single sign-on
Your identity team connects the catalog to your existing identity provider over OpenID Connect. DataHub documents OIDC support with providers such as Google, Okta and Azure AD. On self-deployed DataHub Core, the operator configures the frontend server, while DataHub Cloud enables OIDC through its interface. Confirm the equivalent setup path for OpenMetadata in its security documentation. Test login with a small group of named accounts, confirm that a user who leaves your directory loses access, and record the redirect URIs and client settings in your change system. The output is a verified login flow and a documented configuration that your security team can review.
Run a pilot ingestion from a non-production source
Your data engineers run ingestion from one non-production source, such as a development warehouse or a sample Azure database, using the connector for that source. Start with a single schema so that results are easy to inspect. Compare the resulting tables, columns, owners and lineage with what the source actually contains. Note any connector gaps or missing lineage and decide whether to fix them with configuration or a custom connector. The output is a pilot report listing what ingested correctly, what did not, and the time and resource use observed on your hardware.
Rescan sources and reconcile glossary and ownership
Your data governance lead and the data owners rescan the production sources with the chosen platform rather than trying to move every Purview object by hand. Export the curated glossary terms, owners and classifications from Purview through the Atlas-compatible APIs, and map them to the target's glossary, domain and ownership model. Reconcile differences with the data owners, and keep a mapping sheet that shows each Purview term and its new identifier. The output is a reconciled catalog where every production table has an owner, every glossary term is linked, and the gaps are listed for follow-up.
Rehearse the upgrade path before go-live
Your platform team performs an upgrade in a staging copy before any production change. For OpenMetadata, read the 2.0 release notes first: the breaking changes include moving embedding credentials into an llmConfiguration block, a new Databricks auth format, rebuilding custom ingestion images for Python 3.12, and migrating Great Expectations to 1.3 before upgrading. For DataHub, confirm that the Helm chart's system-update job completes and that search reindexing finishes. Record the procedure, the rollback steps and the backup restore test. The output is a tested runbook that the operations team can follow on the next maintenance window.
Cut over with a parallel run
Your data governance and operations teams run the new catalog in parallel with Purview for an agreed period, with stakeholders checking search results, lineage and ownership in both systems. Keep Purview read-only for reference and do not cancel your subscription until the parallel run has signed off and your records retention requirements are met. Confirm the billing end date with Microsoft in writing. Once users have moved, redirect links, notify consumers of the catalog and archive the Purview export. The output is a documented cut-over decision signed by the data owner, and a retirement plan for the old catalog.

Evidence that shows the catalog meets your governance controls

A self-hosted catalog becomes auditable only when its architecture, access settings, connector inventory, lineage, change history and recovery tests are written down and kept current. DeployOpen prepares these records for your own assessor, while independent auditors issue any audit report or certification.

Architecture and data flow record

Document every component the catalog depends on, where each one runs, and which metadata crosses which network boundary. For OpenMetadata, that covers the server, the database, the search service and ingestion workers. For DataHub, it covers GMS, the MAE and MCE consumers, the frontend, Kafka, the database, search and the graph index. Ask your assessor which data flows they expect to see diagrammed, and confirm whether any ingestion path sends metadata outside your network, including through a vendor-hosted option.

Access and SSO configuration

Record how users sign in, how roles map to catalog permissions, and who can change those settings. DataHub supports OpenID Connect providers such as Google, Okta and Azure AD, but on self-deployed DataHub Core the operator must configure the frontend server, so the configuration file and its review history become evidence. Confirm how OpenMetadata authentication and role assignments are set in your deployment and export the settings your assessor will test.

Ingestion and connector inventory

Keep a register of every source the catalog reads, the connector and version used, the service account it runs under, its schedule and its owner. Purview classic scans are replaced by connector runs you operate, so the inventory shows what metadata enters the catalog and when. OpenMetadata lists more than 130 connectors and DataHub lists more than 150 integrations; confirm each one you need before the inventory is signed off.

Lineage and classification records

Show that lineage and sensitivity labels are generated from sources you control and can be reviewed. Export table and column lineage, glossary terms, classifications and owners on a fixed schedule, and sample them against the source systems. Where OpenLineage events feed OpenMetadata, or where DataHub ingests column-level lineage, record which pipelines emit them and which gaps remain for manual entries.

Upgrade and change logs

Keep a dated log of each version change, the approval behind it and the test run that preceded it. OpenMetadata 2.0 introduced breaking changes, including moving embedding credentials into an llmConfiguration block, a new Databricks auth format and a Python 3.12 rebuild of custom ingestion images, so the log should show those were handled. DataHub's Helm chart runs a system-update job on upgrades, and that job's output belongs in the record.

Backup and restore test results

A backup policy is only evidence once a restore has been performed and recorded. Test restores of the metadata database and, where needed, rebuild the search index, then record the time taken, the data checked and any gaps. Remember that the search index can usually be rebuilt from the database, while the database and configuration are the primary records. Agree the restore test frequency and acceptance criteria with your assessor before the first test.

Questions buyers ask before switching from Purview

Can our team switch from Purview to a self-hosted catalog without outside help?

Some teams can, especially with a small source count and an engineer who already runs Kubernetes or Docker. The harder part is rarely the install. It is rebuilding ingestion for every source, re-creating glossary terms, owners and classifications, and wiring SSO and access rules so the new catalog matches what users had before. A fixed-scope written plan lets you decide which parts to keep in-house and which to hand to a partner. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own cloud accounts or data centers, so you can scope exactly the pieces you want supported.

What actually drives the effort of moving off Purview?

Four factors set most of the work. The first is source count, since each system needs an ingestion connector configured, scheduled and tested. The second is custom ingestion, meaning sources without a ready connector that need a script or SDK job. The third is glossary and classification volume, because curated terms and owners often live in spreadsheets or the portal and must be reconciled by hand. The fourth is SSO and upgrade cadence. OpenMetadata and DataHub both release often, and DataHub's Helm chart runs a system-update job on upgrades to apply schema changes and reindex search, so you should plan for regular upgrade windows rather than a one-time install.

Who on our side needs to be involved in the rebuild?

Three roles usually carry it. A data owner decides which glossary terms, owners, domains and data quality rules are authoritative and should be migrated. An identity contact maintains the OpenID Connect provider and approves the SSO configuration, which DataHub documents as an operator task on self-deployed DataHub Core. A platform operator runs the Kubernetes or bare metal hosts, the database, the search service and the backups. Ask your vendor or partner to name who covers each role in the written scope, because gaps in these three roles are where migrations stall.

How long does a rebuild take, and what determines that?

The duration depends almost entirely on inventory. A team that can list its sources, owners, glossary terms and data quality rules on day one can estimate the work much more tightly than one that discovers them during migration. Ask for a duration only after an inventory phase is agreed in writing, and treat any timeline quoted before that as a placeholder. Also confirm whether the timeline includes parallel running of Purview and the new catalog, since keeping both live during validation changes the calendar.

Which costs are one-time and which recur after a self-hosted switch?

One-time costs include the initial design, ingestion build-out, metadata migration, SSO setup and validation. Recurring costs include the compute and storage for the catalog, its database and search service, ingestion jobs, backups, monitoring, upgrades and the staff time to operate them. The OpenMetadata bare metal docs list minimum server sizes, and DataHub's Minikube guide notes more than 7 GB of RAM for a local test, but production sizing depends on your asset volume and ingestion schedule. Compare these recurring items against Purview's billing per governed asset and per data quality processing unit, which grows with usage rather than with your hosting footprint.

What should we ask for in a fixed-scope written quote?

Ask for a list of named sources and the connector or custom job planned for each one, an inventory of glossary terms, owners and classifications with the migration method for each, and the SSO and access model with the identity contact named. Require a deployment target statement covering Kubernetes or bare metal, the database and search services, and the backup and restore approach. Ask which upgrade and reindex tasks are included and how they will be tested. Finally, ask what handover, documentation and support run after go-live, and whether ongoing support is a separate retainer. DeployOpen does not publish a price list, so the quote should follow directly from that written scope.

Does a self-hosted catalog meet our compliance evidence needs after the switch?

A self-hosted catalog can keep metadata inside your own infrastructure, and OpenMetadata's security documentation covers how the platform handles authentication and access, so review that before you commit. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Ask your auditor early which evidence they will request, such as access reviews, change records and backup tests, and build the catalog's logs and runbooks to produce it.

How DeployOpen plans and deploys a catalog switch in your environment

DeployOpen plans, implements and hands over self-hosted OpenMetadata or DataHub inside your own cloud accounts, data centers or air-gapped networks. For a Purview classic or Unified Catalog decision, we start with the written scope, so the switch, the rebuild and the operating model are agreed before any work begins.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which Purview sources, glossary terms, owners and classifications are in or out of the move.
We confirm your Azure subscriptions, network controls, identity provider and where metadata must physically reside.

How we build

We plan the target platform, choosing between OpenMetadata and DataHub and sizing its database, search and ingestion components.
We configure connectors, SSO and access controls in your environment, and test ingestion against representative sources.
We document the rebuilt glossary, ownership and data quality checks so each one can be verified against the original.

How we hand over

We deliver runbooks for deployment, backup, restore and upgrades, including the schema and reindex steps for each release.
We prepare evidence of configuration and access controls that your own auditors can review, without issuing any attestation.
We walk your platform and security teams through operation, so ownership of the catalog is clear after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, agreed separately from the initial scope.
Upgrades are planned against each release's breaking changes, such as credential formats and ingestion image rebuilds.
Confirm with us during scoping which support level, response expectations and hosting model you need before quoting.

Purview classic Data Catalog to Unified Catalog: switch or self-host