Migrate from Apache Atlas to OpenMetadata

The first mapping pass should cover the Hive and messaging services because Atlas records most of its structure there, and everything else attaches to that structure. In Atlas, Hive databases contain tables, tables contain columns, and Kafka topics carry names and owners. Classifications, lineage and glossary links are later applied to these objects. If the hierarchy is wrong at this stage, every later step attaches metadata to the wrong parent. Start by exporting the Atlas entities for Hive databases, tables, columns and messaging topics. For each one, record its parent service, its owner, and whether it still exists in the source system.

Naming is where most of the risk sits. OpenMetadata identifies each asset by a fully qualified name built from the service, database, schema and table names. Atlas identifies entities by its own qualifiedName convention, which can include cluster or host details that OpenMetadata does not use. These two schemes rarely line up by default. Decide the OpenMetadata service names first, then build a mapping table that converts each Atlas qualifiedName into its target fully qualified name. Check case handling, the default schema behavior for Hive databases, and how topic names containing dots or hyphens are treated by the connector you choose.

Unmatched names create duplicate assets. Illustratively, if a connector ingests a Hive table as one fully qualified name while the migrated Atlas record lands under a different service and schema, the catalog holds two entries for one table. Owners, tags and descriptions then split across them, and search returns both. Duplicates also break lineage, because edges point at one entity while documentation sits on the other. After the first pass, run a reconciliation query that counts assets per fully qualified name and flags any table or topic that appears under two services. Zero duplicates should be the exit condition for this section.

Connector coverage is the final check. OpenMetadata lists more than 130 connectors for warehouses, BI tools, pipelines and ML platforms (OpenMetadata GitHub). Confirm which Hive and messaging connectors you will use, the OpenMetadata version they support, and their documented scope: which metadata they read, whether they capture columns, ownership and topic schemas, and what they leave out. Any Atlas metadata that the chosen connector does not cover will need a manual or API-based path. Record those gaps now, so owner assignments and naming decisions are made with the actual connector behavior in view.

The first decision here is not technical. List every Atlas classification in use and record what each one means to your organization before choosing a target. Atlas classifications often encode sensitivity levels, retention periods or regulatory scope, and they are commonly attached to an entity so they flow downstream through lineage. Export the classification definitions, the entities carrying them and any attributes stored on each one. Then sort each classification into one of two groups. Classifications that describe a property of an asset, such as a sensitivity level or a retention label, usually become OpenMetadata tags, which teams can search and filter on. Classifications that name a business concept, such as a loan product or a customer identifier, usually belong in the glossary, where terms carry a definition, an owner and relationships to other terms. Record the decision and the approver for each row.

Propagation is the part most likely to be assumed away. In Atlas, a classification can propagate along lineage so that a sensitive source column marks derived columns automatically. Before assuming OpenMetadata behaves the same way, confirm how your Atlas propagation rules actually work: which classification types propagate, in which direction, whether propagation can be blocked on a single entity, and whether anyone has overridden it by hand. Pull a sample of entities that inherited a classification through lineage and record whether each label was inherited or set directly. OpenMetadata supports table and column lineage with OpenLineage event integration, but whether a tag applied upstream reaches downstream assets in your deployment depends on how lineage and tagging are configured. Write the expected behavior for each classification as a rule, test it on a known path after migration, and log any gap with a named owner.

Reapplying classifications is a separate step from moving metadata, and re-ingested assets arrive without the Atlas labels. Keep the mapping in version control as a versioned artifact. Each row should hold the Atlas classification, its OpenMetadata target (tag, glossary term or domain), the approver and the pipeline that applies it. Apply labels through the REST API or the Python SDK in a script that can run again without creating duplicates. Then check how your connector runs treat tags that someone has already set in the user interface. Depending on configuration, a re-ingestion may overwrite manual changes or leave them alone, so confirm this on a test source before the production run. Also decide what happens to labels on assets that still exist in your sources but were removed from Atlas, since no one may own that decision yet.

Finally, check that the governance decisions still hold. Build a checklist from the Atlas inventory: every asset that carried a sensitivity classification should carry its equivalent tag, every glossary term should have an owner and a definition, and domains should match the business areas that own the data. Review any access or retention decision that relied on an Atlas label against the new label before relying on it. Run the same queries against both catalogs during the parallel period and reconcile each difference with the data owner. Have your compliance lead sign off the reconciled list. This produces evidence an independent auditor can review, but it does not replace the audit itself. Keep the reconciliation records alongside the mapping so the reasoning behind each decision can be traced later.