Migrate from Alation to DataHub

Migrate from Alation to DataHub: what the move involves

The move from Alation to self-hosted DataHub is a rebuild of ingestion and search plus a token-based transfer of curated content. DataHub does not import an Alation catalog as a whole, so connectors, lineage and the search index are set up again in DataHub's own stack, while descriptions, glossary terms and ownership are extracted from Alation's REST APIs and loaded into DataHub. If your renewal, deployment model, residency requirement or lock-in concern is the trigger, plan the work as two tracks that run in parallel: source ingestion and metadata transfer. The work is usually run by a platform team that owns the Kubernetes cluster, Kafka, the database and Elasticsearch or OpenSearch, a data team that knows the sources and their connectors, and a governance team that decides which Alation content is worth carrying over. Many organizations bring in an implementation partner for the Helm deployment, SSO and content extraction. DataHub's open-source edition is licensed under the Apache License 2.0, so the software itself carries no license fee, but the infrastructure, operating staff and any support contract are recurring costs you must price yourself. Ask any vendor or partner to quote these as separate components, and confirm the exact license terms with the project's repository before you commit.

Effort and risk are concentrated in three places. First, the connector inventory: every source Alation reads must have a DataHub ingestion recipe, and some Alation-specific metadata, such as custom fields and curation workflows, will need a deliberate mapping rather than a direct copy. Second, the operating model: DataHub's Kubernetes guide describes several components and dependencies, and its Helm chart runs a system-update job on upgrades, so an upgrade plan and a test environment are not optional. Third, user adoption: search results will differ from Alation, and stewards need time to re-curate what did not transfer cleanly. Confirm with your own environment how long a parallel run should last, and agree the cutover criteria in writing before the Alation subscription is allowed to lapse.

Which Alation capabilities map to DataHub, and which need rework

This table maps each main Alation capability to its closest DataHub Core equivalent and labels it as a clean match, work that needs rework, or a gap. Alation features marked as cloud-only need confirmation against your Alation edition before you plan the cutover, and DataHub Cloud features sit outside the open-source scope.

Alation capability	DataHub Core equivalent	Status
Discovery and search across tables, columns and dashboards	Search and discovery over ingested entities, indexed in Elasticsearch or OpenSearch, fed by 150+ connectors	Clean match. Confirm each Alation source has a DataHub connector and validate search relevance with your own users
Column-level and table lineage	Column-level lineage from supported connectors and ingestion	Needs rework. Lineage often depends on query logs or dbt, so verify coverage for your warehouses and BI tools
Business glossary and term linking	Business glossary with terms, term groups and YAML import	Needs rework. Map Alation term relationships and stewards to DataHub glossary structure before import
Ownership and stewardship roles	Ownership assigned to datasets and entities, with owner types set by the operator	Needs rework. Alation steward roles do not transfer one to one, so agree a role model first
Curated descriptions, certifications and trust flags	Descriptions and tags can be written through the APIs, but no direct equivalent to Alation's certification workflow	Needs rework. Export curated text through Alation's REST APIs and decide how to represent trust status
Custom fields and catalog templates	Custom properties and structured properties on entities	Needs rework. Confirm the property types you need and rebuild any Alation template logic
Single sign-on	OpenID Connect sign-in, configured by the operator on DataHub Core	Clean match for OIDC providers. SAML and other protocols need confirmation
Deployment model	Self-hosted on Kubernetes with Helm charts, or Docker quickstart for evaluation	Clean match for self-hosting. Plan for Kafka, the database and search components your operations team must run
Alation Agent, Teams and Slack integrations, Chrome Extension	No equivalent in DataHub Core	Gap. These are listed as Alation Cloud Service features, so confirm their use before migration
OAuth 2.0 API authentication and AWS PrivateLink (Enterprise+)	Token-based API access and private networking are handled by your own infrastructure	Gap or confirm. PrivateLink is a cloud-only Alation feature, and DataHub Core does not provide it
Compliance forms, access request workflows, data quality monitoring, AI anomaly detection, 99.5% uptime SLA	Available in DataHub Cloud only	Outside open source. Plan these as separate decisions and do not assume they exist in DataHub Core

Which data and integrations to move, and how

Moving from Alation to DataHub is three separate jobs: technical metadata that DataHub re-ingests from source systems, curated knowledge that you extract from Alation and map by hand, and the integrations and lineage that must be rebuilt rather than copied. Each path has its own owner, its own validation step and its own version risk, so plan them as distinct workstreams.

Re-ingest technical metadata

Technical metadata such as schemas, tables, columns and usage should come from DataHub's own connectors, not from an Alation export. DataHub lists more than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau. Confirm connector coverage for each source in your inventory, and run ingestion in a staging instance first so you can compare asset counts against what Alation shows for the same sources.

Extract curated descriptions and ownership

Descriptions, tags, owners and stewards that people wrote in Alation are not discovered by connectors. Pull them through Alation's token-authenticated REST APIs for data sources, schemas, tables, columns and custom fields, then map each field to a DataHub aspect such as descriptions, ownership or tags. Keep a field-level mapping sheet, because custom fields rarely line up one to one.

Move the business glossary

Alation glossary terms, their definitions, synonyms and links to assets need a clear mapping before import. DataHub supports glossary import from YAML, so transform the Alation output into that structure and load it into a staging environment. Check term hierarchies, term owners and how each term links to columns, because broken links are the most common silent loss in this step.

Rebuild lineage and integrations

Lineage is not a file you can carry across. Column-level lineage in DataHub comes from ingestion of the source systems, dbt and BI tools, so it must be rebuilt and then compared with the lineage Alation shows for your most-used reports. Alation Cloud Service features such as the Chrome Extension, Slack and Microsoft Teams integrations, and the Alation Agent have no direct DataHub equivalent, so rebuild only the integrations your users depend on.

Confirm the Alation version and API outputs

The shape of Alation's REST API responses depends on the Alation release and on whether you run the cloud service or customer-managed Alation. Before writing any mapping, confirm the endpoints, field names and pagination for your version, and confirm which OAuth or token method applies to your deployment. Record the version in the migration runbook so the mapping can be reproduced during validation.

Check DataHub version and access controls

Pin the DataHub release you deploy and confirm it against the project's release notes before you load production metadata. The Helm chart runs a system-update job on upgrades, so schedule that job in your change window. Also confirm that DataHub Core OIDC sign-in is configured by your operator, and that access and ownership rules match the permissions Alation users had.

Migration sequence from inventory to decommission

This sequence moves the Alation catalog into a self-hosted DataHub deployment in five gated stages, so that every source, curated asset and access path is accounted for before Alation is switched off. Each step ends with a named output and a check that the next step depends on.

Inventory sources, custom fields and curation
The catalog owner and an Alation administrator list every data source connected to Alation, its schemas, tables and columns that carry curated content, and each custom field, template and glossary term in use. Use the REST APIs described in Alation's documentation to export this metadata, and record which items have human-written descriptions, owners, tags or certifications, since these are the content you must carry over. The output is a signed inventory with a count of curated objects per source and a list of Alation features your teams rely on. The step is done when a second person can reproduce the counts from the export files and every feature in use has a named DataHub equivalent or a documented gap.
Pilot DataHub on Docker or Kubernetes
The platform team starts DataHub Core in a non-production environment, first with the Docker quickstart for a fast functional check and then with the Helm charts on Kubernetes that match the target production layout. Confirm the prerequisites in the DataHub documentation, including Kafka, the relational database, Elasticsearch or OpenSearch and the graph index, and plan memory for the components before you size nodes. Connect two or three representative sources, such as your warehouse and BI tool, and configure OIDC sign-in against your identity provider. The output is a working pilot with ingestion schedules and an SSO test. The step is done when search returns expected results for sample tables, lineage appears for at least one pipeline, and an upgrade test through the Helm chart completes.
Run Alation and DataHub in parallel
Keep Alation as the system of record while DataHub ingests the same sources on a schedule. Import the glossary and ownership data into DataHub using the transformation scripts your team builds from the inventory export, and reconcile a sample of assets in both tools by hand. Stewards continue to edit in Alation during this period, and a named owner tracks every change that must be re-applied. The output is a reconciliation report listing mismatched descriptions, missing owners and unmapped custom fields. The step is done when the agreed sample of assets matches on name, owner and description, and the unresolved differences have a remediation owner.
Cut over search, SSO and ownership
Point consumers to DataHub: update bookmarks, embedded links in BI tools and internal documentation, and any browser or chat integrations your teams use with Alation. Move stewardship responsibilities into DataHub, freeze edits in Alation for the cutover window, and run a final delta import of descriptions and ownership. Confirm that users can sign in through the same identity provider and that access groups match what they had in Alation. The output is a cutover runbook with a rollback path back to Alation. The step is done when a pilot group of stewards and analysts completes their routine searches in DataHub, the final delta reconciles, and the rollback has been rehearsed.
Decommission Alation and archive exports
Once the cutover has run without open defects for the period your governance team sets, stop ingestion into Alation and disable user access. Retain the final JSON and CSV exports, the inventory, the reconciliation reports and the runbook in an archive controlled by your records policy, since auditors and internal reviewers may ask how curated metadata was preserved. Confirm the retention period with your compliance and legal teams and check your Alation contract for the end-of-service and data return terms before you cancel. The output is a decommission record and an archive index. The step is done when Alation access is removed, the archive can be restored and read without Alation, and the record is signed by the data owner.

How DataHub's components change the operating model

Running DataHub on Kubernetes means your platform team operates a metadata service and its supporting stack, not a single application. The Kubernetes guide lists four main components: GMS (the metadata service), the MAE Consumer, the MCE Consumer and the Frontend. GMS and the consumers depend on Kafka to stream metadata changes, a MySQL, PostgreSQL or MariaDB database for storage, Elasticsearch for search, and a graph index on Neo4j or Elasticsearch. Each of these is a stateful service you must size, back up, patch and monitor. Before the cutover, confirm with your platform team who owns Kafka and the relational database, which backup method covers the metadata store, and whether your search and graph backends are supported in the chart version you plan to use.

DataHub's Helm deployment is split in two. The datahub-helm chart deploys the application, while a separate prerequisites chart from the acryldata repository deploys the dependencies. Treat the prerequisites chart as an environment decision: if your organization already runs managed or shared Kafka, PostgreSQL or Elasticsearch, you may point DataHub at those instead, but you then own the version compatibility and the tuning. On upgrades, the chart runs a system-update job that applies schema changes and reindexes search indices when needed. Plan upgrade windows around that job, test it in a non-production cluster first, and record the reindex duration you observe, since the sources do not give a figure for it.

Authentication is an operator task on DataHub Core. The OIDC SSO guide shows that the frontend server must be configured by you, with an OpenID Connect provider such as Okta, Azure AD or Google, and the client settings must match your identity provider. DataHub Cloud enables OIDC through its interface, so this work does not transfer to the managed product. Assign an owner for the OIDC configuration, the client secret rotation and the role mapping before users are onboarded from Alation. The sources give 8 GB of RAM as the stated minimum for the Docker quickstart and more than 7 GB for Minikube. Those figures are starting points for evaluation only; size a production cluster from load tests against your own catalog volume.

What drives cost and duration in this migration

This table breaks the Alation to DataHub move into its cost components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up. Read it as a checklist for a quote: the largest recurring items are the Kubernetes footprint and the staff who run DataHub, while the largest one-time items are connector setup and content mapping. No prices or durations are stated because none were supplied for this comparison.

Cost component	Who is paid and for what	One-time or recurring	What raises it and how to contain it
Platform infrastructure and Kubernetes	Your cloud or data center team, plus any infrastructure partner, for nodes, storage and networking	Recurring	DataHub needs Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch and a graph index. Right-size each dependency and ask the partner to price a managed or self-run option for each one.
Local evaluation footprint	Engineers evaluating on a laptop or test cluster	One-time	The Kubernetes guide says more than 7 GB of RAM is needed on Minikube. Run the evaluation on a shared test cluster to avoid buying spare capacity.
Connector configuration	Platform engineers writing DataHub ingestion recipes for each source, such as Snowflake, BigQuery, Databricks, dbt, Looker and Tableau	One-time to set up, recurring to maintain	Each source adds a recipe, credentials and a schedule. Count your sources before estimating, and reuse one pattern for each source type.
Content extraction and mapping	Staff or partner time to pull descriptions, glossary terms, ownership and custom fields from Alation REST APIs and map them into DataHub	One-time	Field mismatches and custom fields drive most of the effort. Export a sample first, agree the mapping in writing, and decide which Alation content is worth carrying over.
Parallel running	Alation subscription or customer-managed Alation licences, plus staff time to keep two catalogs aligned	Recurring until cutover	Length of the overlap drives the spend. Set a cutover date and a rollback point in the scope before work starts.
SSO setup	Identity team and implementer for the OpenID Connect configuration on self-deployed DataHub Core, where the frontend is configured by the operator	One-time	The OIDC guide must be followed for each identity provider, such as Okta or Azure AD. Confirm the provider and group mapping early, since DataHub Cloud handles this through its interface.
Upgrades	Platform team for each Helm upgrade, including the system-update job that applies schema changes and reindexes search	Recurring	Upgrade frequency and the number of environments drive effort. Test each release in a non-production environment and schedule reindex windows.
Staff time to operate	Internal platform, data and security staff, or a retained support partner	Recurring	Monitoring, backups, access reviews and user support grow with the number of connected sources and users. Agree a support model and named owners in the written scope.
Alation features without a DataHub equivalent	Business owners who rebuild workflows, such as Alation-only integrations, in other tools or accept the gap	One-time or recurring	Inventory cloud-only features and the workflows that depend on them before quoting. Each gap needs an owner and a decision, which keeps scope from growing during the move.

What usually goes wrong and how to prevent it

Most failed Alation to DataHub moves lose knowledge rather than metadata. The risks below cluster around what Alation holds outside plain table and column records, how the two catalogs drift during a parallel run, and the platform decisions that are easy to get wrong on a self-hosted DataHub Core deployment.

Curated content lost in export

Descriptions often sit in Alation custom fields, article bodies or pages that are not linked to any object, so a standard metadata pull misses them. Before cutover, inventory every custom field and article type in use, then decide for each whether it maps to a DataHub property, a glossary term, a document or a documented archive. Confirm the export with a sample of curated tables reviewed by their stewards. Unlinked articles are the most common silent loss.

Glossary and ownership drift

During a parallel run, stewards keep editing Alation while the DataHub copy stays at the last load. Terms renamed, owners reassigned or descriptions corrected in one catalog then disagree with the other within days. Freeze glossary and ownership edits for a named window, or assign one system of record per field and reconcile on a fixed schedule with a diff report that stewards sign off.

Search relevance changes after reindexing

DataHub builds its own search index from ingested metadata, so ranking will not match Alation's usage-driven results on day one. Popular tables may sit lower, and synonyms or glossary aliases may be missing. Run a fixed set of real search queries from analysts against both catalogs, record the top results, and tune boosts and glossary terms before users are moved. Expect the search index to be rebuilt by the system-update job when upgrades change schemas.

Under-sized Kubernetes clusters

DataHub runs GMS, the MAE and MCE consumers and the frontend alongside Kafka, a relational database, Elasticsearch or OpenSearch and a graph index. The Kubernetes guide states more than 7 GB of RAM is needed just to run DataHub and its dependencies on Minikube, which is a floor for testing, not production sizing. Size production from the connector volume and retention you plan, load a full copy of the Alation metadata in staging first, and confirm limits with the DataHub maintainers or your platform team.

SSO misconfiguration on DataHub Core

DataHub Core supports OpenID Connect sign-in, but the operator must configure the frontend server, and DataHub Cloud handles this through its interface instead. Errors in redirect URIs, client secrets, group claims or role mapping can lock out stewards or expose the catalog to users who should not see it. Test sign-in with a steward, an analyst and a deprovisioned account, and confirm that removing a user at the identity provider removes access.

Assuming cloud-only Alation features have equivalents

Alation documents features available only in Alation Cloud Service, including the Alation Agent, the Microsoft Teams and Slack integrations, the Chrome Extension, OAuth 2.0 API authentication and AWS PrivateLink on Enterprise+ plans. DataHub Core does not replicate these as built-in features, and some capabilities, such as access request workflows and compliance forms, are part of DataHub Cloud. Build a feature inventory from your actual Alation usage, mark each item as replaced, rebuilt, retired or kept in Alation, and get stakeholder sign-off before cutover.

How the migration differs by starting point

Alation Cloud Service runs on Alation's servers and Alation administers and upgrades it, so your team does not control the instance, its database or its upgrade window. Your migration is mostly an extraction and rebuild exercise, and the first question is which features your team uses that exist only in the cloud service. Alation's documentation lists the Alation Agent, the Microsoft Teams and Slack integrations, the Chrome Extension, OAuth 2.0 API authentication and AWS PrivateLink on Enterprise+ plans. Each of these may have to be replaced or dropped in DataHub.

Feature inventory: List every cloud-only capability in use, and who depends on it, before scoping the work.
API access: Confirm which token type your tenant issues and whether your API credentials can read every source and custom field you need.
Connectivity: If PrivateLink or network allowlisting protects your sources, plan how DataHub ingestion reaches them from your own network.
Cutover timing: Agree with Alation's account team how long the tenant stays readable during parallel running, since you do not control that window.
Contract exit: Confirm notice periods, data return terms and the export format in writing with your Alation contract owner.

Before you start, confirm with Alation which export paths and retention rules apply to your tenant.

Questions buyers ask before moving from Alation to DataHub

What does a migration from Alation to DataHub cost?

The cost is mostly labor and infrastructure, not licensing, because DataHub Core is Apache-2.0 licensed and carries no license fee. The main components are the Kubernetes capacity and dependencies DataHub needs, connector setup for each source, content migration from Alation's REST APIs, testing of the rebuilt search and access model, and ongoing upgrades and operations. The Kubernetes guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, while the Docker quickstart requires 8 GB of RAM, so sizing for production is a separate exercise. Ask any implementation partner for a fixed-scope quote that lists each component, what is one-time and what recurs, and which Alation features are excluded from scope.

How long does an Alation to DataHub migration take?

The timeline depends on the number of sources, how much curated content must move, how many glossary terms and ownership assignments exist, and how many Alation features your teams depend on. Connector work is usually the first driver, because each source needs DataHub ingestion configured and validated before users can rely on it. Content migration, cutover planning and user training follow. No duration is fixed in this page; confirm the schedule against a written scope and ask for a phased plan that separates connector rebuild from content transfer.

What does our team need to provide during the migration?

You need named owners for each data domain, access to the Alation instance and its API tokens, read access to every source system the connectors will reach, and a decision on which curated descriptions, glossary terms and ownership records are worth keeping. You also need a Kubernetes environment, database and search capacity, and an identity provider for sign-in. DataHub's OIDC guide says that on self-deployed DataHub Core the frontend server must be configured by the operator, so someone must own that configuration. Plan time from data stewards, because they must validate migrated content.

Can an internal team migrate from Alation to DataHub alone?

An internal team with Kubernetes, data platform and integration experience can complete the work, provided it has the time and the skills to operate Kafka, the metadata service, search and graph dependencies. The risks are usually not the installation itself but the ongoing operation: upgrades, the system-update job that applies schema changes and reindexes search when needed, and connector maintenance. Be honest about capacity before committing. If the team wants outside help, DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope and agreed in writing before work starts.

Can we replace Alation features that only exist in the cloud service?

Some can be replaced and some cannot. Alation's documentation lists the Alation Agent, Microsoft Teams and Slack integrations, the Chrome Extension, OAuth 2.0 API authentication and AWS PrivateLink connectivity on Enterprise+ plans as cloud-only. DataHub Core covers search, lineage, glossary and ownership, and its integrations can be reached through its own APIs, but it does not provide Alation's chat and browser integrations. Build a feature inventory with your users, mark each cloud-only feature as replaceable, partially replaceable or lost, and decide what to do with the lost items before cutover. Confirm current DataHub Core capabilities against its documentation.

Do we need DataHub Cloud to run DataHub in production?

No. DataHub Core is open source under Apache-2.0 and can run on your own Kubernetes using the Helm charts. DataHub Cloud is a separate managed product that adds 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, according to DataHub's comparison documentation. Choose DataHub Cloud only if one of those features or a vendor-backed SLA is a requirement. If you need a 99.5% uptime commitment, weigh it against your own operating model, since a self-hosted deployment carries that obligation internally.

Does DataHub meet our compliance and security requirements?

DataHub supplies a platform and configuration options, but it does not certify your environment. Its governance features, including glossary, ownership and classification-related metadata, help you document controls, and its OIDC support lets you centralize sign-in. Compliance assessments are performed by independent auditors and certification bodies, and DeployOpen prepares systems, controls and evidence for them without issuing audit reports or certifications. Ask your assessor which evidence they need, such as access logs, backup records and change history, and confirm each requirement against your own environment.

How DeployOpen scopes and runs the Alation to DataHub migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. For an Alation to DataHub move, that means the DataHub deployment, its Kafka, database and search dependencies, the connector estate, and the export and import work that carries curated content across. Most engagements are fixed-scope, so the written scope should name which Alation sources, glossary terms, ownership records and custom fields are in the move, which DataHub components are deployed, and which Alation features are retired or replaced. Ask for the scope to list the Alation features that have no DataHub equivalent as explicit decisions, so nothing is lost by default.

Deliverables and timelines are agreed in writing before work starts, and DeployOpen does not publish a price list. A quote follows from that written scope, so the inputs that move the number are the count of connected sources, the volume of curated descriptions and glossary terms to migrate, the number of Alation users whose access must be re-established through single sign-on, and whether the target is a single environment or separate test and production clusters. Ask the vendor to separate one-time work (deployment, connector build, content migration, cutover and documentation) from recurring work, and to state what is included in the handover. DeployOpen does not issue audit reports, attestations or certifications, so any compliance evidence it prepares should be presented to your independent auditor as operational records, not as a certification.

Ongoing support, upgrades and continuous testing are available as retainers, which matters because DataHub upgrades run schema changes and search reindexing through its Helm chart. Before signing, confirm with DeployOpen who performs the Alation side of the cutover, who owns the DataHub Kubernetes cluster after handover, and how a retainer would cover the upgrade cycle for the DataHub release you deploy. Your own team should also confirm who in your organization approves glossary and ownership content, because that decision drives much of the migration effort.

Migrate from Alation to DataHub