OpenMetadata vs DataHub: which catalog fits your team
Choose OpenMetadata if your team wants a catalog built around a single application server backed by MySQL or PostgreSQL, with Elasticsearch or OpenSearch for search and Airflow running metadata ingestion. The bare metal prerequisites are Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x, so the moving parts are familiar to a team that already runs a relational database, a search cluster and Airflow. Choose DataHub if your team is comfortable operating Kafka and wants metadata changes streamed through GMS and its MAE and MCE consumers, deployed on Kubernetes with the Helm charts from the acryldata/datahub-helm repository. The DataHub Kubernetes guide also needs a graph index on Neo4j or Elasticsearch, which is one more component to size and patch.
The decision turns on three things. First, existing skills: an Airflow-heavy data platform team will find OpenMetadata's ingestion model natural, while a team that already runs Kafka and Kubernetes will find DataHub's event-driven design familiar. Second, footprint: DataHub's Kubernetes guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, so compare that against OpenMetadata's documented minimum server sizing before you size a shared cluster. Third, governance needs: confirm whether you require column-level lineage, glossaries, data quality tests and domains from each product in the form your auditors and stewards will use, and test those features against your own sources rather than relying on feature lists alone.
Before committing, run a two-week proof of concept with one warehouse, one BI tool and one pipeline source. Measure how long a full ingestion takes, how upgrades behave, and who on your team gets paged when search or the queue falls behind. Ask each vendor to confirm the SSO configuration you need, since DataHub's OIDC setup on self-deployed Core is configured by the operator, and check the upgrade notes for the release line you plan to run. A DeployOpen engagement, if you choose one, starts from a written scope that covers this comparison work, so the proof of concept can be defined and priced before any build begins.
Which scenarios favor OpenMetadata or DataHub
This table maps common operating situations to the platform that usually fits better and the condition that decides it. Read each row as a starting point, then check the condition against your own estate, since several rows are closer than they look.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Existing Airflow estate for pipelines | OpenMetadata | OpenMetadata runs metadata ingestion through Airflow, so an Airflow team already has the scheduler, operators and upgrade habits. Confirm that your Airflow version matches the ingestion images required by OpenMetadata 2.0, which moved to Apache Airflow 3.3.0. |
| Existing Kafka platform with event consumers | DataHub | DataHub's architecture uses Kafka to stream metadata changes between its services. If your platform team already runs, monitors and scales Kafka, the extra component is familiar. Without Kafka, the Kafka-based design adds a dependency you would have to operate. |
| Small platform team with limited on-call capacity | Closer than it looks | Both need a database, a search service and a backing ingestion or streaming layer. OpenMetadata's bare metal prerequisites are Java 21, a supported database and Elasticsearch or OpenSearch, plus Airflow for ingestion. DataHub adds Kafka and a graph index. Count the stateful services you would page for before choosing. |
| Kubernetes-first shop | Either, depending on Helm practice | OpenMetadata documents production Kubernetes deployments on EKS, AKS, GKE and on-premises clusters. DataHub is deployed with Helm charts plus a separate prerequisites chart. Choose the one whose chart and upgrade path your team has already tested, and confirm current chart versions with each vendor. |
| Bare metal or air-gapped estate | OpenMetadata | OpenMetadata documents a bare metal install without Kubernetes, with stated minimum sizing for the server, database and search. DataHub's documented production path is Kubernetes with Helm. Confirm offline installation steps, image mirroring and dependency packaging with each vendor before committing. |
| Need for column-level lineage and data quality checks | Closer than it looks | Both list column-level lineage and quality features. OpenMetadata also covers profiling, freshness checks and OpenLineage events, while DataHub lists data quality assertions and monitoring. Test each against your own lineage sources and quality rules. |
| Need for OIDC single sign-on on self-hosted deployments | OpenMetadata | On self-deployed DataHub Core, the operator must configure the frontend server for OIDC providers such as Okta or Azure AD. Confirm the equivalent configuration effort for OpenMetadata's security settings in your environment. |
| Teams wanting a managed vendor option with SLAs | DataHub or OpenMetadata, via the maintainer | The DataHub README describes DataHub Cloud as managed and SLA-backed. Collate offers managed OpenMetadata. Both are vendor offers, separate from the Apache-2.0 self-hosted projects, so ask each vendor for written terms. |
How each catalog is built and what that means for operations
OpenMetadata and DataHub both run on a server, a relational database and a search index, but DataHub adds a Kafka streaming layer and a graph index on top. Each extra component is one more thing a platform team must patch, back up, size and monitor.
OpenMetadata server and its dependencies
The OpenMetadata server is a Java 21 service that sits in front of a relational database and a search index. Its bare metal prerequisites name MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. Ask your team whether it can run and patch Java 21 across the server nodes, and whether the chosen database version matches your standard support policy before you commit to a version.
Airflow-based metadata ingestion
OpenMetadata runs metadata ingestion through Apache Airflow, so Airflow is a required part of the stack rather than an optional extra. That means a second scheduler to upgrade and monitor alongside the catalog itself. OpenOpenMetadata 2.0 moved ingestion images to Python 3.12 with Airflow 3.3.0, so custom connector images need rebuilding. Confirm who owns the Airflow environment and its upgrade cadence.
DataHub's Kafka streaming layer
DataHub's GMS takes metadata changes through Kafka, and its MAE and MCE consumers process them asynchronously. Kafka brings its own brokers, topics, retention settings and consumer lag to watch, which is often a new competency for teams that do not already run it. Ask whether your organization already operates Kafka with the monitoring and on-call coverage this would require, because a stalled consumer delays catalog updates.
DataHub storage, search and graph index
DataHub needs MySQL, PostgreSQL or MariaDB for storage, Elasticsearch or OpenSearch for search, and a graph index on Neo4j or Elasticsearch. The graph index is the component most teams do not already run, so check whether Neo4j is an approved product in your environment or whether Elasticsearch will carry the graph role. Each store needs its own backup and restore test.
Deployment targets and sizing
OpenMetadata documents production deployments on Kubernetes (AWS EKS, Azure AKS, Google GKE and on-premises clusters), on bare metal, and Docker for local trials. DataHub is deployed on Kubernetes with Helm charts plus a separate prerequisites chart, and its guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube. Confirm which target your platform team already supports, and ask both vendors for a sizing guide for your expected metadata volume.
Upgrades that touch the search index
DataHub's Helm chart runs a system-update job on upgrades to apply schema changes and reindex search when needed, so upgrades can be long and must be rehearsed. OpenMetadata 2.0 lists breaking changes, including an llmConfiguration block for embedding credentials and a new Databricks auth format. Plan a staging upgrade for both, and check the release notes for every maintenance release you apply.
OpenMetadata vs DataHub side by side on governance and operations
This table compares how each catalog handles lineage, quality, glossary, connectors, APIs, SSO and deployment. Where a supplied fact is missing for one side, the cell says what to confirm with that vendor. Read it as a checklist of questions for a proof of concept, not as a final ranking.
| Capability | OpenMetadata | DataHub |
|---|---|---|
| Lineage scope | Table, column, dashboard, pipeline and metric lineage, with OpenLineage event integration | Column-level lineage listed as a core feature; confirm dashboard, pipeline and metric lineage coverage |
| Data quality and profiling | Data quality tests, profiling, freshness checks and Dynamic Sampling as the profiler default in 2.0 | Data profiling of schema, statistics, ownership and usage, plus data quality assertions and monitoring |
| Glossary and classification | Glossaries, classifications and domains, plus a Context Center in 2.0 | Business glossary listed as a core feature; confirm how classifications and domains are modeled |
| Connector count | More than 130 connectors for warehouses, BI tools, pipelines and ML platforms | More than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau |
| Programmatic access | REST APIs, a Python SDK, TypeScript packages and Java libraries; MCP enabled by default in 2.0 | Confirm the current SDK and API surface with the DataHub project before relying on it |
| SSO | Documented security guide; confirm which OIDC or SAML providers are supported in your version | OpenID Connect with providers such as Google, Okta and Azure AD; self-hosted Core requires operator configuration of the frontend |
| Deployment options | Kubernetes on EKS, AKS, GKE or on-premises clusters, bare metal without Kubernetes, and Docker for local trials | Kubernetes with Helm charts plus a separate prerequisites chart; Docker quickstart for trials |
| Managed option from the maintainer | Collate offers commercial enterprise capabilities and premium support | DataHub Cloud is described as managed and SLA-backed; confirm terms directly with the vendor |
What is free and what is paid in each catalog
OpenMetadata is released under the Apache License 2.0, so the server, its REST APIs, the Python SDK, the TypeScript packages and the Java libraries carry no license fee. The project is maintained by Collate, which also offers commercial enterprise capabilities and premium support. Those commercial offers are separate from the open-source project, so your self-hosted deployment does not include them by default.
- Self-hosted core: The open-source catalog runs in your own cloud account, data center or air-gapped network, and your team operates it.
- Recurring infrastructure: You pay for hosts that run Java 21, a MySQL 8.0.42 or later or PostgreSQL 15 or later database, Elasticsearch 9.x or OpenSearch 3.x for search, and Airflow for metadata ingestion.
- Collate commercial layer: Enterprise capabilities and premium support come from Collate under its own terms, so the scope of those features is set by the contract.
- Staff effort: Upgrades, backups and connector maintenance fall to your team unless you contract them separately.
Confirm with Collate which capabilities in your chosen edition are open source and which are commercial, and get that list attached to the quote.
DataHub is also released under the Apache License 2.0, so the self-hosted DataHub Core carries no license fee for the software itself. The company behind DataHub sells DataHub Cloud, which its README describes as managed, SLA-backed and enterprise-ready with no infrastructure to run. If you self-host the core, the operating work moves to your team, and that work has a real cost even though the license is free.
- Core license: The Apache-2.0 code is free to self-host, but Kafka, the metadata service, the relational database, the search cluster and the graph index all run on your infrastructure.
- Managed alternative: DataHub Cloud shifts infrastructure operation to the vendor. Request the SLA terms in writing before you rely on the uptime commitment.
- Self-deployed SSO: On DataHub Core, the operator configures the frontend server for OpenID Connect providers such as Google, Okta or Azure AD. DataHub Cloud enables OIDC SSO through its interface, so that configuration effort is different.
- Upgrade effort: The Helm chart runs a system-update job on upgrades to apply schema changes and reindex search when needed, so plan a maintenance window and test the upgrade first.
Ask the vendor which DataHub Cloud features and SLA terms apply to the tier you are considering.
Both catalogs have Apache-2.0 cores, so the license alone does not decide the cost. The open-source feature set is what your team self-hosts. Any enterprise, premium, managed or cloud capability is a separate commitment, and you should confirm it in writing for the specific edition and tier before you compare total cost.
- Feature scope: Ask each vendor which listed capabilities, such as lineage, glossary, data quality, SSO and audit, ship in the open-source build and which are commercial.
- Support terms: Get response targets, support hours and escalation paths in writing. Do not assume them from community channels.
- Upgrade path: Confirm whether commercial editions follow the open-source release line and how breaking changes are announced. OpenMetadata 2.0, for example, lists breaking changes to credential formats and ingestion images.
- Hosting and data location: For managed offers, confirm where metadata is stored, who can access it and how keys are held.
- Exit terms: Confirm how metadata and configuration can be exported and what the path back to self-hosting looks like.
Request a written quote that names the edition, the feature list and the support terms, so the comparison uses the same scope for both catalogs.
What drives the running cost of each catalog
The running cost of either catalog is mostly the cost of the dependencies around it, not the catalog service itself. For OpenMetadata, the bare metal prerequisites are Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x, plus Airflow for running metadata ingestion. The minimum server sizing in the OpenMetadata bare metal documentation is 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. That is a floor for evaluation and small estate sizing, not a production estimate. For DataHub, the Kubernetes guide adds Kafka and a graph index on Neo4j or Elasticsearch to a database and search layer, and it says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube. The Docker quickstart notes 8 GB of RAM. Those figures show that DataHub's pipeline runs on more moving parts, so the hosting line item usually grows faster with estate size. Ask each vendor or partner to price production sizing for your expected metadata volume, including Kafka brokers if you are on DataHub.
Recurring costs fall into four groups: infrastructure, people who patch and upgrade, ingestion job maintenance and any support or managed-service fees. Infrastructure recurs every month in the cloud account or data center. People costs recur through patching the database, search and Kafka layers, backing them up, and running upgrades. DataHub's Helm chart runs a system-update job on upgrades to apply schema changes and reindex search when needed, so plan a maintenance window and a rollback path for each upgrade. OpenMetadata 2.0 included breaking changes, including moving embedding credentials into an llmConfiguration block, a new Databricks auth format, and migrating Great Expectations to 1.3 before upgrading, so budget reviewer time for each release. Ingestion job maintenance recurs as sources change, and it runs in Airflow for OpenMetadata and in DataHub's ingestion framework. Support and managed services are optional, and DataHub Cloud or Collate would replace some of this infrastructure and operations work with a fee. Your quote should separate one-time work (design, integration, SSO setup, initial ingestion) from recurring work (hosting, upgrades, on-call, connector updates, and any retainer).
One-time costs are concentrated in evaluation, design and integration: sizing the stack, wiring SSO (DataHub's OIDC guide says self-deployed DataHub Core requires the operator to configure the frontend server), building ingestion pipelines for your warehouses and BI tools, and defining the governance workflow. Costs go up with the number of sources, the depth of lineage you require, the number of environments you run, and the strictness of your backup and recovery targets. Ask each provider for a written scope that states who builds and who runs each component, which versions and upgrade paths are covered, what happens to ingestion jobs during an upgrade, and what the monthly run cost would be at your source count. Confirm the current release and support status directly with each vendor, because version support windows change and any figure in a quote should match the release you will actually operate.
Moving a catalog from one platform to the other
This sequence moves a working catalog from one platform to the other without losing lineage, ownership or access rules, and it ends with a documented cutover and a retired source. Each step names the output that tells you it is safe to continue.
Inventory connectors and ingestion schedules
Your data platform or catalog owner lists every source the current catalog reads from, the connector or ingestion method used for each, the schedule it runs on, and the owner of each job. Include warehouses, BI tools, pipelines and any custom scripts that push metadata by API. The output is a written inventory with one row per source, and you know it is complete when a sample of recent metadata changes can be traced back to a listed source. Confirm the connector coverage for each source against the target's connector list before you assume a match exists.
Map lineage, glossary and ownership objects
Document how each object type in the current catalog maps to the target model. Tables, columns, dashboards, pipelines, glossary terms, classifications, owners and tags usually need explicit mapping, because the two platforms model entities and relationships differently. Export what the current platform can export, and note which lineage edges come from automated extraction and which were entered by hand. The output is a mapping sheet that a data steward has reviewed, and you know it is done when every object type has a target or a documented decision to drop it.
Stand up target dependencies and the platform
The platform team installs the target and its dependencies in your environment, using the deployment method your team has chosen. For OpenMetadata, the bare metal documentation lists Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, Elasticsearch 9.x or OpenSearch 3.x, and Airflow for ingestion. For DataHub, the Kubernetes guide lists Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch or OpenSearch, and a graph index on Neo4j or Elasticsearch. The output is a running target with backups configured, and you know it is ready when a test ingestion completes against a non-production source.
Rebuild ingestion jobs in the target model
Recreate each ingestion job in the target's model, not by copying the old job definition. OpenMetadata runs metadata ingestion through Airflow, while DataHub supports both push and pull ingestion through its Kafka-based design, so schedules, credentials and failure alerts must be rebuilt for the new model. Keep the old jobs running in parallel until the new ones match the inventory. The output is a set of target jobs with named owners, and you know it is done when each job's row counts and object counts match the source within the tolerance your team sets.
Validate search, permissions and lineage
Test search results, lineage graphs, glossary links and access controls with a defined set of named users and sample assets. Check that role-based and group-based visibility matches the old platform, and that single sign-on works for each identity group. Confirm that custom properties and classifications appear where your stewards expect them. The output is a signed test log listing each check, the result and the owner, and you know the cutover can proceed when no high-impact check is open. Confirm the SSO setup in the target's own documentation, because self-deployed DataHub Core requires the operator to configure the OIDC frontend.
Cut over users and communicate changes
Announce a cutover date, publish links and short guidance for the new search and navigation, and move users in groups so support requests stay manageable. Update bookmarks, API clients and any integrations that point to the old catalog's endpoints. Keep the old platform read-only for a defined period so users can compare results. The output is a cutover record showing which groups moved, which integrations were repointed, and the open issues, and you know it is complete when the support queue shows no unexplained gaps in search or lineage.
Retire the old platform and archive its metadata
After the read-only period and sign-off from the data owners, export a final snapshot of the old catalog, store it under your retention policy, and shut down its ingestion jobs, search indices and databases in a controlled order. Remove its credentials from secrets stores and revoke service accounts. The output is an archive record with checksums and an approval from the catalog owner, and you know the retirement is complete when the old endpoints no longer respond and the backup restore has been tested. Note that the OpenMetadata 2.0 breaking changes, including the llmConfiguration move and the Python 3.12 image rebuild, apply only to OpenMetadata upgrades and do not affect a migration into it.
Where OpenMetadata and DataHub implementations run long
The most common slowdowns differ by platform. For OpenMetadata, schedule risk usually sits in ingestion: the Airflow version that runs metadata ingestion has to match what the 2.0 line expects, and OpenMetadata 2.0 moved ingestion images to Python 3.12 with Apache Airflow 3.3.0, so custom ingestion images must be rebuilt. Teams with custom connectors or Great Expectations checks also need to migrate to 1.3 before upgrading. For DataHub, the slowdown usually comes from operating the streaming layer: Kafka topics, the MCE and MAE consumers and schema changes all have to stay healthy, and the Helm chart's system-update job runs on upgrades to apply schema changes and reindex search. Plan an upgrade rehearsal in a non-production cluster and time the reindex on a copy of production-sized data before committing to a date.
Identity integration is where DataHub Core projects most often stall. The OIDC SSO guide for DataHub lists providers such as Google, Okta and Azure AD, but on self-deployed DataHub Core the operator configures the frontend server, while DataHub Cloud enables OIDC SSO through its interface. Confirm early whether your identity team can register the application and supply the redirect and client settings. OpenMetadata's authentication and security setup needs the same early check against the OpenMetadata security documentation, along with role mapping for stewards and administrators.
Connector coverage gaps and lineage scope affect both platforms and are often discovered late. DataHub's README lists more than 150 integrations and OpenMetadata lists more than 130 connectors, but a named list is not a guarantee for your version of a source system or for a proprietary tool. Before statements of work are signed, ask the client for a data source inventory with versions, owners and access methods, identify any sources that need custom work, and agree in writing on the lineage depth required (table, column, dashboard or pipeline). Get sign-off from the data owners on that scope, because it determines how much ingestion and validation effort the project carries.
Questions buyers ask before choosing a catalog
How much total effort does it take to run OpenMetadata compared with DataHub?
Both are multi-service systems, so the effort comes from the dependencies you operate, not from the catalog alone. OpenMetadata's bare metal documentation lists Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, Elasticsearch 9.x or OpenSearch 3.x, and Airflow for metadata ingestion. DataHub's architecture adds Kafka for streaming metadata changes, plus a graph index on Neo4j or Elasticsearch, and its Kubernetes guide describes four main components. Count each service you must patch, back up, monitor and upgrade. Ask each vendor for a reference topology for your expected source count and metadata volume, and confirm how the sizing changes as that volume grows.
Can our team self-host either catalog without outside help?
A team with Kubernetes or database operations experience can often run either catalog, but the answer depends on skills you already have. OpenMetadata documents production paths on EKS, AKS, GKE, on-premises clusters and bare metal, and its prerequisites are mostly standard databases, search and Airflow. DataHub is deployed with Helm charts from its own repository plus a separate prerequisites chart, and Kafka adds a streaming system your staff must understand. If Kafka is not already run in-house, that is a material gap. Map your current skills against each dependency list before deciding.
How long does an implementation take, and what drives that timeline?
The timeline is driven by source count, connector coverage, identity setup and how much governance you configure at launch. OpenMetadata lists more than 130 connectors and DataHub lists more than 150 integrations, so check that your specific warehouses, BI tools and pipelines are supported at the versions you run. Single sign-on is another driver: DataHub's OIDC guide says self-deployed Core requires the operator to configure the frontend server. Neither vendor's supplied material gives a standard duration, so ask for one in writing against your scope. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts.
What does ongoing upgrade work look like for each catalog?
Upgrades carry real migration steps for both products, and these should be scheduled, not treated as routine patches. OpenMetadata's 2.0 release notes list breaking changes, including 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. DataHub's Helm chart runs a system-update job on upgrades to apply schema changes and reindex search when needed. Review the release notes for each version you plan to cross, and test upgrades in a non-production environment that matches your data volume.
Which catalog fits better as an Amundsen replacement?
Either can serve as an Amundsen successor, but the cutover path differs. Amundsen was archived in September 2026 with no service release since March 2024, so both options need a migration plan. OpenMetadata documents an Amundsen connector that ingests from Amundsen's Neo4j backend, which is a concrete starting point for metadata. DataHub is a different architecture, so you would rebuild ingestion and search rather than port them. Choose based on whether you want to keep Airflow-based ingestion (OpenMetadata) or streaming push and pull ingestion over Kafka (DataHub), then test the cutover with your real ingestion jobs and users.
Does a managed tier change the decision between these catalogs?
A managed tier can remove much of the operating burden, but it changes cost and control, so model both paths. Collate maintains OpenMetadata and offers commercial enterprise capabilities and premium support. DataHub's maker sells DataHub Cloud, which its README describes as managed and SLA-backed with no infrastructure to run. Ask each vendor which features are reserved for the paid tier, where your metadata is hosted, what the exit path looks like, and how pricing scales with assets and users. DeployOpen does not run these vendors' managed services, and its work is self-hosted implementation inside your infrastructure.
Which governance features are included in the free open-source versions?
Both Apache-2.0 projects include substantial governance features, so the difference is in depth and fit rather than presence. OpenMetadata supports table, column, dashboard, pipeline and metric lineage with OpenLineage events, plus data quality tests, freshness checks, glossaries, classifications and domains. DataHub lists column-level lineage, a business glossary, profiling, and data quality assertions and monitoring. Build a checklist from your own controls, such as classification, access policy and audit needs, and confirm each item against the current release. Ask vendors for documentation of any feature they describe as enterprise-only.
What should our security team check before approving either catalog?
Start with authentication, network exposure and how the catalog stores credentials for connected sources. DataHub supports single sign-on through OpenID Connect providers such as Google, Okta and Azure AD, but on self-deployed Core the operator configures the frontend. OpenMetadata publishes security documentation that describes its deployment security options. Review how each catalog stores connector credentials, which services hold copies of metadata, and how logs and search indices are protected. Confirm current controls against the vendor documentation for your release, since supplied material does not cover every setting.
How DeployOpen helps you choose, implement or migrate a catalog
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For OpenMetadata vs DataHub, we start with your sources, identity setup and operating constraints, then agree what the catalog must do before any installation begins.
How we scope
- We review your data sources, warehouses, BI tools and orchestrators before choosing a catalog architecture.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We confirm which database, search and ingestion dependencies your platform team already operates.
- The written scope names the lineage, glossary and governance features you need from day one.
How we build
- We install and configure the chosen catalog in your environment, on bare metal, Kubernetes or Docker.
- We connect ingestion jobs, identity provider single sign-on and search indices to your existing systems.
- We test connectors, lineage paths and access controls against the scope before sign-off.
- Upgrade and migration steps are planned against each release's breaking changes and dependency versions.
How we hand over
- You receive architecture notes, configuration records and runbooks for every component in the stack.
- Ingestion schedules, credentials handling and backup procedures are documented for your operators.
- Your team runs a walkthrough covering ingestion failures, search reindexing and user onboarding.
- Compliance evidence, such as access settings and change records, is organized for your assessors.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover catalog version upgrades, connector maintenance and dependency patching.
- Ask any quote to state which upgrade and testing tasks are included and how often they run.
- We can help you reassess the choice if your source estate or release direction changes materially.
