Migrate from Amundsen to OpenMetadata

What a move from Amundsen to OpenMetadata involves

A data team running Amundsen that wants OpenMetadata's governance layer usually has a working catalog, owners who maintain descriptions, and search habits that people depend on. The move is part metadata import and part re-ingestion from sources. The Amundsen connector reads the metadata held in the Amundsen graph store, so existing table descriptions, tags and ownership records can be carried across. Assets that OpenMetadata should model differently, and the lineage, profiling and quality results it needs directly from the source systems, are ingested again from those sources. The effort depends on three things: the size of the catalog, how much customization the team has built around Amundsen, and how long both systems must run side by side.

The work is planned and fixed-scope. Before any build starts, the team inventories the Amundsen estate: entity counts by type, the sources behind them, custom fields or scripts, the access model, and the people who use the catalog every day. That inventory becomes the written scope and the cutover plan. No duration is given here because the duration follows from the inventory. A catalog with a stock configuration and a few well-documented sources differs greatly from one with many custom extractors and heavy manual curation. Ask for a scope that names each source, the metadata to import, the assets to re-ingest, the validation checks that define a completed import, and the conditions under which cutover goes ahead.

Running both systems during cutover adds recurring cost that is easy to underestimate. Each system needs its own infrastructure, its own ingestion schedules and its own upkeep, and the team has to decide which system is authoritative for edits in each domain at each point in time. The one-time costs are the inventory, the import and re-ingestion work, validation and cutover. The recurring costs are the infrastructure and staff time for as long as both catalogs exist. In a quote, ask for the inventory as a separate, itemized deliverable, the re-ingestion effort per source, the validation approach, and the length of the parallel run stated as an explicit assumption that can be changed.

Several decisions and risks need an owner before the build. Descriptions and ownership curated in Amundsen may need review because OpenMetadata organizes them through domains, glossaries and ownership models that the team may configure differently. Access rules must be redesigned rather than copied, and search results will behave differently for users. Confirm the Amundsen and Neo4j versions in your own environment, since this page does not state them, and check the OpenMetadata version and deployment target against the current release notes and deployment documentation before planning the cutover window.

Which Amundsen metadata maps cleanly to OpenMetadata

This table compares Amundsen metadata objects with their OpenMetadata equivalents and shows how each is expected to move. Read the status in the third column as a starting point: connector-driven rows still need checking against your own Neo4j export, and rows marked for testing need a sample import on the target version. The main takeaway is that names, hierarchy and descriptions usually carry over, while ownership, tags, usage signals and search ranking need deliberate mapping and verification.

Amundsen metadata	OpenMetadata equivalent	Migration note and status
Tables	Tables under database and service hierarchy	Expected through the Amundsen connector. Verify names and fully qualified paths against your export.
Columns	Columns on each table, with data types	Expected to carry over with the table. Confirm column types on a sample table after import.
Dashboards	Dashboards and charts linked to source tables	Confirm by testing on the target version. Lineage links may need manual re-linking.
Owners	Ownership assigned to users or teams	Confirm by testing. Map each Amundsen owner to an existing OpenMetadata user or team before import.
Tags	Tags and classifications on tables and columns	Confirm by testing. Map each Amundsen tag to an OpenMetadata tag or classification before cutover.
Descriptions	Table and column descriptions	Expected to carry over. Check formatting, line breaks and length on a sample set of tables.
Glossary terms	Glossary terms linked to assets	Usually held in descriptions or tags in Amundsen. Create terms in OpenMetadata and link them manually.
Domains	Domains grouping data assets	Assign after import. Check whether your export includes any grouping that can seed domain assignment.
Usage statistics and search ranking	Usage signals and search relevance in OpenMetadata	To confirm. Do not assume these carry over. Verify how the target version ranks search before go-live.

How the Amundsen connector reads Neo4j

The documented path for moving an Amundsen catalog into OpenMetadata reads metadata directly from the Neo4j database that backs Amundsen, using OpenMetadata's Amundsen connector. Amundsen stores its table, column, user and lineage records as a graph in Neo4j, so the connector does not query the Amundsen web application or its search index. Before any planning, confirm with the OpenMetadata connector documentation which Amundsen and Neo4j versions the connector supports and exactly which entities it reads and writes. Scope decisions made later depend on that answer, so treat it as the first item on the checklist.

Neo4j access is the first thing to prepare. The connector needs a database account with read permission on the graph that holds Amundsen's metadata. Ask the Amundsen operator which database and graph name hold the data, whether more than one database exists (for example, a staging copy), and whether the account can be scoped to read-only. Document the account owner and the credential storage location now, because the OpenMetadata ingestion service will store and use that secret. Your security team should approve the account's permissions before the first connection test, not after.

The second preparation item is a network path from the OpenMetadata ingestion runner to the Neo4j endpoint. The runner is the process that opens the connection, so the firewall rules, DNS entries and any TLS trust chain must allow traffic from the runner's subnet or cluster to the Neo4j port. In a Kubernetes deployment, check egress policies on the namespace where ingestion runs. In a bare metal deployment, check the host firewall and any proxy. Ask the Neo4j team whether the database accepts connections from that address range and whether certificates are issued by an internal authority that must be added to the runner's trust store.

The third item is a test instance of the target OpenMetadata version. Run the connector against a non-production OpenMetadata deployment first, using a copy or sample of the Neo4j data. This instance should match the version and deployment model you plan to run in production, because connector behavior and ingestion image requirements change between releases. If you intend to upgrade across major versions, plan that upgrade separately and read the OpenMetadata upgrade notes before choosing the target. Use the test run to measure how many entities the connector returns, which fields arrive populated, and where the output differs from what Amundsen shows users.

Documented import paths for an Amundsen catalog

Amundsen metadata can reach OpenMetadata through a documented connector, while the REST APIs, Python SDK and TypeScript packages cover the gaps and corrections the connector leaves behind. Choose the path for each object type, and confirm every option against the documentation for the OpenMetadata release you deploy.

Amundsen connector reading Neo4j

Start with the Amundsen connector, which reads the Neo4j graph behind your Amundsen catalog. It is the primary path for bulk metadata, so it carries most of the catalog volume. Run a first load against a copy of the Neo4j data and compare counts and sample records with Amundsen before any production ingestion is scheduled. Treat that comparison as the acceptance check for the import.

Confirm connector scope per release

Which Amundsen entities, relationships and fields the connector maps depends on the OpenMetadata release you deploy. Confirm them in the connector documentation for that release before planning the import. Record every object type the connector does not cover, along with the owner who will fill it. This inventory of gaps becomes the work list for the API, SDK and script steps that follow.

REST APIs for targeted corrections

The REST APIs suit single-object fixes, such as correcting an owner, adding a description or attaching a glossary term to one table after the connector load. They operate at the lowest level, so one call per record fits small sets of changes. Use them for reviewed exceptions from the gap inventory, and keep a log of each change so corrections can be audited against the original Amundsen values.

Python SDK for bulk gap filling

The Python SDK suits gap filling across many entities, such as applying ownership or domain assignments from a reviewed spreadsheet or an Amundsen export. It keeps the logic in code that can be versioned, tested in a dry run and repeated after each connector run. Ask the implementation team to confirm that the SDK version matches your OpenMetadata server before the first batch.

TypeScript packages for internal tooling

The TypeScript packages suit teams that already build internal portals or front-end tools in JavaScript and want to read or update catalog entities from that stack. They fit steward review workflows, such as a small internal page that lets owners confirm assignments before a write runs. Choose them only when the team that owns the tool will maintain it after handover.

Custom scripts need testing

Any script written to fill a gap or correct a field is built and tested by the implementation team. The connector and the vendor do not supply it. Plan for unit tests against a sandbox OpenMetadata instance, a rerun check after each connector load and a rollback approach for bad writes. Ask for the test cases and the sign-off owner to be written into the scope before work starts.

What must be re-ingested from source systems

Lineage, profiling, freshness and data quality should be re-established by running OpenMetadata's own ingestion against the live sources: warehouses, BI tools and pipeline schedulers. Anything Amundsen showed was a snapshot of what its extractors saw at the time, so it can be stale or incomplete. OpenMetadata's connectors read each system of record directly, and its lineage (table, column, dashboard, pipeline and metric) can come from connector metadata or OpenLineage events, depending on the source. Confirm, for each connector in your target version, which lineage method it uses and what it needs in the source system, such as query log access or event emitters. Profiling depends on the profiler configuration, and OpenMetadata 2.0 made Dynamic Sampling the profiler default, so review sampling settings before comparing profile results with the old catalog.

Data quality tests and freshness checks should be defined again in OpenMetadata and run against the source tables. If Amundsen displayed a quality or freshness status, that status was a copy of a result produced elsewhere, and it has no meaning inside OpenMetadata until a test runs there. Ask the owning data teams which checks matter for each critical table, write those tests as OpenMetadata test cases, and set freshness expectations that match the actual load schedule. Do not migrate last-run timestamps or pass and fail history as if they were current results. Keep the old status values in a reconciliation export so auditors and data owners can see what changed and why.

Ownership needs human review. Owner fields in Amundsen were often filled from a directory lookup, a source hint or a manual edit, and many have not been checked since the person changed roles or left. Treat every migrated owner as a candidate until a steward or data owner confirms it. Decide which role each owner plays (technical owner, business owner, steward or domain lead), map each to an OpenMetadata user or team, and check that a named approver exists for each domain. Assets with no confirmed owner should be listed and assigned before cutover, because access decisions and quality alerts depend on that assignment.

Glossary and tag decisions also need a named reviewer. Amundsen descriptions, tags and badges do not map one to one onto OpenMetadata glossary terms, classifications and tags, so each category needs a deliberate choice. Decide which descriptions become asset descriptions, which become glossary definitions, and which are retired because they duplicate another term. A glossary steward should agree definitions, remove near-duplicates and approve term links to assets before linking is bulk-applied. Classifications for sensitive data should be re-derived from the source scan or reviewed manually, and no classification should be carried over without someone confirming it still applies.

Before deciding what to re-ingest, confirm which items the Amundsen connector carries over in your version of OpenMetadata and which it leaves behind. Connector documentation and a test run on a non-production catalog are the most reliable sources for this. Build a reconciliation register with one row per metadata type: the source of truth, the action (carry over, re-ingest, review manually or retire) and the owner of that decision. Use the REST API or Python SDK to compare asset counts, owners and glossary links between the two catalogs, and reconcile the differences in the register rather than assuming the connector copied everything it should.

Running Amundsen and OpenMetadata side by side during cutover

Cutover moves users, search and ownership from Amundsen to OpenMetadata in gated stages, with both catalogs live long enough to show that the same questions get the same answers. Each gate has a named approver and a written exit check, so the team can stop or roll back before Amundsen is retired.

Inventory the Amundsen catalog and sources
Your data platform lead and the catalog owner list every table, dashboard, owner, tag and description held in Amundsen, along with the source systems that feed each one and the ingestion job that populates it. The inventory also records which Neo4j nodes and relationships hold ownership, lineage and descriptions, so nothing is lost by accident. Data owners sign off on the inventory. The step is done when every source has a named owner, an ingestion method and a decision on whether it is in scope for the first wave.
Pilot the migration on one domain
Choose one business domain with active Amundsen users and load its metadata into a test OpenMetadata instance. The domain owner and the governance lead compare search results, owners, descriptions and key lineage paths against Amundsen for that domain only. Every difference is logged with a proposed fix and an owner. The pilot closes when the domain owner accepts the agreed comparison list and the open gaps have documented fixes, which becomes the template for later domains.
Deploy OpenMetadata on infrastructure you control
The DeployOpen team installs the target in your cloud accounts, data centers or air-gapped network, using Kubernetes on EKS, AKS, GKE or an on-premises cluster, or bare metal. Bare metal needs Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x, and sizing should be checked against the documented minimums and your expected volume. Your platform owner and security lead sign off on hosting, SSO, backups and secrets. The step is done when the instance runs and a tested restore is recorded.
Import the Amundsen connector and reconcile
Configure the Amundsen connector to read the Neo4j store and run the import into the test instance. Reconcile entity counts, owners, tags and lineage edges against the inventory from step one, and confirm in the connector documentation which node types and relationships map to which OpenMetadata objects. Each difference is classified as carried over, transformed or dropped, with a reason. The catalog owner signs off the reconciliation report, and the step is done when every difference has a classification.
Re-ingest metadata from source systems
Metadata that Amundsen only copied from sources is pulled again with OpenMetadata's native connectors, so schemas, profiling and quality results come from the source systems rather than from a stale copy. The data engineering lead confirms that each in-scope source has a supported connector and version in the official connector list before the run. Each source is signed off by its owner. The step is done when every in-scope source has a successful ingestion run and its schemas match the source.
Run both catalogs in parallel
Amundsen and OpenMetadata stay live together for the agreed period. Domain owners write a fixed set of business questions, such as who owns a given table, what feeds a dashboard, and which glossary term applies to a column, and the team answers each question in both catalogs. Discrepancies go to a shared log with an owner. The domain owners and the catalog owner sign off the parallel run. It is done when every question has a matching answer or an accepted, documented explanation.
Cut over search and ownership
Search, bookmarks and internal links move to OpenMetadata, ownership and stewardship assignments are transferred, and any integration that calls the Amundsen API is repointed to OpenMetadata's REST APIs or SDKs. Users are told the change date and where to report problems. The change advisory board approves the cutover, and the catalog owner confirms the assignments with each domain owner. The step is done when search traffic is served from OpenMetadata and no open ownership gaps remain.
Decommission Amundsen and archive Neo4j
After the hold period agreed at the cutover gate, the team stops Amundsen ingestion jobs, takes a final export and a snapshot of the Neo4j store, and places both in an access-controlled archive. Retention follows your records policy, and your compliance lead confirms that the archive meets it. Security signs off on access to the archive. The Amundsen services are then shut down. The step is done when the archive has been restore-tested and the decommissioning record is filed.

What drives the cost and duration of the migration

This table lists the eight drivers that change the effort of moving from Amundsen to OpenMetadata, and whether each one adds mostly one-time or recurring work. Use the last column as a checklist when you request a written quote, so every driver maps to a stated scope item. The main takeaway is that decisions made before ingestion, such as metadata cleanup and identity design, often shape the work more than the migration tooling does.

Driver	Why it changes effort	One-time or recurring	What to ask for in a quote
Number of sources and connectors	Each source needs its own OpenMetadata connector, credentials and a validated re-ingestion run.	One-time setup, recurring if sources stay live	Connector list per source, confirmation each has a documented connector, and who holds credentials
Volume of tables and dashboards	More assets lengthen ingestion runs, increase search indexing and add review of migrated results.	One-time migration, recurring storage and runs	Asset counts by type, expected run windows, and database and search sizing
Degree of custom Amundsen metadata	Custom tags, attributes or bespoke fields need mapping to OpenMetadata entities or may need custom work.	One-time	Inventory of custom fields, target mapping for each, and which fields are dropped
Ownership and glossary cleanup	Stale owners and inconsistent terms carry over unless cleaned first, and your data owners must approve changes.	One-time	Who signs off owners and terms, glossary term count, and the cleanup responsibility split
Identity and access integration	Moving access to a documented SSO provider and role model requires identity design. Basic authentication and SSO cannot run together.	One-time build, recurring user lifecycle	Identity provider, role mapping, and how existing basic-auth accounts move at cutover
Hosting choice	Kubernetes or bare metal changes installation, upgrades and backups. Bare metal needs Java 21 and listed database and search versions.	One-time build, recurring operations	Hosting target, database and search versions, and who performs upgrades and backups
Length of the parallel run	Running Amundsen and OpenMetadata together means two sets of schedules and sync checks until users switch.	Recurring for the length of the run	Run length in writing, criteria for ending the parallel run, and who maintains both
Number of users to train	More user groups mean more sessions and materials, and each team needs workflows for its own assets.	One-time, plus recurring for new joiners	User groups by role, training format, materials, and whether handover covers new hires

What usually goes wrong when a catalog moves platforms

Most catalog moves do not fail during the import itself. They fail afterward, when records exist but are wrong, incomplete or ignored. The five risks below share one root cause: Amundsen and OpenMetadata run side by side without a named owner for each decision about what is authoritative.

Ownership gaps after import

Owners recorded in Amundsen do not always resolve to owner records in OpenMetadata after import, so tables can appear with no accountable team. Ownership often depends on people, groups or tags that the source never modeled the same way. Before cutover, sample assets in each domain and confirm that every owner resolves to a user or team that still exists in your identity provider. Confirm which owner attributes your Amundsen instance stores and how your SSO group names map to OpenMetadata teams.

Duplicate assets from two ingestion paths

If the Amundsen connector and a native OpenMetadata connector both ingest the same database or warehouse, one table can appear twice under different fully qualified names. Duplicates split lineage, tests, descriptions and ownership across two records, and search returns both. Choose one ingestion path per source and record that choice in your cutover runbook. Confirm the service names and database and schema naming in each source, because these determine whether records merge or split.

Lineage that is incomplete by omission

Lineage in OpenMetadata can look complete while still missing every source that has not been connected yet. Edges from pipelines, BI tools or streams that are not yet in scope simply do not appear, and the graph gives no warning. Maintain a register of lineage sources marked as connected, planned or out of scope, and review each domain's graph against that register. Confirm which pipeline and BI sources your platform team will connect first and whether OpenLineage events will feed the catalog.

Searches that stay on the old catalog

During a parallel run, analysts often keep using the Amundsen search bar because it still works. Descriptions and ownership edited in one system then never reach the other, and the two catalogs drift apart. Set a dated freeze on metadata edits in Amundsen for each domain, publish the new search location to every team, and update links where you control them, such as onboarding pages and dashboards. Confirm which teams link to Amundsen from notebooks, runbooks and dashboards, and who will change those links.

Target sizing too small for search and database

OpenMetadata's bare metal documentation lists minimums of 2 vCPUs and 4 GB RAM for the server, and at least 2 vCPUs, 2 GB RAM and 30 GB storage each for the database and search services. These figures are a floor. They do not account for your ingestion schedule, profiling workload or number of concurrent searches. Undersized search nodes slow results during the parallel run, and undersized databases slow ingestion. Size from your asset count, ingestion frequency and user count, and ask your platform team for the storage growth rate observed in your environment.

Questions buyers ask before moving from Amundsen

Can our team migrate from Amundsen to OpenMetadata without a partner?

Often yes, if your team has the skills and time, but check that against the skill list below before deciding. The move has four kinds of work: setting up OpenMetadata in your infrastructure, pointing the Amundsen connector at the Neo4j database that holds your Amundsen graph, re-ingesting metadata from each source system, and validating ownership, lineage and access before people switch. Your team will need people who know your source systems, the Neo4j data model, and either Kubernetes or bare metal operations. Teams with that mix in-house often handle the move internally. Teams short on one of these skills usually bring in a partner for the gaps. DeployOpen can plan, implement and document the move inside your environment under a written scope, so the decision mostly depends on where your gaps are.

What drives the effort and cost of an Amundsen migration?

Effort depends mainly on how many sources you have, how much of your catalog is curated, and how much custom logic your lineage depends on.

Main drivers:

Number of source systems and whether each has a connector in OpenMetadata
Volume of owners, tags, descriptions and glossary terms that must be checked
Custom lineage or transformation logic
Access model and SSO design
Number of environments and how long both catalogs run together

Cost has one-time parts (planning, build, validation, training) and recurring parts (hosting, operations, upgrades, and any support contract you keep). OpenMetadata is open source and has no license fee, so the spend is mostly labor and infrastructure. Ask any quote to show these lines separately.

How long does an Amundsen to OpenMetadata migration take?

No duration should be fixed until the scope is written, because the schedule follows from its inputs. Ask for a schedule that ties each phase to a named input: source inventory, Neo4j access, environment readiness, validation sign-off and the cutover window. The largest variables are the number of sources, how much manual curation your catalog holds, and whether your staff can work on the migration alongside their normal duties. Ask the provider to state its assumptions, the dependencies on your staff, and what happens if a source system is unavailable during ingestion. A timeline without these assumptions is hard to compare across quotes.

What do we need from our staff during the move?

Four roles carry most of the work, and each needs a named person before kickoff.

Catalog owners confirm which assets, owners, descriptions and glossary terms are current, and approve what carries over.
Source admins provide read credentials and network access for each system OpenMetadata connects to, and help configure connectors.
Neo4j access lets the Amundsen connector read the graph database. Your database team usually sets up a read-only account. Confirm the exact access pattern in the connector documentation.
A sign-off authority approves validation results and the cutover decision.

Agree these names and their time commitments in the written scope.

Can Amundsen and OpenMetadata run side by side during cutover?

Yes. Amundsen and OpenMetadata are separate systems, so both can run while teams validate results, as long as each has its own infrastructure and the Neo4j source stays available. Freeze metadata edits in Amundsen during validation so owners do not change records in two places. Confirm how the connector handles repeated runs and whether incremental ingestion can keep both catalogs current before you set a cutover date. Plan the cutover as a dated step with a documented rollback path, and retire Amundsen only after the sign-off authority has approved the results.

Is OpenMetadata free to use under its license?

Yes. OpenMetadata is released under the Apache License 2.0, which permits use without a license fee. Collate, which maintains OpenMetadata, also offers commercial enterprise capabilities and premium support. Check which features your requirements depend on, because those may sit in commercial offerings rather than the open-source release. Your legal team should confirm the license terms for your use case. Your main costs will be infrastructure, staff time, and any optional commercial or support contract you choose.

What should a written migration scope include?

A written scope should state what is in and out, so quotes can be compared fairly. Include:

Source systems and environments covered, including Neo4j access details
Metadata to migrate by type (owners, tags, descriptions, lineage, glossary) and what is re-ingested from sources
Validation method, acceptance criteria and the named sign-off authority
Deployment target (Kubernetes or bare metal), with versions confirmed at build time
Cutover approach, parallel running period and rollback
Client responsibilities, deliverables, documentation and handover
Assumptions, dependencies and change control

DeployOpen agrees scope, deliverables and timelines in writing before work starts.

Which Amundsen metadata carries over, and what must be re-ingested?

The answer depends on which fields the Amundsen connector reads from Neo4j and how each field maps to OpenMetadata. Confirm the connector's supported fields in its documentation before the build. Expect technical metadata such as schemas, tables and columns to be ingested directly from source systems, so OpenMetadata holds its own copy. Lineage, data quality tests and profiling usually need configuration in OpenMetadata itself. Manually entered descriptions, owners and tags should be checked after transfer. Ask the provider for a field mapping document and a list of known gaps before work starts.

How DeployOpen scopes and delivers an Amundsen to OpenMetadata move

DeployOpen plans and delivers the move from Amundsen to OpenMetadata inside infrastructure you control, from scoping through handover. The work covers the Amundsen connector reading your Neo4j metadata, the items that must be re-ingested from source systems, and a parallel run while teams cut over. Engagements are fixed-scope, with the scope agreed in writing before work starts.

How we scope

The written scope lists the Amundsen instance, its Neo4j database, and the source systems whose metadata must be re-ingested.
We map which entities, owners, tags and lineage the connector carries over and which must be re-created.
Scope covers the OpenMetadata deployment target, whether Kubernetes or bare metal, plus SSO and the cutover window agreed up front.

How we build

We deploy OpenMetadata and its database and search services at the sizing agreed in scope, following the documented prerequisites.
We run the Amundsen connector against the Neo4j store in a test environment and review the imported entities before production.
We re-ingest warehouse, BI and pipeline metadata from sources, then check lineage, owners and glossary terms against Amundsen.

How we hand over

Handover includes deployment documentation, connector configuration, and a record of which entities were migrated and which were re-created.
Runbooks describe the parallel run, the cutover steps, and the rollback path to Amundsen if a check fails.
Your team receives the configuration and access model, and the decision to retire Amundsen stays with your owners.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Upgrades follow the OpenMetadata 2.0 breaking-change list, including the Python 3.12 ingestion image rebuild, where your environment uses custom images.
Scope the retainer at handover so ingestion schedules, connector credentials and search capacity have a named owner.