Migrate from Atlan to DataHub

Migrate from Atlan to DataHub: what the move involves

Moving off Atlan's single-tenant SaaS is mostly a question of what curated metadata you have built up and who will own it afterward. The curated layer (glossary terms, domains, ownership, tags and descriptions) is what you export and reload into DataHub. Connectors, lineage and profiling are not carried over as data. DataHub rebuilds them by re-ingesting each source, so you should plan for that rebuild as ingestion work rather than as a data transfer. The work is usually shared between a data governance lead, who decides which glossary terms, owners and domains are worth keeping, and a platform engineer, who stands up DataHub and writes the ingestion recipes. Atlan's Self-Deployed Runtime, which runs connectors inside your network, has no one-to-one replacement. In DataHub, ingestion is driven by recipes that the operator schedules and runs against each source, so someone must own those jobs, their credentials and their failure alerts. Confirm early whether your team already runs scheduled ingestion for other tools, because that skill set is what this part of the move depends on.

The effort depends mainly on how much curated metadata exists and how well it is maintained. A catalog with a small, current glossary and owners on most key tables is a much smaller export than one with thousands of unowned assets and inconsistent tags. Before scoping, ask your Atlan administrators or pull a sample with pyatlan to measure glossary size, the share of assets with owners and descriptions, and the number of custom attributes. Those counts, together with the number of connected sources, are the inputs a fixed-scope quote needs. Before cutting over teams, decide how SSO will work. DataHub supports OpenID Connect providers, but on self-deployed DataHub Core the frontend must be configured by your operator, following the DataHub OIDC SSO guide. Atlan's own identity setup uses Keycloak, so your existing identity provider's client registrations and group mappings need to be reviewed rather than copied. Plan a parallel run where both catalogs are read-only for a defined period, and agree in writing who signs off that lineage and ownership match what teams expect.

Which Atlan capabilities map to DataHub and where the gaps are

This table maps Atlan's catalog, glossary, domains, lineage, tags, SSO and deployment model to their DataHub equivalents. Each row is marked clean, needs rework or gap, so you can size the migration before scheduling it. Confirm any feature not covered by the supplied sources against the current DataHub documentation and your own pilot.

Atlan capability	DataHub equivalent	Status	What to confirm
Catalog and asset discovery	DataHub search and entity catalog, fed by 150+ source integrations	Clean	Confirm connector coverage for each of your sources against the current integration list
Business glossary	Business glossary defined in DataHub's YAML format and loaded through ingestion	Needs rework	Terms, categories and term-to-asset links must be rewritten from Atlan export files
Domains	DataHub domains assigned to datasets and entities	Needs rework	Rebuild the domain hierarchy and reassign ownership rules, since the structures differ
Column-level lineage	Column-level lineage from supported connectors and SQL parsing	Needs rework	Lineage is rebuilt by re-ingestion, not copied from Atlan; validate it on critical pipelines
Tags and classifications	DataHub tags and glossary terms applied to entities	Needs rework	Map Atlan tag names to DataHub tags and confirm how propagation behaves in your setup
Custom metadata	Custom properties or structured properties, depending on the DataHub version	Gap	Confirm the approach with the DataHub release you deploy, since custom attributes often need a modeling decision
SSO	OIDC through an identity provider such as Okta, Azure AD or Google	Needs rework	On DataHub Core the frontend must be configured by your operator; Atlan uses Keycloak for OIDC and SAML
Access request workflows	DataHub Cloud feature, not in the open-source edition	Gap	Plan a separate approval process or tool if you rely on Atlan access requests
Compliance forms	DataHub Cloud feature, not in the open-source edition	Gap	Document compliance evidence through your own forms or workflow tools
Deployment model	Self-hosted on your Kubernetes with Helm charts, GMS, consumers, frontend, Kafka, a SQL database and Elasticsearch	Needs rework	Atlan runs as SaaS with only a Self-Deployed Runtime on site; DataHub runs entirely in your environment and you operate it

What to export from Atlan with pyatlan and what to rebuild

Not all Atlan metadata deserves the same treatment. Curated business context such as glossaries, descriptions, owners and tags is worth extracting, while connector-generated technical metadata is better rebuilt by DataHub's own ingestion. Confirm the pyatlan version and API coverage for your tenant before you plan the extract.

Glossary terms and hierarchy

Glossaries are the business vocabulary your teams have agreed on, so they are the first thing to extract with pyatlan. Export terms, their definitions, categories and parent relationships, then map them to DataHub's business glossary, which is defined in YAML. Check that term names stay unique after export, and record any term that Atlan links to assets so you can reattach it in DataHub.

Descriptions and certified context

Asset descriptions and certification notes written by data owners are hard to recreate and worth carrying over. Extract them per asset with pyatlan, keyed by qualified name so they match the assets DataHub ingests later. Expect some assets to change identifier during re-ingestion, so run a reconciliation report that lists descriptions with no matching target before you cut over.

Owners and stewardship

Ownership records show who answers for each dataset, and they are a common gap in migrations. Pull owner assignments from Atlan and map them to DataHub users and groups, which must already exist in your identity provider. Ask a steward from each domain to review the mapped list, since former employees and shared mailboxes often appear in exported owner fields.

Tags and classifications

Tags and classifications drive access reviews and policy decisions, so their meaning must survive the move. Export tag names, definitions and the assets they attach to, then confirm that each tag still exists as a DataHub tag or glossary term. Check whether any tag was applied by a rule in Atlan, since rules do not carry over as data and must be rebuilt.

Connector metadata to rebuild

Schemas, lineage, usage statistics and profiles come from the source systems, so DataHub ingestion should regenerate them rather than copy Atlan's copies. Plan a DataHub connector for each source you run today, including Snowflake, dbt and Looker, which DataHub lists among its more than 150 integrations. Confirm each connector's coverage for the features you rely on, such as column-level lineage.

Runtime, SSO and access to rebuild

Self-Deployed Runtime connectors, which run in your network to reach private sources, must be replaced by ingestion that DataHub can reach. Atlan uses Keycloak for SSO, OIDC and SAML, so DataHub's OIDC configuration and group mapping must be built again on the frontend, and the Kubernetes deployment must reach your sources directly. Document each credential and network path before cutover.

Migration sequence from inventory to decommissioning Atlan

This sequence moves curated Atlan metadata into a self-hosted DataHub deployment in controlled stages. Each step produces a written artifact, so the team can confirm what moved, what was rebuilt and what was deliberately left behind before any user is switched over.

Inventory sources and curated metadata
List every connector feeding Atlan, every data domain, glossary term, owner and tag that analysts rely on, and every custom attribute your teams have added. Separate curated metadata that must be carried over from metadata that a DataHub ingestion run will regenerate on its own, such as table schemas and lineage. Owners of each data domain confirm their list. The output is a source inventory and a curated-metadata register that names what is exported and who approved each item.
Stand up a DataHub pilot
Run DataHub in a non-production environment to test your connectors and access model before committing to a design. Use the Docker quickstart on a workstation for evaluation, which needs Docker with 8 GB of RAM and Python 3.10 or later, or deploy the Helm charts from the acryldata/datahub-helm repository with the separate prerequisites chart on Kubernetes for a closer match to production. Confirm the Kubernetes sizing in the DataHub guide for your cluster. The output is a running pilot instance and a short note recording which sources ingested cleanly and which needed configuration changes.
Map Atlan domains and glossary to DataHub
Build a mapping file that links each Atlan domain, glossary term and tag to its DataHub counterpart, including domains, glossary terms and the YAML business glossary format that DataHub loads. Decide where Atlan concepts have no direct match and record the decision, for example by keeping a tag as a tag rather than forcing it into a term. Data stewards sign off on the mapping. The output is a versioned mapping file and a reconciled glossary in YAML that the team can load into the pilot and review line by line.
Re-ingest sources and load curated metadata
Configure DataHub connectors for each source in the inventory, then load the approved glossary, domains, ownership and tags from the mapping file. Run ingestion against the pilot first and compare entity counts and sample assets against Atlan for the same sources. Record gaps, such as a source type without a DataHub connector or a custom attribute that did not carry across. The output is a reconciliation report listing each source, its entity counts in both catalogs and every known difference.
Run Atlan and DataHub in parallel
Keep Atlan as the system of record while DataHub ingests the same sources on a schedule and stewards check their domains against Atlan. Compare search results, lineage views and glossary terms for a representative set of assets, and log every mismatch with an owner. The Self-Deployed Runtime stays in place during this period for sources that need it. The output is a parallel-run log with each discrepancy resolved, accepted or scheduled for correction before cutover.
Configure SSO and cut over teams
Configure OpenID Connect single sign-on for DataHub using the OIDC guide, since self-deployed DataHub Core requires the operator to configure the frontend server, and test it with your identity provider. Move teams in groups, starting with the data stewards, and update links in documentation, bookmarks and any integrations that pointed to Atlan. Confirm that group-based access matches the access model in Atlan. The output is a signed-off cutover checklist covering SSO tests, access mapping, communication and a named owner for each group.
Decommission Atlan and retain records
After the final teams move and the cutover checklist is complete, export a final archive of Atlan metadata and retain it under your records policy. Revoke Atlan user access, disable connectors and the Self-Deployed Runtime, and confirm with Atlan how your contract ends and what data they retain. Keep the mapping file, reconciliation report and parallel-run log with the archive so auditors can trace how metadata was moved. The output is a decommissioning record and a closed contract checklist.

How the migration changes by starting point

Teams that run the Self-Deployed Runtime for on-premises databases, mainframes or VPC-locked sources carry the most connector work. Those connectors do not move as configuration. In DataHub, each source is ingested by a recipe that runs in your network, so the rebuild starts with an inventory of every Runtime-backed source, its credentials, its network path and its schedule. Plan the DataHub ingestion runners on the same network segment as those sources before anything else.

Export scope: Pull only curated metadata with pyatlan, but keep a list of which assets came from Runtime connectors so you can match them to new recipes.
Connector rebuild: Stand up DataHub ingestion for each Runtime source and compare asset counts and schemas against Atlan before retiring the Runtime.
Network and credentials: Confirm that the new ingestion hosts can reach the sources under the same firewall rules and that service accounts are issued and rotated under your own policy.
Cutover order: Move the on-premises sources first, while Atlan remains the reference for comparison, and decommission the Runtime last.
Audit trail: Record each source's ingestion run history during parallel operation so reviewers can see the new pipeline matches the old one.

Before you start, confirm with your team how many sources depend on the Runtime and whether any of them cannot be reached from a Kubernetes cluster you control.

What drives the cost and duration of this migration

This table lists the factors that change the cost and effort of moving from Atlan to self-hosted DataHub, who is paid for each piece of work, and what recurs after cutover. Read each row as a question to answer in your own environment before asking for a quote. The main takeaway is that source count, curated metadata volume and the size of the DataHub platform you operate usually matter more than the export step itself.

Driver	Why it changes cost or effort	What to ask for or confirm
Number of sources and connectors	Each Atlan source served by a Self-Deployed Runtime must be re-ingested with a DataHub connector, and connectors that need VPC or on-premises network paths add access work.	List every source, its DataHub connector, and which sources need network changes or new service credentials.
Volume of curated glossary and ownership	Terms, domains, owners and tags are exported with pyatlan and mapped to DataHub domains and its YAML business glossary, so a large, inconsistent glossary means more review before import.	Ask how mapping is verified, who approves term ownership, and how many terms are retired or merged.
Custom metadata	Custom attributes in Atlan have no direct equivalent and may need custom properties, structured properties or a decision to drop them.	Ask which custom metadata fields are used in reports, policies or access rules, and how each is mapped.
Lineage depth	Lineage rebuilt from connectors is usually cheaper than migrating it by hand, but manual lineage or lineage from custom pipelines must be recreated and checked.	Ask which lineage paths are automated and which need manual edges, and how coverage is compared with Atlan.
SSO complexity	DataHub's OIDC configuration on self-deployed Core is set by the operator in the frontend server, and group mapping, role assignment and cutover for each identity provider add work.	Confirm the identity provider, group mapping rules and whether the cutover needs a parallel login period.
Team count and cutover waves	Each team's bookmarks, access, notifications and habits move separately, so more teams mean more training and more support during cutover.	Ask for the cutover plan by team, the rollback path and who owns user communication.
Kubernetes, Kafka, database and search footprint	DataHub needs GMS, the MAE and MCE consumers, the Frontend, Kafka, MySQL, PostgreSQL or MariaDB, Elasticsearch and a graph index. The Kubernetes guide says more than 7 GB of RAM is needed for Minikube, and the Docker quickstart requires 8 GB of RAM, so production sizing is a separate exercise.	Ask for a sizing estimate by component, the managed or self-run choice for each dependency, and the node pool cost paid to your cloud provider.
Upgrades and recurring operations	The Helm chart's system-update job applies schema changes and reindexes search when needed, so each DataHub release needs a planned window, testing and a rollback plan.	Ask for the upgrade procedure, who runs it, and how often upgrades are scheduled after go-live.

What usually goes wrong when moving off Atlan

Most failed catalog migrations do not fail on the first load. They fail later, when lineage, glossary links, owners or logins quietly differ from what teams relied on in Atlan. Each card below names one risk in a move from Atlan to DataHub and the check that catches it before users notice.

Lineage that does not rebuild cleanly

Connectors rebuild table and column lineage from source metadata, but lineage that Atlan users added by hand, or lineage from sources you did not re-ingest, will not appear on its own. Compare lineage edges for a sample of critical tables in both catalogs before retiring Atlan. Confirm which DataHub connectors produce column-level lineage for your specific sources, since coverage varies by connector.

Glossary terms losing relationships

Atlan glossary terms carry related terms, synonyms, categories and links to assets. When these are exported and rewritten into DataHub's YAML business glossary, relationships can be dropped or point to terms with changed names. Export a glossary term, import it into a test DataHub instance, and check that each relationship and asset link appears before loading the full glossary.

Ownership gaps after mapping

Owners in Atlan may be users, groups or roles that do not exist under the same identifiers in DataHub. Assets then load with no owner, or with an owner who has left the company. Build a list of every asset without an owner after the load, assign owners from your data stewardship records, and agree who approves changes to ownership before cutover.

SSO misconfiguration on DataHub Core

On self-deployed DataHub Core, the operator must configure the frontend server for OpenID Connect sign-in, including the identity provider, redirect URL and client settings. Atlan's Keycloak-based login, which many teams used with their own identity provider, does not carry over automatically. Test sign-in with a non-administrator account, confirm group claims map to DataHub roles, and check that sign-out and session expiry behave as your policy requires.

Underestimated upgrade effort

DataHub's Helm chart runs a system-update job on upgrades to apply schema changes and reindex search indices when needed. Teams that treat DataHub as a one-time install often schedule upgrades without a rehearsal, then find the job runs longer than their maintenance window. Stand up a staging cluster with a copy of production metadata, run the upgrade there first, and record how long the system-update job takes.

Cutting over before reconciliation

Teams sometimes switch users to DataHub while Atlan still holds metadata that has not been reconciled, so searches return different answers and governance decisions are made on incomplete records. Run the reconciliation checks for lineage, glossary, owners and tags on a fixed set of assets, obtain sign-off from the data owners, and only then redirect users. Keep Atlan read-only for a defined period so that any gap can be checked against the original.

Questions buyers ask before moving from Atlan to DataHub

What does a migration from Atlan to DataHub cost?

The cost comes from three groups of work: people, infrastructure and ongoing operations. Your internal engineers or a partner spend time exporting curated metadata with pyatlan, mapping Atlan domains and glossary terms to DataHub domains and its YAML business glossary, and re-ingesting sources with DataHub connectors. Infrastructure is a Kubernetes cluster that runs GMS, the MAE and MCE consumers, the frontend, Kafka, a MySQL or PostgreSQL database and Elasticsearch or OpenSearch. Some costs are one-time (migration, testing, cutover) and others recur (hosting, upgrades, on-call and support). DeployOpen does not publish prices. Ask any quote to itemize these components, and to separate the Atlan subscription savings from the operating cost you will carry.

How long does moving from Atlan to DataHub take?

The duration depends on how many sources you connect, how much glossary and ownership data you curate, how many teams must cut over, and how much of your lineage you need to rebuild. No timeline is fixed by the product. A small catalog with a few sources and a clean glossary is simpler than one with many connectors, custom metadata and SSO changes for several teams. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so ask for a phased plan that separates the export, the DataHub deployment, the re-ingestion, and the team cutover.

What do we need from our own team during the migration?

You need people who own the metadata that matters, and people who can run the platform afterward. Data owners must confirm which glossary terms, descriptions, owners and tags are still correct, because a migration will not decide that for them. Platform engineers must provide a Kubernetes environment, storage, networking, and a path for SSO. Source system owners must provide read credentials for each connector. Security and compliance staff should review how access and audit requirements map to DataHub. Ask your provider to list these inputs in the written scope so you can schedule them.

Can our team do the Atlan to DataHub migration in-house?

Yes, if you have engineers comfortable with Kubernetes, Helm, Python and identity configuration, and time to run the cutover without disrupting consumers. DataHub is Apache-2.0 licensed and its Kubernetes deployment uses Helm charts from the acryldata/datahub-helm repository plus a separate prerequisites chart. The harder parts are usually the metadata mapping decisions, the connector configuration for each source, and the cutover plan. Teams without a catalog operator often underestimate the ongoing work of upgrades and search reindexing. A written assessment of your sources and skills will show where in-house work stops being practical.

Can we export our metadata out of Atlan?

Yes, you can extract the parts of Atlan metadata that matter, but the process is SDK-based. Atlan does not publish an OpenAPI spec and points developers to its Python and Java SDKs, so the export uses pyatlan to pull glossaries, descriptions, owners and tags. Connector-derived metadata such as schemas and most lineage is typically rebuilt by DataHub's own connectors, so exporting it is usually not worth the effort. Confirm with Atlan which custom metadata and API limits apply to your tenant before you commit to a schedule, and keep an exported copy of curated content before any subscription changes.

Do we need DataHub Cloud features to replace Atlan?

Not for core cataloging. The open-source DataHub edition covers 150+ integrations, column-level lineage, a business glossary, profiling, ownership, usage and data quality assertions and monitoring, according to the project's README. DataHub Cloud 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. If your Atlan workflows depend on access requests or compliance forms, list them and compare each one against the open-source edition or DataHub Cloud before you finalize scope.

How are DataHub upgrades handled once it runs in our environment?

You schedule upgrades yourself on the self-hosted edition, and the Helm chart runs a system-update job on upgrades to apply schema changes and reindex search indices when needed. Plan for a staging environment, a backup of the database and search state, and a rollback path. DataHub's release cadence is frequent, with v1.6.0.3 released on September 25, 2026 and v1.8.0 release candidates following in October 2026, so ask any provider how they will track releases and test them before production. Upgrade support is usually a retainer item, so confirm whether it is included in your quote.

How do we cut over SSO and teams without breaking access?

Plan SSO as its own workstream. DataHub supports OpenID Connect providers such as Google, Okta and Azure AD. On self-deployed DataHub Core, the frontend server must be configured by the operator, while DataHub Cloud enables OIDC SSO through its interface. Map each Atlan role and group to DataHub roles and policies before cutover, run a pilot with one team, and keep Atlan read-only until owners confirm their content. Confirm with your identity team how group claims flow from your provider into DataHub.

How DeployOpen scopes and runs an Atlan to DataHub migration

DeployOpen plans and implements self-hosted DataHub inside your own infrastructure, then moves curated Atlan metadata, glossary and domains across under a written scope. Engagements are fixed-scope, with the deliverables, timelines and responsibilities agreed before work starts.

How we scope

Inventory the Atlan domains, glossary terms, owners, tags and connectors that the migration must carry across
Agree which sources are re-ingested with DataHub connectors and which Atlan metadata is retired instead
Confirm the target Kubernetes environment, storage, search and Kafka dependencies, and where the platform will run
Document cutover criteria for each team, including SSO and access rules, in the written scope

How we build

Extract glossary, ownership and tag metadata from Atlan using pyatlan and keep the exports as reviewable files
Map Atlan domains and glossary structure to DataHub domains and the YAML business glossary format
Deploy DataHub on your Kubernetes with its Helm charts and configure OIDC SSO on the self-deployed frontend
Test ingestion, lineage and search results against the Atlan inventory before any team is moved over

How we hand over

Deliver runbooks for deployment, upgrades, backups and the system-update job that runs during Helm upgrades
Document the mapping decisions, exports and validation results so your auditors and data owners can trace them
Train the teams that will own connectors, glossary changes and access settings after cutover
Provide a cutover plan with a rollback path, agreed with your data owners before Atlan access is withdrawn

How we support

Continue after handover with a support or upgrade retainer, scoped in writing like the original engagement
Run continuous security testing of the DataHub deployment and its connectors as a separate, agreed scope
Confirm with your team which features you need that open source lacks, such as DataHub Cloud compliance forms, before signing

Migrate from Atlan to DataHub