OpenMetadata vs Amundsen: when each fits an archived catalog
If your data team still searches an Amundsen catalog, you are working from a project that was archived in September 2026, with no service release since March 2024 and a read-only repository. For most teams in that position, OpenMetadata is the active option to plan around. Its 2.0 line is current, with 2.0.5 released on October 8, 2026, and it covers discovery, lineage, glossaries and governance in one platform. Keeping Amundsen running makes sense mainly as a historical search reference, where nobody needs new metadata, fixes or security updates. Treat that as a time-limited choice with a retirement date, and record which users and dashboards still depend on it.
Three conditions usually decide the choice. The first is existing Neo4j data. OpenMetadata's Amundsen connector reads metadata from Amundsen's Neo4j backend over a Bolt URI with a read-only account, and it includes tags by default, so existing descriptions and classifications can carry across. Owners are assigned only when the source owner's email matches an OpenMetadata user, so confirm that directory emails are consistent before you rely on owner data. The second is Airflow usage. OpenMetadata runs metadata ingestion on Airflow, and Airflow 2 reached end of life on April 22, 2026. If your ingestion already runs on a supported Airflow release, the move is simpler. If it does not, plan the Airflow upgrade as part of the cutover (Amundsen connector docs).
The third condition is the search and governance stack. OpenMetadata needs Elasticsearch 9.x or OpenSearch 3.x for search, MySQL 8.0.42 or later or PostgreSQL 15 or later for its database, and Java 21 on bare metal. Check whether your platform team already runs those versions before committing. If your needs extend past search into glossaries, classifications, data quality and lineage, OpenMetadata covers them in one product. If you only need ranked search over tables and dashboards, confirm that a lighter option still meets the requirement. DataHub is the other Apache-2.0 catalog most shortlists include, and it has its own comparison page, so use that page to test its Kafka-based design against this list.
Which catalog fits which team situation
This table maps common team situations to the catalog most likely to fit, with the reason and the conditions that change the answer. Read it against your own Amundsen footprint, your Airflow usage and your governance scope, since those factors usually decide the outcome more than feature lists do.
| Team situation | Better fit | Reason and where it depends |
|---|---|---|
| Amundsen running with Neo4j and an existing databuilder Airflow DAG | OpenMetadata (illustrative path), with a parallel run | OpenMetadata's Amundsen connector reads the Neo4j backend over Bolt with a read-only account, so existing metadata can move without rebuilding every source. Confirm that your Neo4j version and graph model match what the connector expects before you commit. |
| Team wants glossary, lineage and data quality in one tool | OpenMetadata | OpenMetadata documents table, column, dashboard, pipeline and metric lineage, glossaries, classifications, data quality tests and profiling in one product. Amundsen's documented scope is discovery and search, so it would need other tools for the rest. |
| Team needs only read-only historical search over existing metadata | Neither as a new build, or a frozen export | Amundsen is archived and its repository is read-only, so it gets no fixes. If you only need to search a snapshot, export it and keep a read-only copy, and reserve the cutover effort for teams that must keep updating metadata. |
| Team has Neo4j or Atlas expertise but no Airflow | Depends on your ingestion tooling | OpenMetadata documents Airflow for running metadata ingestion, and DataHub centers on Kafka streaming. Without Airflow, weigh the cost of adding and operating it against the cost of Kafka, and confirm which operating skills your team already has. |
| Team already runs Kafka and wants push-based change streams | DataHub (confirm fit) | DataHub's architecture uses Kafka for streaming metadata changes, which suits teams with Kafka operations. Compare this against OpenMetadata's database, search and Airflow dependencies in the sibling DataHub comparison. |
| Team wants a managed vendor rather than self-hosting | Neither open-source option alone | Self-hosted OpenMetadata and DataHub both require your team to run databases, search and ingestion. Check Collate's managed offering and its deployment models if operating the stack is the constraint, and ask each vendor for written support terms. |
| Team needs a Hadoop-era catalog with Hive and Ranger hooks | Apache Atlas comparison first | Amundsen is not a replacement for Atlas's Hive, Kafka and Ranger integrations. Review the OpenMetadata vs Apache Atlas comparison before deciding, because the migration path differs. |
How each catalog is built and what that means for operations
Amundsen and OpenMetadata both index metadata for search, but they carry very different dependency stacks and maintenance histories. The cards below trace each component to the patching, on-call and skills work it creates, so you can size the cutover against your own team.
Amundsen's frontend and search layer
Amundsen's frontend is a Flask application with a React interface, and its search service runs on Elasticsearch. Both are small in concept, but they are the parts users touch daily, so any browser or search regression is visible immediately. Check whether your team still has engineers who can patch a Flask and React stack, and whether your Elasticsearch version is still supported by your own security policy. Because the project is archived, you will own every dependency update yourself.
Amundsen's metadata service and databuilder
Amundsen's metadata service keeps its graph in Neo4j or Apache Atlas, and the databuilder library loads that graph and the search index from Python scripts or Airflow DAGs. This means two stateful stores plus a custom Python loader that your team must keep running. The last databuilder release was 7.5.1 on August 14, 2024, so any change to a source system's API may require you to fix the loader yourself. Confirm who owns each DAG and whether the Neo4j instance has tested backups.
OpenMetadata's server, database and Java runtime
OpenMetadata runs as a Java 21 server backed by MySQL 8.0.42 or later, or PostgreSQL 15 or later, which stores its entity model and configuration. A Java runtime and a relational database are familiar to most platform teams, so the main on-call question is database capacity and upgrade sequencing. Each 2.0.x maintenance release may carry migration steps, so schedule server and database patching together and test them in a non-production copy first.
OpenMetadata's search and Airflow ingestion
OpenMetadata uses Elasticsearch 9.x or OpenSearch 3.x for search and Apache Airflow to run metadata ingestion. Your team will need to operate a search cluster and an Airflow scheduler, which may already exist in your environment or may be new. Ingestion images are built on Python 3.12 with Apache Airflow 3.3.0 in the 2.0 line, so custom connector images must be rebuilt. Ask who will own the Airflow environment and whether it can run the Amundsen connector alongside existing jobs during the cutover.
Minimum sizing for each OpenMetadata tier
OpenMetadata's documented minimum server size is 2 vCPUs, 4 GB RAM and 20 GB storage. The database and search services each need at least 2 vCPUs, 2 GB RAM and 30 GB storage. These are floors, not production sizing, because catalog volume, profiling and lineage history grow with the number of assets you ingest. Use the minimums to confirm that your existing hosts can take the stack, then size production from your own asset counts in a pilot.
Maintenance status of each catalog
Amundsen's README states that the project was archived in September 2026 due to inactivity, and the repository is read-only. Its last service releases were on March 6, 2024, so security fixes will not come from upstream. OpenMetadata is Apache-2.0, maintained by Collate, and its 2.0 line is current with 2.0.5 released on October 8, 2026. The practical difference is who patches: your team for Amundsen, and the upstream project plus your own upgrade process for OpenMetadata.
How OpenMetadata vs Amundsen compares on discovery, lineage and governance
This table sets OpenMetadata's documented capabilities against what Amundsen offers in its archived form, so teams can see where the gaps lie. Read the Amundsen column as a record of its design, and confirm any item marked for verification against the archived repository before you plan a cutover.
| Capability | OpenMetadata (Apache-2.0, 2.0 line) | Amundsen (Apache-2.0, archived September 2026) |
|---|---|---|
| Lineage | Table, column, dashboard, pipeline and metric lineage, with OpenLineage event integration | Not documented in the supplied README. Confirm in the archived repository whether any lineage model exists |
| Search and discovery | Search over cataloged assets with governance metadata such as glossaries, tags and domains | Page-rank style search driven by usage patterns, indexing tables, dashboards and streams, backed by Elasticsearch |
| Glossary and classification | Glossaries, classifications and domains are built in | Not documented in the supplied README. Confirm tag and glossary support in the repository |
| Data quality and profiling | Data quality tests, profiling, freshness checks and Dynamic Sampling as the 2.0 profiler default | Not documented. Amundsen is a discovery engine, so confirm whether any quality features exist before assuming none |
| Programmatic access | REST APIs, a Python SDK, TypeScript packages and Java libraries | Databuilder Python library loads the graph and search index, run by script or an Airflow DAG |
| Connectors and ingestion | More than 130 connectors for warehouses, BI tools, pipelines and ML platforms, run through Airflow ingestion | Databuilder extractors, with amundsengremlin (AWS Neptune) and amundsenrds (relational) as alternate backends |
| Maintenance status | Active releases, with 2.0.5 released on October 8, 2026 | Archived in September 2026. Last service releases were March 6, 2024 and the last databuilder release was August 14, 2024 |
What OpenMetadata's Amundsen connector ingests from Neo4j
The OpenMetadata Amundsen connector reads metadata from Amundsen's Neo4j graph over a Bolt URI, using a read-only account. Create that account with read access to the graph and nothing else, and confirm the Bolt endpoint with whoever operates Amundsen before the first run. The ingestion host must be able to reach that endpoint. Tags are included by default, so the classification labels your analysts already use for discovery should arrive without extra configuration. Verify a sample of tagged tables after the first run to confirm the labels appear as expected in OpenMetadata.
Ownership is the part that needs planning. The connector assigns an owner only when the owner's email in Amundsen matches a user that already exists in OpenMetadata. Owners without an account, owners who have left the company, and owner values that are not personal email addresses will load without an owner. Before cutover, export the owner list from Amundsen, compare it with your OpenMetadata user directory, and decide for each gap whether to create the user, reassign the asset or accept it as unowned. Align the email values in your identity provider first, because that alignment usually determines the match rate.
Treat the connector as the transfer of catalog metadata, and plan separately for everything else. The documented scope covers tags and owners, so do not assume that lineage, data quality tests or profiling configuration you built around Amundsen will follow. List the Amundsen features your teams actually use, then check each against the OpenMetadata Amundsen connector documentation. Rebuild lineage through OpenMetadata's own lineage support, including OpenLineage events, and recreate quality tests in its data quality framework. Run one ingestion into a staging instance and compare asset counts against Amundsen before you schedule the cutover.
Licensing and editions for OpenMetadata and Amundsen
OpenMetadata is released under the Apache License 2.0, so the open-source release can be installed, modified and run in your own infrastructure, and the license itself carries no fee. The project is maintained by Collate, which also offers commercial enterprise capabilities and premium support. Those paid features and support terms come through Collate, so a team that wants them needs a separate agreement with that vendor. The current line is 2.0, with 2.0.5 released on October 8, 2026, and maintenance releases arriving roughly every one to two weeks.
- Apache License 2.0: the open-source release is free to use under a permissive license, and you keep it inside your own network and change control.
- Collate maintenance: the company behind the project maintains the codebase and sells commercial enterprise capabilities and premium support.
- Paid features are a separate purchase: anything beyond the open-source release comes from Collate, so budget for it as its own line item if your requirements depend on it.
- Release cadence: version 2.0.0 shipped on August 24, 2026, and frequent maintenance releases mean you need a standing upgrade window in your operating plan.
Before you sign, ask Collate which features each offering includes, how long each release line receives support and what the upgrade path looks like for a self-hosted deployment. OpenMetadata releases is the natural next read for the release history.
Amundsen is licensed under the Apache-2.0 license and hosted by the LF AI and Data Foundation. Its README states that the project was archived in September 2026 due to inactivity and that its contents remain available for historical purposes. The amundsen-io/amundsen repository is read-only, so the upstream codebase can no longer receive changes. The last service releases were frontend 4.3.0, metadata 3.13.0 and search 4.2.0 on March 6, 2024, and the last databuilder release was 7.5.1 on August 14, 2024.
- Apache-2.0 license: the code can be used and forked without a license fee, but the license does not oblige anyone to fix bugs or patch security issues.
- LF AI and Data Foundation hosting: the project sat under a foundation, but archival means that foundation hosting no longer signals active development.
- Read-only repository: you can still read and copy the code, but upstream fixes will not arrive in the repository.
- No service release since March 2024: the most recent service versions are more than two years old at the time of archival, so any security posture depends on what you maintain yourself.
Ask any party offering Amundsen support to state in writing what they will patch, on what schedule and who is responsible for vulnerabilities in the frozen code. The Amundsen releases page shows the final version history.
Licensing is only the starting point. Edition boundaries, support windows and commercial terms change over time, so the answers should come from each vendor in writing. This tab lists what to confirm for both platforms before a contract, a budget request or an internal approval.
- Collate edition scope: confirm which capabilities, user or asset limits and support levels sit in each paid tier, and which of them your use case requires.
- Support window for OpenMetadata 2.0: confirm how long the release line you plan to run receives support and what the upgrade path looks like to later lines.
- Breaking changes in 2.0: plan for the move of embedding credentials into an llmConfiguration block, the new Databricks auth format, the Python 3.12 rebuild of custom ingestion images and the Great Expectations 1.3 migration before upgrading.
- Support for the archived Amundsen code: confirm whether anyone will provide patches, how that support is contracted and who carries the risk if they do not.
- Hosting model: if you need a managed deployment from Collate, confirm the deployment model it offers and do not assume it matches your open-source install.
Record each answer with the date and the name of the person who gave it, because edition terms and release lines change.
What drives running cost for each catalog
The running cost of OpenMetadata is driven mainly by its stack of dependencies, and each one is a line item you will pay for or staff yourself. OpenMetadata needs Java 21, a MySQL 8.0.42 or later or PostgreSQL 15 or later database, Elasticsearch 9.x or OpenSearch 3.x for search, and Airflow to run metadata ingestion. The documented minimum for the server is 2 vCPUs, 4 GB RAM and 20 GB storage, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. Those are floors, not production sizing. Hosting cost rises with the number of tables, the number of ingestion pipelines and how often they run, and how much profiling and sampling you enable. Amundsen's footprint is different: its frontend, search service and metadata service plus a Neo4j or Atlas persistent layer, and the Airflow DAGs that run databuilder. Because Amundsen is archived, any Neo4j, Elasticsearch or Python runtime it depends on will receive no upstream fixes from the Amundsen project, so you carry that patching cost yourself.
Staff skills and upgrade effort are usually the largest recurring costs, and they vary by platform. OpenMetadata engineers need Java, Airflow and the search and database tuning that goes with them. Amundsen operators need Python, Node, Neo4j or Elasticsearch experience, and someone who can keep a read-only Neo4j connection and Airflow DAGs working. Upgrade effort for OpenMetadata is not trivial. The 2.0 release notes list breaking changes that touch configuration and ingestion: embedding credentials moved into an llmConfiguration block, a new Databricks auth format, custom ingestion images rebuilt for Python 3.12, and a Great Expectations migration to 1.3 before upgrading. Budget time for those changes on every upgrade, and ask the vendor or partner to list each breaking change that applies to your connectors and custom images.
For a written quote, ask for these items separately: one-time migration work (connector setup, validating ingested tags and owners, rebuilding Airflow DAGs, and retiring the Amundsen stack), and recurring operations (hosting for each dependency, staff time, patch and upgrade cycles, and support). Ask what support tier is included, what response commitments are written in, and whether security patches for the Amundsen components you keep will be covered. Ask how the price changes if you add sources, raise ingestion frequency, or move from a single node to a highly available database and search cluster. Confirm the sizing assumptions in the quote against your own table counts and ingestion schedule, because the documented minimums will not reflect a production estimate.
Cutting over from Amundsen to OpenMetadata, step by step
This sequence moves discovery, owners and user access from a read-only Amundsen install to OpenMetadata in an order that keeps Amundsen available for comparison until each piece is verified and signed off.
Inventory Amundsen sources and databuilder jobs
Your data engineering lead lists every data source Amundsen indexes, every databuilder loader (Python script or Airflow DAG), the Neo4j or Atlas backend in use, and who maintains each job. Include any amundsengremlin or amundsenrds deployment, since the OpenMetadata Amundsen connector reads only the Neo4j backend. Record which sources OpenMetadata already connects to natively. The output is a signed inventory that the data platform owner and the security reviewer approve before any build work starts, so that gaps are visible early.
Stand up OpenMetadata with its dependencies
Your platform team deploys OpenMetadata in your own infrastructure with its database (MySQL 8.0.42 or later, or PostgreSQL 15 or later), search (Elasticsearch 9.x or OpenSearch 3.x) and Airflow for ingestion, on the deployment model chosen in your architecture review. Confirm Java 21 and the sizing in the bare metal documentation against your environment. Done means the server, database, search and ingestion services are healthy, backups are configured and a test user can sign in through your chosen identity method. Security sign-off is required before any production data is loaded.
Configure the Amundsen connector with read-only access
A DBA or Neo4j administrator creates a read-only account for the Amundsen Neo4j backend, and the platform team configures the OpenMetadata Amundsen connector with the Bolt URI and that account. Tags are included by default, so review them before the first run. Run the ingestion once in a non-production OpenMetadata project. Done means the connector run completes, the ingested tables and tags match a sample checked by hand against Amundsen, and the security reviewer has confirmed the account has no write permissions.
Map Amundsen owners to OpenMetadata users
A data governance lead exports the owner list from Amundsen and checks it against OpenMetadata users. The connector assigns an owner only when the source owner's email matches an OpenMetadata user, so every unmatched owner must be resolved by creating the user, correcting the email in the source, or assigning ownership manually. Done means each table in scope has an owner in OpenMetadata or is on a named exception list approved by the data owner. Owners who should not have access should be removed before users are invited.
Run a side-by-side search and owner comparison
Analysts and data owners run a fixed set of real discovery queries in both Amundsen and OpenMetadata and record the top results and owners for each. Amundsen ranks by usage patterns, so expect ranking differences and judge whether the OpenMetadata results are acceptable for your users rather than identical. Done means the test log shows agreed results for the priority tables, each mismatch has an owner and a decision, and the data governance lead signs off that discovery is fit for the user group that will cut over.
Rebuild lineage, glossary and quality tests
The connector covers the metadata it documents, so lineage, glossary terms and quality tests must be rebuilt rather than assumed to transfer. Your data engineers recreate lineage with the OpenMetadata lineage features and OpenLineage events where your pipelines emit them, define glossary and classification content, and rewrite any Amundsen-specific checks as OpenMetadata data quality tests. Done means each item on the rebuild list has an owner, a test or review result, and sign-off from the data owner for the affected domain. Anything that cannot be rebuilt is documented as retired.
Move users and recreate bookmarks
Your identity team provisions OpenMetadata access for each approved user through the identity method you confirmed in step two, and users recreate their saved searches and bookmarks in OpenMetadata, since these are not part of the connector scope. Share the new URLs and a short guide with users and set a read-only period on Amundsen. Done means every active Amundsen user has a confirmed OpenMetadata login, the access review is recorded, and the business owner has agreed the cutover date in writing.
Retire the Amundsen frontend and search
After the agreed read-only period and a final ingestion comparison, your platform team stops the Amundsen frontend, search and metadata services and the databuilder DAGs, then archives the Neo4j data and configuration according to your retention policy. Keep a verified backup and a documented restore path until the data governance lead and security reviewer confirm no dependent process still reads from Amundsen. Done means the services are stopped, the archive is verified and the change record is closed with all sign-offs attached.
What implementing each platform involves and where projects run long
A new OpenMetadata deployment starts with the dependency matrix and sizing. Plan for Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, Elasticsearch 9.x or OpenSearch 3.x for search, and Airflow to run metadata ingestion. The OpenMetadata bare metal documentation gives minimum sizing of 2 vCPUs, 4 GB RAM and 20 GB storage for the server, and at least 2 vCPUs, 2 GB RAM and 30 GB storage each for the database and search services. Treat those as floors for evaluation and size against your expected catalog volume. Then list the work items: ingestion pipelines and their custom images (2.0 requires rebuilding them for Python 3.12), connector credentials, SSO and role mapping, and a small first group of onboarded users. Confirm your Airflow version as well, since Airflow 2 reached end of life on April 22, 2026.
Keeping an archived Amundsen running is an ongoing maintenance commitment. The README says the project was archived in September 2026 and the repository is read-only, so no upstream fix for a vulnerability will arrive through the repository. The last service releases are frontend 4.3.0, metadata 3.13.0 and search 4.2.0 from March 6, 2024, and the last databuilder release is 7.5.1 from August 14, 2024. Your team owns every patch to the Flask frontend, the React build chain, the Elasticsearch client, the Neo4j driver and the databuilder jobs, and any runtime upgrade can break the build. The README lists Python 3.8 or later and Node v12 as requirements. Before you commit to another year on this stack, confirm with your security team that these runtimes, your base images and your vulnerability scanners still receive support in your environment.
The common overrun points are owner matching, lineage gaps, search relevance tuning, user retraining and ingestion schedules. The OpenMetadata Amundsen connector assigns an owner only when the source owner's email matches an OpenMetadata user, so audit owner emails in the Neo4j backend before the first run and expect some assets to arrive unowned. Tags are included by default, which can import years of tag sprawl, so decide what to keep before ingestion. Lineage is where surprises tend to appear, so compare a sample of tables against their source systems rather than trusting the migrated graph. Search ranking will change because Amundsen orders results by usage patterns, so build a set of representative queries and tune against it. Finally, users must relearn navigation, and schedules move from databuilder DAGs to Airflow-driven ingestion, so run both catalogs in parallel for a defined period.
What does an OpenMetadata vs Amundsen cutover cost and take?
What drives the cost of an OpenMetadata vs Amundsen cutover?
Cost comes mainly from engineer time and from the infrastructure OpenMetadata needs, and both depend on how much Amundsen work you are moving. Your own staff are paid for planning, connector setup, validation and decommissioning. Recurring costs include hosting the OpenMetadata server, its database, its search service and the Airflow environment that runs ingestion. Costs rise with the number of ingestion sources, custom databuilder jobs, the size of the Neo4j graph, the number of users to onboard and the lineage depth you need. If you use an outside partner, ask for an itemized written scope that separates one-time work (mapping, cutover, retirement of Amundsen) from ongoing work (upgrades, support, retainers), and confirm who pays for the infrastructure.
How long does an Amundsen cutover take to finish?
The pace depends on the size and messiness of your Amundsen estate, and the supplied facts do not give a duration, so confirm the timeline with your team and any outside provider before you commit. The biggest pace drivers are how many databuilder jobs and Airflow DAGs feed Amundsen today, how clean the owner and tag data is, and how many downstream users rely on search links or APIs. A parallel run, where both catalogs stay live while users and jobs move over, usually adds time but lowers the risk of a gap in discovery. Ask for milestones tied to ingestion parity, search checks and a user sign-off window, not only a completion date.
Can our own team run the cutover without outside help?
Yes, if your team already operates the components OpenMetadata needs and has the time to do the work. OpenMetadata's bare metal prerequisites include Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, Elasticsearch 9.x or OpenSearch 3.x, and Airflow for metadata ingestion. Someone must also own Amundsen's Neo4j read-only account, connector configuration, owner mapping and cutover testing. Teams without experience in those systems often find the Airflow and search work takes longer than planned. DeployOpen plans, implements and documents self-hosted platforms inside the client's infrastructure, usually under a fixed scope agreed in writing, so you can choose a full handover, a shared effort or an internal build.
What do our engineers need to check during the migration?
Engineers should check the connector path, the platform prerequisites and the data that comes across. Start by confirming that the Amundsen backend is Neo4j, because the OpenMetadata Amundsen connector reads from Neo4j over a Bolt URI using a read-only account. Next, confirm the platform versions: OpenMetadata 2.0 moved ingestion images to Python 3.12 with Apache Airflow 3.3.0, so custom ingestion images may need rebuilding. Size the database and search services at least at the documented minimum of 2 vCPUs, 2 GB RAM and 30 GB storage each, and then size for your real volume. Compare document counts, table and column lineage, tags and owners between the two catalogs before any user sees the new system.
Is it safe to keep running Amundsen after it was archived?
Amundsen can keep running, but it carries a growing security and maintenance risk that you must own. The Amundsen README states that the project was archived in September 2026 due to inactivity, and the GitHub repository is read-only. The last service releases were from March 6, 2024, and the last databuilder release was from August 14, 2024, so no upstream fixes have shipped under those versions since then. Any vulnerability found in Amundsen's Python, Node or Elasticsearch dependencies would need your own patching. Until cutover, restrict network access, limit who can reach the Neo4j account, scan the stack and set a retirement date. Check the Amundsen releases page yourself for any later tags before you decide.
Does the Amundsen connector move everything across?
No. The connector moves the metadata it can read from Amundsen's Neo4j backend, and you should verify each other category with a test migration. OpenMetadata's documentation says tags are included by default, and owners are assigned only when the source owner's email matches an OpenMetadata user, so unmatched owners will need manual mapping. Confirm how your team's other Amundsen content is handled, including any usage-based ranking, custom fields added through databuilder, dashboard metadata loaded by other jobs and saved search behavior. The connector is documented for Neo4j, so if your Amundsen deployment uses Apache Atlas or another backend, the path will differ and you should plan that separately. Ask the outside provider or your own team to document every gap in the written scope.
Should we compare DataHub before choosing a replacement?
Yes, because DataHub is the other Apache-2.0 catalog teams usually shortlist when leaving Amundsen, and the two have different operating models. DataHub is also Apache-2.0 licensed, and v1.6.0.3 was released on September 25, 2026. Its architecture centers on a metadata service (GMS) with Kafka for streaming metadata changes, MySQL or PostgreSQL storage, Elasticsearch or OpenSearch search, and both push and pull ingestion. OpenMetadata centers on its own server with a database, search and Airflow-based ingestion. Compare the ingestion model your team prefers, whether you want to run Kafka, how much lineage and governance depth you need and who on staff will operate each stack. Review the DataHub releases page as part of that comparison.
How DeployOpen helps choose, implement or migrate a catalog
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a team leaving Amundsen, we start by confirming which Amundsen data you need to carry forward and which OpenMetadata deployment fits your environment.
How we scope
- We confirm which Amundsen tables, dashboards, owners and tags must move, and which can be retired.
- We document the target OpenMetadata deployment, its database and search dependencies, and the Airflow ingestion setup.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We install OpenMetadata in your environment and configure the Amundsen connector with a read-only Neo4j account.
- We review owner mappings so only source owners whose email matches an OpenMetadata user are assigned.
- We rebuild ingestion jobs and validate search, lineage and glossary content against the Amundsen source before cutover.
How we hand over
- We deliver runbooks covering ingestion schedules, connector configuration, access roles and rollback steps.
- We document user guidance for search, glossary terms and governance workflows so teams know where to look.
- We walk your platform and data owners through the cutover record and confirm what was migrated and what was not.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can plan OpenMetadata upgrades, including breaking changes listed in the 2.0 release notes, before they reach production.
- Ask any vendor or DeployOpen contact to confirm current release status and support windows in writing before you commit.
