Which catalog fits your team: Purview or self-hosted DataHub
If your estate is mostly Azure, your team has little capacity to run infrastructure, and identity and governance already sit in Microsoft tooling, Purview is usually the lower-friction choice, and a renewal or billing change alone is a weak reason to leave it. Self-hosted DataHub fits when a data residency or control obligation requires the metadata platform to run inside your own accounts, when sources span several clouds or on-premises systems, when you want an Apache-2.0 licensed core, and when you have people who can operate Kafka, a relational database and a search index as production services. DataHub's Kubernetes guide lists GMS, the MAE and MCE consumers and the frontend as its main components, each depending on those services, so the operating load is real.
The decision turns on three questions. First, the source mix: list every system that must appear in the catalog and check whether DataHub's connectors cover it, using the DataHub GitHub repository as the starting point and testing your least common source before committing. Second, data control obligations: write down where metadata may be stored, who may administer it, and whether your auditors expect the platform to sit under your own controls. Third, who will operate it: name the team that owns upgrades, the system-update job that runs on Helm upgrades, backups, SSO configuration and on-call coverage, and price that staff time against the SaaS fees you would otherwise pay. If those answers are unclear, the right next step is a short written evaluation rather than a migration.
Which scenarios favor Purview and which favor DataHub
This table maps common operating conditions to the platform that usually fits better, with the reason tied to what each product is built to do. Read each row against your own estate, then confirm the open items with vendors and your own environment before deciding.
| Scenario | Better fit | Reason |
|---|---|---|
| Azure-only estate with no platform team | Microsoft Purview | Unified Catalog is a managed SaaS service on the Purview Data Map, so Microsoft runs the catalog and you do not operate Kafka, databases or search. |
| Multi-cloud or on-premises sources | DataHub | DataHub's README lists more than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau, so you can confirm coverage for your own sources. |
| Strict residency for metadata | DataHub | Self-hosted DataHub Core runs inside your cloud account or data center, so catalog metadata stays under your control. Confirm where any managed service stores data. |
| Existing Microsoft identity | Microsoft Purview | Purview uses your Microsoft Entra tenant directly. DataHub needs an OpenID Connect provider such as Azure AD configured by your operators on DataHub Core. |
| In-house platform engineering | DataHub | Teams that already run Kubernetes and Helm can deploy DataHub with the acryldata Helm charts and own upgrades, including the system-update job. |
| Column-level lineage across mixed tools | DataHub | DataHub's README lists column-level lineage as a core feature, which suits teams tracing fields across warehouses and BI tools. Validate lineage depth for your sources in a pilot. |
| Limited RAM or small operations budget | Microsoft Purview | DataHub's Kubernetes guide says more than 7 GB of RAM is needed for DataHub and its dependencies on Minikube, plus Kafka, a relational database and search to operate. |
| Need for vendor-backed uptime terms | Microsoft Purview | DataHub Cloud lists a 99.5% uptime SLA, but DataHub Core carries no SLA, so self-hosting moves availability work to your team. Ask Microsoft for its current SLA terms. |
Where metadata lives and what that means for compliance
Purview, DataHub Core and DataHub Cloud place your metadata, logs and identity configuration in different hands. Each choice shifts which evidence you produce yourself and which you request from a vendor.
Purview as Microsoft-hosted SaaS
Unified Catalog runs on Microsoft's side of the boundary, so the catalog database, search index and service operations sit outside your administrative control. Your evidence comes from Microsoft's contractual and assurance documents plus your own configuration records for scans, roles and collections. Before a review, ask Microsoft which compliance reports cover the Purview service in your region and confirm the current certifications directly with Microsoft, since they change over time. Also confirm where metadata and processing for your tenant are stored.
DataHub Core in your own environment
With DataHub Core, the metadata service, Kafka, the relational database, the search index and the graph index all run in your cloud account or data center. Your team owns retention, backups, encryption keys, network segmentation and access logs for every one of those components. Expect your assessment to ask for evidence of each, so document the deployment topology and the operator runbooks from day one. DeployOpen can prepare that evidence and the controls behind it, but it does not issue audit reports or attestations.
DataHub Cloud as a managed service
DataHub Cloud moves operation of the platform to the company behind DataHub, which offers an uptime SLA and AWS PrivateLink connectivity. You still decide what metadata is ingested, but you depend on the vendor for hosting, patching and the audit trail of the service itself. Ask for the data processing terms, the subprocessors list, the regions where your metadata is stored and the independent reports the vendor holds. Confirm any certifications in writing with the vendor rather than relying on this page.
OIDC configured by your operators
On DataHub Core, the frontend server's OIDC settings must be configured by your team, which means your identity provider client registration, redirect URIs, secret storage and session settings all become controls you own. Misconfigured SSO can leave access tied to stale accounts or weak session handling, so record who approved each setting. Review the OIDC guide with your identity team before go-live and keep the configuration under change control.
OIDC enabled through DataHub Cloud
DataHub Cloud enables OIDC SSO through its interface, which shortens setup but moves part of the identity configuration into the vendor's console. Your access reviews still depend on your identity provider, so confirm how group membership maps to DataHub roles and who in your organization can change those settings. Ask the vendor for an audit log of administrative changes to SSO and role assignments, because an assessor will ask for it.
What DataHub adds to your operating footprint
Running DataHub means operating a set of stateful services, not a single application. The metadata service (GMS) serves reads and writes, the MCE Consumer and MAE Consumer process metadata change events, and the Frontend serves the web interface. Kafka carries the metadata change streams between these parts, a relational database (MySQL, PostgreSQL or MariaDB) holds the metadata, and Elasticsearch or OpenSearch powers search. A graph index on Neo4j or Elasticsearch supports lineage queries. Each of these needs its own backup, patching, sizing and failure runbook, and the platform team should own that list before the pilot begins.
The Kubernetes path uses Helm charts from the acryldata/datahub-helm repository, with a separate prerequisites chart for the dependencies. The Kubernetes guide states that more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube. Treat that figure as a minimum for a local test cluster, not a sizing guide for production. Production sizing depends on your metadata volume, ingestion schedule, search load and high availability choices, so ask your team to size each dependency against a representative source set and confirm the figures with the DataHub documentation for your chosen version.
Upgrades carry work of their own. The Helm chart runs a system-update job that applies schema changes and reindexes search indices when needed. Plan upgrade windows that allow for reindexing time on a catalog of your real size, test the job in a non-production cluster first, and keep the dependency versions in your change records. The Docker quickstart requires Docker with 8 GB of RAM and Python 3.10 or later. Use it to evaluate connectors and the interface on a laptop, but do not carry its single-host layout into production, because it does not reflect the Kafka, database and search topology your governance team will depend on.
DataHub Core, DataHub Cloud and Purview licensing side by side
DataHub Core is the Apache License 2.0 edition of DataHub, which your team installs, runs and upgrades in your own infrastructure. The software itself carries no licence fee, so your spending moves to the components the platform needs and to the people who operate them. The DataHub repository and its Kubernetes guide describe that footprint.
- Licence: Apache License 2.0, with no per-asset or per-user fee for the software.
- Components: GMS, the MAE Consumer, the MCE Consumer and the Frontend, plus Kafka, MySQL, PostgreSQL or MariaDB, Elasticsearch for search, and Neo4j or Elasticsearch for the graph index.
- Deployment: the Docker quickstart suits evaluation and needs Docker with 8 GB of RAM and Python 3.10 or later. Production uses the acryldata/datahub-helm charts plus a separate prerequisites chart.
- Upgrades: the Helm chart runs a system-update job that applies schema changes and reindexes search when needed, so plan a maintenance window and rehearse it in staging.
- Single sign-on: on Core, your team configures the OIDC settings on the frontend server.
Confirm the exact version you will deploy against the project's releases page before you size the cluster, because v1.7.0.1 and v1.6.0.3 are recent lines and v1.8.0 release candidates appeared in October 2026.
DataHub Cloud is the managed product from the company behind DataHub. The project's README describes it as managed, SLA-backed and enterprise-ready, with no infrastructure for you to run. It is commercially licensed, so the decision rests on the features it adds beyond the open-source edition and on how much operating work you want to hand over. The managed overview lists the differences.
- Operations: the vendor runs the platform, so your team does not operate Kafka, the search index or the database upgrade path.
- Uptime commitment: the comparison docs list a 99.5% uptime SLA. Check its scope, service credits and exclusions in the contract.
- Added features: data quality monitoring, AI anomaly detection, compliance forms and access request workflows are not in the open-source edition.
- Network path: AWS PrivateLink is available, which matters if sources and the catalog must avoid public internet paths.
- Single sign-on: OIDC SSO is enabled through the DataHub Cloud interface, so your team does not configure the frontend server.
Ask for the subscription terms in writing, including what is metered, where the managed instance runs, and how metadata moves between your sources and the service.
Microsoft Purview Unified Catalog is a SaaS governance catalog built on the Purview Data Map. Microsoft bills it per governed asset and per data quality processing unit (DGPU), so cost follows how many assets you govern and how much data quality work runs. Microsoft hosts and upgrades the service, which removes the server and database work and places your metadata on Microsoft's platform.
- Billing meters: governed asset count and DGPU consumption for data quality and health controls. Both move with scope, so model them with counts taken from your own tenant.
- Operation: Microsoft runs the service. Your team administers collections, glossary content, owners and sources.
- Azure fit: scanning Azure sources requires the least setup. Other sources depend on the connectors the Purview scanning options support.
- Exit path: plan extraction through the Atlas-compatible Data Map APIs before you commit, since a bulk export has to be built.
- Comparison basis: moving to a self-hosted catalog converts those meters into infrastructure, support and staff time, so the totals only compare when you count both sides fully.
Ask Microsoft for the current meter definitions, the DGPU consumption your planned data quality rules would generate, and the billing model that applies to your tenant before you compare totals.
What drives cost on each side
Purview bills by governed asset and data quality processing units, while a self-hosted DataHub Core bills you for infrastructure, people and migration work. Each card names one cost component, what drives it up or down, and what to request in a quote before comparing totals.
Purview governed assets and DGPU
Purview Unified Catalog charges recurring fees tied to the number of governed assets and to data quality processing units (DGPU) consumed by quality and health controls. Both scale with how broadly you scan and how often quality rules run. Ask Microsoft or your partner to model asset counts for each source, the scan frequency and the expected DGPU consumption for your quality rules, so you can see which settings move the bill most.
DataHub Core infrastructure
Self-hosted DataHub Core runs on Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch or OpenSearch for search, and a graph index on Neo4j or Elasticsearch, plus the GMS, MAE and MCE consumers and the frontend. This is recurring cloud or data center spend that grows with metadata volume and ingestion frequency. Request sizing for each dependency in your own environment before you commit to a footprint.
Engineering time to operate
Deploying, upgrading and tuning DataHub on Kubernetes takes platform engineering time that Purview does not require from your team. The Helm chart runs a system-update job during upgrades to apply schema changes and reindex search, so upgrade windows and rollback plans need planned capacity. Estimate this as a recurring staff allocation, and ask your integrator to state the effort for deployment, upgrades and tuning as separate line items.
DataHub Cloud subscription
If you choose DataHub Cloud instead of Core, the subscription replaces much of the infrastructure and operations work with a vendor-managed service, and it adds data quality monitoring, access request workflows and an SLA. The fee is a recurring commercial term that the vendor quotes separately. Ask for the price basis, what is included in each tier, and which features you would still need to run yourself.
Migration and rescanning labor
Moving from Purview means rescanning sources with DataHub ingestion, exporting curated glossary terms and ownership through the Purview REST APIs, and rebuilding domains and data products. This is one-time work whose size depends on source count, the amount of curated metadata and how many custom classifications you carry over. Ask for a source-by-source inventory and a validation plan for lineage and ownership before accepting a migration quote.
How a move from Purview to DataHub is structured
The sequence moves catalog metadata, curated business context and access controls from Purview into a self-hosted DataHub that your team operates, with each phase closing on a check you can verify before the next one starts.
Inventory sources and Purview objects
The data platform team lists every source registered in the Purview Data Map, the glossary terms, collections, owners, classifications and any lineage that people rely on, and marks which sources DataHub has a connector for. Owners of each source confirm what must be carried over and what can be left behind. Done when you have a signed-off inventory with a keep, rebuild or retire decision for each item and a list of connectors to confirm against the DataHub integrations list.
Stand up DataHub on Kubernetes with prerequisites
The platform team deploys the prerequisites chart for Kafka, the relational database, Elasticsearch or OpenSearch and the graph index, then installs DataHub from the acryldata/datahub-helm charts. Sizing, storage classes, backups and network policy are decided here, because the DataHub Kubernetes guide describes four core components that each depend on these services. Done when the GMS and frontend pods are healthy, a test ingestion reaches the search index, and the platform team has a documented runbook for upgrades that includes the system-update job.
Rescan sources with DataHub ingestion
Data engineers configure DataHub ingestion recipes for each source in scope and run them against the same systems Purview scanned, so technical metadata comes from the source rather than from a copy of Purview's view. Scheduled runs replace Purview scan schedules. Done when each source has a recipe in version control, a successful run, and a count of datasets and schemas that you can compare with the Purview entity inventory from the first step.
Export curated glossary and ownership data
Data stewards pull glossary terms, term relationships, owners and classification assignments out of Purview through its REST APIs, and save them as structured files that record the Purview identifiers. The migration sibling page covers the export method in detail. Done when every curated term and owner assignment exists in an exported file and a steward has spot-checked a sample against the Purview portal.
Map domains and data products
Governance leads translate Purview collections and any data products into DataHub domains, data products, owners and glossary structures, then load them with ingestion or the API. Ownership groups are reconciled with the identity directory at this point. Done when every migrated dataset has a domain or an explicit exception, each domain has an accountable owner, and the governance lead signs off on the mapping document.
Validate lineage and access
Engineers compare lineage graphs for priority pipelines in Purview with those produced by DataHub, including column-level lineage where the source connector supports it, and record any gaps as known limits. Security staff test the access model for each domain, because DataHub roles and policies are configured separately from Purview's. Done when priority lineage paths match or have documented exceptions, and access tests show that users see only the assets their role allows.
Cut over SSO and retire Purview
The identity team configures OIDC single sign-on for the self-deployed DataHub frontend, since this is an operator task on DataHub Core, and then moves users to the new catalog. Purview is set to read-only for a agreed period, after which its scans are stopped and the subscription is cancelled. Done when all users authenticate through the new SSO flow, stewards have confirmed the cut, and the final export of Purview metadata is archived with its retention record.
Questions buyers ask before switching from Purview to DataHub
How much effort does a self-hosted DataHub deployment take?
Effort depends mainly on the number of sources you ingest, how many environments you run, and how much of the stack your team already operates. DataHub Core runs four main components (GMS, the MAE Consumer, the MCE Consumer and the Frontend) and needs Kafka, a relational database, Elasticsearch or OpenSearch for search, and a graph index on Neo4j or Elasticsearch. Each of these is a service to size, back up, patch and monitor. The DataHub Kubernetes guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, which is a development floor, not a production sizing. Ask your team to map each dependency to an owner before you commit to a timeline.
Can an internal team run DataHub without outside help?
Yes, if the team already runs Kubernetes, Kafka, a managed relational database and a search cluster with on-call coverage. The open-source edition is Apache-2.0 licensed and has no license fee, so the recurring cost is infrastructure and staff time. The gaps usually sit in the first deployment, SSO wiring, ingestion jobs for each source, and upgrades. Upgrades matter in particular: the Helm chart runs a system-update job to apply schema changes and reindex search when needed, so someone must own that job and its rollback plan. If none of these skills exist in-house, a fixed-scope implementation with a written handover is one option to weigh against a managed product.
How long does a migration from Purview to DataHub take?
The timeline is set by how many sources you rescan, how much curated glossary and ownership data you need to carry over, how many domains and data products you must remap, and how much of the Kafka, database and search footprint is ready before ingestion starts. Purview's catalog content is usually rebuilt from source scans rather than copied, so the rescan scope often drives the schedule more than the glossary size does. No duration applies to every estate. Ask any implementation partner for a written scope that lists sources, glossary entries, owners and environments, and agree the deliverables before work starts.
What does the Kubernetes work involve for DataHub?
DataHub is deployed with Helm charts from the acryldata/datahub-helm repository, plus a separate prerequisites chart for its dependencies. The work includes setting values for each component, provisioning persistent storage and database credentials, sizing Kafka and search, configuring ingress and TLS, and wiring logging and metrics. The guide's four components each need resource requests and a clear upgrade path. Your platform team should also decide whether to run dependencies inside the cluster or use managed services, since that choice changes backup, failover and patching responsibilities. Confirm these decisions against the current Kubernetes guide for the release you plan to run.
Is DataHub Cloud the right step if we lack capacity?
DataHub Cloud may fit if the constraint is operating capacity rather than data residency. Its documentation lists features not in open source, including data quality monitoring, AI anomaly detection, compliance forms, access request workflows, a 99.5% uptime SLA and AWS PrivateLink. The trade-off is that the metadata service moves to a vendor-hosted platform, which you should review against your residency and contract requirements. Compare the subscription with the staff time and infrastructure cost of Core, and ask the vendor which environment the metadata will be stored in and who can access it.
How is SSO configured on self-deployed DataHub Core?
On DataHub Core, SSO uses OpenID Connect, and the operator must configure the frontend server. DataHub's OIDC SSO guide covers providers such as Google, Okta and Azure AD. Your team will register an application with the identity provider, set the redirect URI for your deployment, and supply the client ID, client secret and issuer settings through the frontend configuration, usually as Kubernetes secrets. Test login, group mapping and logout in a non-production environment first. DataHub Cloud enables OIDC SSO through its interface, so that step is simpler there.
Will lineage and glossary terms carry over from Purview?
Lineage and glossary terms do not transfer automatically, but both can be rebuilt. DataHub's feature list includes column-level lineage and a business glossary, and its ingestion covers more than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau. Lineage is usually better regenerated by running ingestion against the sources, while glossary terms, owners and domains are exported from Purview through its REST APIs and mapped to DataHub's model. Check each source connector for the lineage depth you need, and validate a sample of columns and terms before cutover.
What should we ask for in a quote for this work?
Ask for a written scope that names the sources to ingest, the environments to build, the identity provider for SSO, the Kubernetes platform and the dependency choices for Kafka, the database and search. Ask who owns each dependency after handover, what the upgrade and rollback process includes, and which deliverables are documentation, configuration and test evidence. Also ask how ongoing support, upgrades and testing are offered as a retainer. DeployOpen does not publish a price list, and a quote follows from that written scope.
When a fixed-scope implementation helps
A fixed-scope implementation fits teams that want DataHub or OpenMetadata running inside their own cloud account or data center, but do not have the spare platform capacity to design, install, harden and back it up themselves. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and supports self-hosted DataHub or OpenMetadata within the client's infrastructure. The work is usually agreed as a fixed scope with written deliverables and timelines before it starts. For a DataHub move, that scope typically covers the Kubernetes deployment, the Kafka, database and search dependencies, the ingestion sources you need on day one, OIDC single sign-on configuration on the frontend, and the backup and restore procedure for the metadata store.
Pricing is the question most procurement teams ask first, and DeployOpen does not publish a price list. A quote follows from the written scope, so the useful preparation is a list of the systems in scope, the number of ingestion sources, the environments (for example, a non-production cluster alongside production), the identity provider you will integrate, and any air-gapped or data residency constraints. Ask for the quote to separate one-time work (design, deployment, migration of glossary and ownership data, hardening) from recurring work (upgrades, backup testing, monitoring and support). Ask also what the quote excludes, such as your cloud infrastructure, Purview licensing during a parallel run, or staff time on your side.
Once the initial scope is delivered, many teams keep a retainer for ongoing upgrades and support, because DataHub releases move quickly and each Helm upgrade can run a system-update job that applies schema changes and reindexes search. Before you sign anything, confirm with the implementation partner who performs upgrades in a staging environment first, how rollback is handled, and how long a retainer runs. Those answers matter more to the platform team's operating load than the initial install does.
What to confirm before you decide
This sequence turns a Purview versus DataHub question into a written, component-level decision that your architecture, security and finance teams can sign off on. Each step ends with a check you can show to the people who approve the change.
Confirm Purview capabilities and billing in writing
Your procurement or licensing owner asks Microsoft for the current Unified Catalog terms in writing: which features are included, how governed assets are counted, how data quality processing units (DGPU) are metered, and what happens to classic Data Catalog entitlements if you hold them. Confirm which Purview features your data stewards actually use today, because that list defines the scope DataHub must cover. The step is done when you have a one-page inventory of used features and a written billing description tied to your current volumes.
List required source connectors and check coverage
Your platform team lists every source system the catalog must read, including Azure services, warehouses, BI tools, orchestrators and any on-premises or VPC-locked databases. Check each one against the DataHub integration list in the project README, which names more than 150 integrations including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau, and then confirm version support for each connector in the current DataHub documentation. Mark any source with no connector or only partial coverage, since those become custom ingestion work. The output is a coverage matrix with a status per source and an owner for each gap.
Decide hosting and data residency requirements
Your security and compliance leads record where metadata may live, which cloud accounts, regions, data centers or air-gapped networks are permitted, and whether any sources can send metadata outside your network. Because DataHub Core runs in your environment, this step decides whether you need only the open-source edition or whether a managed option is acceptable for some workloads, and what access controls, logging and key management the metadata store must meet. The step closes with a signed residency and hosting statement that names the approved locations and the reviewers.
Size the Kubernetes and data store team
Your platform lead inventories the people who will run DataHub day to day, including Kubernetes administration, operation of the Kafka, relational database and Elasticsearch or OpenSearch dependencies, and on-call coverage. The DataHub Kubernetes guide describes four main components (GMS, MAE Consumer, MCE Consumer and Frontend) plus Kafka, a MySQL, PostgreSQL or MariaDB database, search and a graph index, and it notes that more than 7 GB of RAM is needed for a Minikube test deployment. Compare that workload with the skills you have, and decide whether to staff it internally, retain a partner or buy DataHub Cloud for some use. The output is a named staffing plan with the skills gaps you intend to close.
Pilot ingestion on one data domain
Your data engineering team picks one domain with clear owners, a few well-supported sources and an existing glossary, then runs DataHub ingestion against those sources in a non-production environment. Measure what you can observe in your own environment: whether ownership, glossary terms, column-level lineage and classifications arrive correctly, how long a scheduled run takes on your volumes, and what breaks on schema changes. Test a DataHub upgrade on the pilot as well, since the Helm chart runs a system-update job that applies schema changes and reindexes search when needed. The step is done when stewards have reviewed the results and listed the gaps that must be fixed before wider rollout.
Confirm the upgrade and support model
Your engineering lead decides who applies DataHub releases, how often you test them, and who receives security advisories for the open-source components. Review the DataHub release page for the current versions and release candidates, and confirm with the vendor which support, upgrade and SLA options exist for DataHub Cloud or for an implementation partner, since the open-source edition carries no vendor SLA. The output is a written upgrade calendar, a rollback plan and a named support path for each component.
Get a written quote with named components
Your finance and procurement teams request a quote that lists each cost component separately: infrastructure for Kubernetes nodes, Kafka, the relational database, search and storage; ingestion compute; implementation and integration work; hardening and backup; training; ongoing support or retainer; and internal staff time. Ask for one-time costs and recurring costs in separate lines, and ask what drives each line up or down, such as source count, metadata volume and retention. DeployOpen fixed-scope engagements are agreed in writing before work starts, so ask for the scope, deliverables and timelines in the same document. The step is done when you can compare the quote against the Purview billing statement from the first step on equal terms.
How DeployOpen helps you evaluate and implement DataHub
DeployOpen treats the Purview versus DataHub decision as a written scope: what metadata sources matter, which lineage and glossary needs must hold, and what your team can operate. We then plan, build and hand over a DataHub deployment inside your own cloud account, data center or air-gapped network.
How we scope
- We list the sources to ingest, from Azure and other clouds to warehouses, BI tools and dbt projects.
- We define the lineage depth, glossary ownership and access model your governance team requires.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy DataHub on Kubernetes with Helm, sizing Kafka, the database, search and graph index for your load.
- We configure ingestion recipes, scheduling and OIDC single sign-on against your identity provider.
- We test ingestion, lineage accuracy, search and access controls in a staging environment before cutover.
How we hand over
- We document the architecture, upgrade procedure, including the system-update job, and backup and restore steps.
- We provide runbooks for ingestion failures, search reindexing and capacity changes your team will own.
- We walk operators and data stewards through the catalog so ownership and glossary upkeep stay in-house.
How we support
- Ongoing support, version upgrades and continuous testing are available as a retainer after handover.
- We can help your team review each DataHub release before you apply it in production.
- Ask us to confirm scope, deliverables and retainer terms in writing before committing to a plan.
