When Alation or self-hosted DataHub fits your data discovery needs
Choose Alation when the catalog's value to your organization depends on features that Alation delivers in its own service and your team wants Alation to host, upgrade and operate the platform. The Alation Cloud Service is the option Alation's documentation calls the recommended path, and it is the only place where some features are offered, including the Alation Agent, the Microsoft Teams and Slack integrations, the Chrome Extension, OAuth 2.0 API authentication and AWS PrivateLink on Enterprise+ plans. If your data stewards already work inside those tools every day, or your organization has standardized on Alation's curation workflows, a move carries real retraining and integration work. Self-hosted DataHub fits when the catalog itself must run inside your own network, when open-source licensing under Apache-2.0 matters to your procurement rules, and when your platform team can own a Kubernetes deployment with Kafka, a relational database, a search index and a graph index.
Four questions should drive the decision. First, where must the catalog run? If a residency rule or a contract requires the metadata service and its stores to stay in your environment, customer-managed Alation and self-hosted DataHub both qualify, but only one of them is cloud-only for certain features. Second, which Alation features do your users rely on day to day? List them from Alation's own feature documentation and check each one against DataHub Core before any renewal talks. Third, who will operate the platform? DataHub Core is deployed with Helm charts from the acryldata/datahub-helm repository plus a prerequisites chart, and the Helm chart runs a system-update job on upgrades, so someone on your team must own that cycle. Fourth, which SSO path do you need? On self-deployed DataHub Core, your operators configure the OIDC frontend themselves, while DataHub Cloud handles OIDC through its interface.
Ask Alation for a written list of which features in your current contract are cloud-only and which are included in customer-managed Alation, and ask DataHub's maintainers or a qualified implementation partner to confirm how each of your required features maps to DataHub Core. Pilot both options against one or two of your highest-value data sources and time the work your stewards actually do. Be cautious about DataHub Cloud features such as compliance forms, access request workflows and AI anomaly detection, because they sit outside the open-source edition and change the answer if your requirements depend on them. Teams with strong platform engineering and clear ownership of the catalog usually find self-hosted DataHub a workable fit, while teams that depend on Alation's cloud-only integrations or lack capacity to run the platform should keep Alation or weigh the choice carefully.
Which option fits which scenario
This table compares the two platforms across the situations that usually decide the choice, such as network placement, cloud-only features, sign-in control and team size. Read each row for the better fit and the condition that would reverse it. Confirm feature availability for your Alation edition and plan before deciding.
| Scenario | Better fit | Reason and reversal condition |
|---|---|---|
| Catalog must stay inside your own network | DataHub Core | You install it on your own Kubernetes or Docker hosts. Alation has a customer-managed option, but confirm with Alation which features it omits before relying on it for air-gapped use. |
| Depends on Alation Cloud Service features | Alation | Alation's documentation lists cloud-only features such as the Alation Agent, Teams and Slack integrations, the Chrome Extension and OAuth 2.0 API authentication. Choose DataHub only if your team does not use these. |
| Needs OIDC sign-in with operator-controlled configuration | DataHub Core | DataHub's OIDC guide says self-deployed Core requires the operator to configure the frontend server. Choose Alation if you prefer the vendor to manage identity setup, and confirm the options in your edition. |
| Small platform team with limited Kubernetes operations | Alation | DataHub Core runs Kafka, a relational database, Elasticsearch or OpenSearch and a graph index, all of which you must patch and monitor. A vendor-hosted Alation Cloud Service removes that work, though its cost should be compared in a written quote. |
| Team already runs Kubernetes and its data platform | DataHub Core | The Helm chart and prerequisites chart fit existing cluster tooling. If your platform team lacks capacity for the dependencies, Alation becomes the better fit. |
| Need for AI documentation or observability features | Alation | Features such as DataHub Cloud's AI anomaly detection and data quality monitoring are not in open source. Choose DataHub Cloud, a separate commercial product, if you need them while staying on DataHub. |
| Data residency requires self-hosted operation with no vendor access | DataHub Core | Self-hosted DataHub keeps metadata inside your environment. Alation customer-managed deployment also keeps data on your hosts, so confirm support terms and telemetry settings with Alation. |
| Existing Alation curation must carry over | Alation | Curated descriptions, glossary and stewardship in Alation need an export plan before any move. Choose DataHub when a rebuild of curation is acceptable to your stewards. |
Where the catalog metadata lives under each model
The first decision is which copy of the catalog you are actually operating. Alation Cloud Service runs the instance on Alation's servers, and Alation administers and upgrades it. Customer-managed Alation moves that work to you: you host, install and maintain the software, so the metadata sits in your environment. DataHub Core is a third model. It is Apache-2.0 software you deploy on your own Kubernetes cluster with the Helm charts, which means your team runs the metadata service, Kafka, the relational store, the search index and the graph index. DataHub Cloud is a separate managed product from the company behind DataHub, not a hosting option for DataHub Core, so a contract for it does not change where your self-deployed instance keeps its data. Confirm the hosting model in writing with your Alation account team before you compare anything else.
Metadata leaves your network in different ways under each model. With the cloud service, catalog content, lineage and curated descriptions are stored on Alation's infrastructure, and the connectors that reach your sources are the part you must check closely, since the Alation Agent is listed among features available only in the cloud service. With customer-managed Alation or DataHub Core, the ingestion path stays inside your network as long as your sources and the catalog are reachable from it. In every model, ask who holds the encryption keys for stored metadata, where backups are written, who can restore them, and how long backups and logs are retained. Your security team should also review which connector credentials the catalog stores and whether they are kept in your existing secrets manager. Ask Alation for the documented backup and key management arrangements for the cloud service, and write down who in your organization owns the equivalent tasks for the self-hosted options.
Data residency and compliance outcomes depend on your own controls, your configuration and the independent auditor who assesses them, not on the catalog product alone. A self-hosted deployment does not make a control effective by itself, and a vendor-hosted service does not remove your obligation to evidence it. Before choosing, map each applicable requirement to a named owner, a configuration and a piece of evidence, such as access reviews, encryption settings and restore tests. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or certifications. Your auditor and any certification body decide whether the outcome meets your obligations.
Identity, compliance and operating risks to weigh
Alation and DataHub differ less in search quality than in who signs users in, who collects audit evidence, who patches the platform and how traffic reaches it. Each card below is a decision point where the answer depends on your own identity stack, assessor and network design.
OIDC sign-in on DataHub Core
On self-deployed DataHub Core, the frontend server must be configured by your team, so OIDC sign-in with a provider such as Okta or Azure AD is a setup task you own. Alation's sign-in options depend on whether you run the cloud service or customer-managed software, so compare them directly. Before committing, confirm the OIDC settings, group-to-role mapping and how sessions end when a user is offboarded in your identity provider.
Alation API authentication scope
Alation documents OAuth 2.0 API authentication as a feature available only in Alation Cloud Service. If your integrations, exports or access reviews depend on OAuth 2.0 rather than tokens, customer-managed Alation may not give you that path. Ask Alation in writing which authentication methods your deployment type supports, and whether your scripts and migration tooling need to change before a move.
Audit evidence and access reviews
A self-hosted catalog produces logs, role assignments and configuration records that your assessor will ask to see, and nobody else collects them for you. Map which controls cover catalog access, change history and privileged administration, then decide where logs are stored and how long they are kept. Confirm with your assessor which evidence they accept from a self-hosted tool and how often access reviews must run against DataHub roles and Alation users.
Upgrade ownership
With Alation Cloud Service, Alation administers and upgrades the instance. With DataHub on Kubernetes, your team runs Helm upgrades, and the chart's system-update job applies schema changes and reindexes search when needed. Assign an owner for upgrade testing, rollback and dependency patching across Kafka, the database and Elasticsearch or OpenSearch, and agree the change window with the teams that depend on the catalog.
Network connectivity and private access
Where the catalog is reached from matters for data residency and for connectors that read sources inside a private network. Alation documents AWS PrivateLink connectivity as a cloud-service feature on Enterprise+ plans, and DataHub Cloud lists PrivateLink among its managed features. On DataHub Core, you design ingress, egress and connector paths yourself. Confirm which private connectivity your Alation plan includes and which network paths your source systems need.
What running DataHub Core on Kubernetes requires
Running DataHub Core on Kubernetes means installing two things from the acryldata/datahub-helm repository: the main datahub Helm chart, which deploys the four core components (GMS, the MAE Consumer, the MCE Consumer and the Frontend), and a separate prerequisites chart that deploys the dependencies those components need. The dependencies are Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch for search and a graph index on Neo4j or Elasticsearch. Your platform team should decide early whether to run these stateful services inside the cluster, which the prerequisites chart supports, or to point DataHub at services that already sit under your database and messaging operations. That choice drives who patches, backs up and restores Kafka, the metadata database and the search index, so it belongs in the cost comparison, not in a later sprint.
Memory is the first sizing number to check. The Docker quickstart requires Docker with 8 GB of RAM, and the Kubernetes guide says more than 7 GB is needed to run DataHub and its dependencies on Minikube. Both figures describe a trial, not production. For a production cluster, size from the drivers that move the load: the number of sources and the frequency of ingestion runs, the number of tables and columns with column-level lineage enabled, the volume of usage and profiling data you collect, the search index size, and the number of concurrent users. Ask your own data team to measure a representative source set on a staging cluster and size production from those results. Confirm the current resource requests and limits in the chart's values files with the release you plan to deploy.
Plan upgrades as a controlled change. The Helm chart runs a system-update job on upgrades to apply schema changes and reindex search indices when needed, so an upgrade can take longer and touch the search index as well as the application pods. Schedule a rehearsal in a non-production namespace, back up the metadata database and the search indices first, and confirm the release notes for the target version, such as the DataHub releases page, before you change production. Ask who owns this runbook after go-live. Every DataHub Core upgrade is work your staff performs, and that recurring effort is the part of the self-hosted cost most often underestimated.
What each cost component covers on both sides
What does an Alation subscription cover in each deployment model?
An Alation subscription is a recurring fee that covers the software license and, depending on the model, the hosting and upgrades. With Alation Cloud Service, Alation runs the instance on its servers and administers and upgrades it, so the fee carries that operating work. With customer-managed Alation, the license fee is only part of the spend, because your team hosts, installs and maintains the software. Ask Alation for a written quote that states the deployment model, the plan tier, which features are included (some features are cloud-only), user or asset count, support terms and renewal uplift, and whether any cloud-only features are priced separately.
What infrastructure does self-hosted DataHub need to run?
Self-hosted DataHub Core is Apache-2.0 licensed, so there is no license fee, but you pay for the infrastructure and the people who run it. The DataHub Kubernetes guide lists four main components (GMS, the MAE Consumer, the MCE Consumer and the Frontend), plus Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch for search, and a graph index on Neo4j or Elasticsearch. The 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 sizing guide. Production sizing depends on the number of sources, metadata volume, ingestion frequency and availability targets, so ask your platform team to size it against a test load.
What do Kafka, databases and search add to the DataHub bill?
These are the dependencies that DataHub needs for metadata streaming, storage and search, and each one is a recurring infrastructure cost plus operating effort. Kafka carries metadata change events, the relational database stores metadata, and Elasticsearch or OpenSearch powers search. Costs rise with cluster size, replication for high availability, backup retention, and managed versus self-run choices. Many organizations already run Kafka, PostgreSQL or Elasticsearch for other systems, which can lower the marginal cost, but shared clusters need capacity planning. Ask for a list of every dependency, its version support policy and the backup and restore procedure before you commit to a design.
How much does connector setup cost for each catalog?
Connector setup is mostly a one-time effort to configure each source, schedule ingestion and validate the results, followed by a recurring effort to maintain connectors when sources change. DataHub lists more than 150 integrations in its README, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau, and you should confirm coverage for your own systems. Cost rises with the number of sources, custom or unsupported systems, and the access model for each source. On the Alation side, connector and data source work is part of the subscription's operating model, so ask which connectors and sync features are included in your plan and who maintains them.
What does a content migration from Alation involve and who pays for it?
Content migration is a one-time effort that moves curated descriptions, glossary terms, ownership and custom fields from Alation into DataHub. Alation's REST APIs return the data sources, schemas, tables, columns and custom fields that you need, and the effort depends on how much curation exists, how many custom fields are in use and how much of it maps cleanly to DataHub concepts. Features with no direct DataHub equivalent need a decision about whether to rebuild them or retire them. Internal staff can do this work, while an implementation partner can scope and deliver it under a written, fixed scope. Ask for a written inventory of assets and fields before agreeing on effort.
What does upgrade work look like for each option?
With Alation Cloud Service, Alation administers and upgrades the instance, so your recurring upgrade effort is mainly testing integrations and user acceptance. With customer-managed Alation or self-hosted DataHub, your team plans, tests and applies each upgrade. The DataHub Helm chart runs a system-update job on upgrades to apply schema changes and reindex search indices when needed, which is useful but still needs a maintenance window, a rollback plan and a staging environment. Budget for upgrades as a recurring activity, and ask Alation for its upgrade cadence and notice period in the contract.
How much staff time does a self-hosted catalog need compared with a subscription?
Staff time is the recurring cost most often underestimated. A self-hosted DataHub needs people who run Kubernetes, the dependencies, backups, monitoring, security patching, SSO configuration (the OIDC frontend must be configured by the operator on DataHub Core) and on-call coverage. A subscription shifts some of that work to the vendor, but customer-managed Alation still leaves hosting and maintenance with you. Estimate the time from your own platform team's capacity, and ask Alation which tasks its cloud service covers so the comparison is like for like.
What should a written quote for a self-hosted catalog project include?
A useful quote separates one-time work from recurring work and names every component. For the Alation side, ask for the subscription terms, deployment model, plan tier, included and excluded features, renewal uplift and export support. For self-hosted DataHub, ask DeployOpen for a fixed-scope proposal that lists architecture and sizing, Kubernetes and dependency setup, connector scope, content migration, SSO and hardening, testing, documentation, training and handover, plus retainers for upgrades and ongoing support if you want them. DeployOpen does not publish a price list, and a quote follows from the written scope, so the scope document is what makes the numbers comparable.
How a move from Alation to DataHub is planned
The sequence moves the parts of Alation that people rely on into a self-hosted DataHub deployment, proves that discovery works against real sources, and then retires Alation access in a controlled way. Each phase ends with a check that the team can sign off before the next one starts.
Inventory the Alation features in use
Start by listing what your users actually do in Alation: searches, lineage views, glossary terms, stewardship workflows, article publishing, Compose queries, and any integrations with Slack, Microsoft Teams, the Chrome Extension or the Alation Agent. Check each item against the cloud-only feature list in Alation's documentation, because some of them have no direct DataHub equivalent and need an explicit decision. The output is a written inventory with an owner for each feature and a keep, replace, or retire decision. Confirm the current feature availability with Alation for your plan and deployment type before you finalize it.
Stand up DataHub Core on your Kubernetes
The platform team deploys DataHub Core with the Helm charts from the acryldata/datahub-helm repository and the separate prerequisites chart for Kafka, the relational database, Elasticsearch or OpenSearch, and the graph index. Configure OIDC sign-in on the frontend yourself, since DataHub Core requires the operator to set it up, and follow the upgrade procedure that runs the system-update job. The step is complete when the components are healthy, a test user can sign in through your identity provider, and backups of the storage layer are restorable in a test restore.
Rebuild ingestion from DataHub connectors
Recreate the metadata feeds using DataHub's own ingestion connectors for each source your Alation instance currently reads, such as the warehouses, BI tools and transformation layers in your estate. Run them in a non-production environment, compare the returned schemas, tables and columns with what Alation shows for the same sources, and document any gaps in connector coverage or lineage depth. The step closes when every in-scope source has a scheduled ingestion job and a reconciliation report signed off by the data owners.
Move curated descriptions, glossary and ownership
Export curated content from Alation through its token-authenticated REST APIs, covering table and column descriptions, glossary terms, certifications and steward assignments, then load them into DataHub using the glossary YAML import and the ownership and documentation fields. Prioritize the assets that users search for most, and keep a mapping file that links each Alation object to its DataHub URN so later checks are repeatable. The migration sibling topic covers the export and API details, so use it for the mechanics. This step is done when a sample of curated assets shows matching descriptions and owners in DataHub, reviewed by the stewards.
Plan around features with no DataHub equivalent
For each item marked replace or retire in the inventory, decide how the business function will continue. Options include keeping an Alation article archive as read-only documentation, moving Slack or Teams notifications to a custom integration built on DataHub's APIs, or accepting the loss of a workflow your users rarely use. DataHub Cloud features such as access request workflows and compliance forms are not in open source, so any need for them must be met by a different control or stay outside the migration. Record each decision with the owner who accepted it, because these are the items most likely to cause complaints after cutover.
Run DataHub alongside Alation in parallel
Keep Alation available for a defined period while a pilot group of analysts and stewards run their daily searches and lineage checks in DataHub. Track the questions they could not answer, the search results they ranked differently, and any ingestion failures, and fix them in the connector configuration or the curated content. Hold a review with the data owners to confirm that the core workflows cover what they need. The parallel run is complete when the open issue list contains no blockers for the agreed workflows and the pilot group has confirmed it.
Cut over to DataHub
Announce the cutover date, freeze curated edits in Alation, run a final incremental export and ingestion, and point users, bookmarks and internal links to DataHub. Confirm that the sign-in path, ingestion schedules and backup jobs are running in production, and keep the rollback steps documented in case a critical issue appears. The cutover is complete when the production checks pass and the support channel shows no unresolved blocking issues.
Retire Alation access and retain records
After the agreed stabilization period, remove user access to Alation, revoke API tokens and integrations, and export a final archive of the metadata and content your records policy requires you to keep. Confirm the retention arrangement with your legal and compliance team and with Alation's contract terms, since the notice and data return conditions are set in your agreement. The step closes when access is removed, tokens are revoked, the archive is verified, and the decommissioning record is filed.
What buyers ask before choosing DataHub or Alation
Is DataHub Core free to use?
Yes, the open-source edition of DataHub is licensed under the Apache License 2.0, so the software itself carries no license fee. The cost you still pay is the infrastructure to run it: Kubernetes capacity, Kafka, a MySQL or PostgreSQL database, Elasticsearch or OpenSearch, and a graph index. The DataHub Kubernetes guide notes that more than 7 GB of RAM is needed to run DataHub and its dependencies even on Minikube, so a production footprint will be considerably larger. Staff time for installation, upgrades, connector maintenance and access setup is the other recurring cost. Confirm current license terms in the DataHub repository before you rely on them.
What drives the total cost of a self-hosted DataHub compared with Alation?
The cost drivers are the number of metadata sources, the volume of metadata ingested, the number of users, the availability you need, and how many people maintain the platform. On the Alation side you pay a subscription, and the choice between Alation Cloud Service and customer-managed Alation changes who runs the servers and upgrades. On the DataHub side you pay for compute, storage and search capacity, backups, monitoring and staff time. Ask Alation for a written quote that separates subscription, support tier and any feature tier, and build your own model for infrastructure and people. A cost comparison by component will show where the balance falls for your environment.
How long does a move from Alation to DataHub take, and what does it depend on?
The duration depends on the scope, not on a fixed rule. The main variables are how many data sources you must reconnect with DataHub's own ingestion, how much curated content you need to move (descriptions, glossary terms, ownership and certifications), how many Alation features your teams rely on that have no DataHub equivalent, and how many users need retraining. Parallel running with Alation during cutover adds time but reduces risk. Agree the timeline in writing against a defined scope before any work starts, and ask any implementation partner to show the dependencies behind their estimate.
Can an internal team run DataHub without an outside partner?
A capable platform team can run DataHub Core in-house, provided it has Kubernetes operations skills and clear ownership of Kafka, the database, search and the connectors. The DataHub Helm chart runs a system-update job on upgrades to apply schema changes and reindex search indices when needed, so upgrades are a routine but planned task that needs a test environment. Teams without that experience, or without spare capacity during a migration, often bring in a partner for the initial build, hardening, backup design and handover. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and works under a fixed scope agreed in writing.
What does DataHub Cloud add that the open-source edition does not include?
DataHub Cloud is the managed product from the company behind DataHub. According to the DataHub comparison documentation, it adds data quality monitoring, AI anomaly detection, compliance forms, access request workflows, a 99.5% uptime SLA and AWS PrivateLink. The project README also describes it as managed, SLA-backed and enterprise-ready with no infrastructure to run. Choose it if you want the vendor to operate the platform. Choose Core if you need the software inside your own cloud account or data center. Confirm the current feature list with the vendor, because managed offerings change.
Which Alation cloud-only features would we lose, and how do we plan for them?
Alation's documentation lists features available only in Alation Cloud Service, including the Alation Agent, Microsoft Teams and Slack integrations, the Chrome Extension, OAuth 2.0 API authentication and AWS PrivateLink connectivity on Enterprise+ plans. Start by inventorying which of these your users depend on, then check whether DataHub or a comparable open-source option covers the same need, for example through its own integrations, OIDC sign-in or API access. Where no equivalent exists, record the gap, decide whether a workaround is acceptable, and confirm the current list in the Alation documentation before you commit.
How does single sign-on work on self-hosted DataHub?
DataHub supports single sign-on through OpenID Connect providers such as Google, Okta and Azure AD. On self-deployed DataHub Core, the operator must configure the frontend server, including the OIDC settings, whereas DataHub Cloud enables OIDC SSO through its interface. Plan for the redirect URLs, client secret storage, group-to-role mapping and certificate handling, and test sign-in, sign-out and session expiry before users are moved. The DataHub OIDC SSO guide describes the configuration steps.
When keeping Alation is the sounder choice
Keeping Alation is the sounder choice when its cloud service is already embedded in how your stewards and analysts work, and when your organization does not want to own a Kubernetes data platform. Alation Cloud Service runs on Alation's servers and Alation administers and upgrades it, which removes the server, database and search tuning work that a DataHub deployment would put on your team. If your data stewards rely on the Alation Agent, the Microsoft Teams or Slack integrations, the Chrome Extension or OAuth 2.0 API authentication, those capabilities exist only in the cloud service according to Alation's documentation, and replacing them is a real project rather than a configuration change. The Alation documentation on cloud and customer-managed deployment is the place to confirm which of these features your plan includes today.
A fair test is a short pilot that measures the workflow you would actually lose, not a feature checklist. Pick two or three representative domains, have stewards curate them in Alation, and log every task that depends on a cloud-only feature, every support ticket and every upgrade event over the pilot window. On the DataHub side, deploy DataHub Core in a non-production cluster following the Kubernetes guide, then time how long your team needs to stand up GMS, the consumers, Kafka, the database and search, and to configure OIDC sign-in on the frontend. Ask Alation for the written SLA, support tiers and Enterprise+ features that apply to your contract, and ask the same of DataHub Cloud if you are weighing it as a middle option. Collect the evidence in one place: task logs, time records, the cluster resource footprint and the list of features you cannot replicate.
Decide to stay with Alation if the pilot shows that cloud-only features carry daily stewardship work, that your platform team has no capacity to run and patch the DataHub stack, or that your contract terms give you a service commitment you would otherwise have to build yourself. Decide against staying if the pilot shows that most of your use is search, lineage and glossary, which DataHub covers. Record the decision with its assumptions, and set a review date tied to your next renewal so the choice is revisited with current pricing and feature lists.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including DataHub Core on your Kubernetes cluster. For Alation vs DataHub, we start with a written scope that tests which Alation capabilities your teams actually depend on before any build begins.
How we scope
- Inventory the Alation features your teams use, including any that exist only in Alation Cloud Service or customer-managed Alation
- Map each source system to a DataHub ingestion path and flag connectors that need custom work
- Agree in writing the search, lineage, glossary, stewardship and SSO requirements that define done
- Confirm which AI documentation and observability features your organization needs, since DataHub keeps some of them in its managed cloud
How we build
- Deploy DataHub Core on your Kubernetes with its Helm charts, with Kafka, the database, search and graph index dependencies configured in your environment
- Configure OIDC sign-in on the frontend, since self-deployed DataHub Core requires the operator to set this up
- Load the business glossary and ownership data from version-controlled YAML so changes are reviewed and traceable
- Test search relevance, lineage accuracy and ingestion schedules against a representative set of your Alation sources
How we hand over
- Document the architecture, network paths, secrets handling and the ingestion and glossary change process for your team
- Provide runbooks for the system-update job that runs during upgrades, including reindexing steps and rollback criteria
- Deliver a feature gap register that records which Alation capabilities are not replaced and how your users will work around them
- Train your data stewards and platform engineers on daily operation and on managing the catalog as code
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Track new DataHub releases against your environment and plan upgrades with a tested change window
- Review access controls, SSO configuration and dependency health on a schedule agreed in the retainer
- Provide compliance readiness evidence for your own assessors, while audit reports and certifications come from independent bodies
