Migrate from Alation to OpenMetadata

Migrate from Alation to OpenMetadata: what the move involves

The move from Alation to self-hosted OpenMetadata is a re-ingestion plus a curated-content transfer, not a file copy. Your catalog is rebuilt by connecting OpenMetadata to the same warehouses, BI tools and pipelines, then the descriptions, glossary terms, ownership and curation work your stewards produced in Alation are carried over through Alation's APIs. This applies whether your trigger is a renewal, a move away from customer-managed Alation or the cloud service, a data residency rule or a lock-in concern. Each of these reasons leads to the same planning question: what can be exported, and what has to be recreated by hand.

Platform, data and governance teams usually do this work together, often with an implementation partner who handles deployment, connector configuration and content mapping. The platform team owns the hosting decision (OpenMetadata documents production deployment on Kubernetes or on bare metal), the data team owns the source connections and their credentials, and the governance team decides which Alation articles, glossary terms and curation states are worth moving at all. Effort and risk depend mostly on how many sources you connect, how much curated content you have, and how much of it depends on Alation-specific features. Confirm these figures with your own inventory before any quote is requested, since no effort estimate for your environment is supplied here. Alation's export and API surface sets the boundaries of what can move. Its token-authenticated REST APIs return data sources, schemas, tables, columns and custom fields, and articles, glossary and curation state are reachable through the same interfaces, so test each object type on a sample before committing to a plan. Anything Alation exposes only through its interface, or only in a feature set you do not license, may need to be recreated manually. Run the Alation Sink connector in parallel during cutover so that changes made in OpenMetadata are reflected back into Alation while teams still depend on it. Note that the Sink only writes into Alation; the import direction is a separate question covered in the export guide.

Which Alation capabilities map to OpenMetadata, and which need rework

This table maps the main Alation capabilities to OpenMetadata equivalents and labels each as a clean mapping, a needs-rework item or a gap. OpenMetadata lists more than 130 connectors, supports table, column, dashboard, pipeline and metric lineage through OpenLineage events, and offers REST APIs, a Python SDK, TypeScript packages and Java libraries. Confirm each rework and gap item against your own Alation usage before setting migration scope.

Alation capability	OpenMetadata equivalent	Status	What to confirm or plan
Search and discovery	Native search over ingested tables, columns, dashboards and pipelines	Clean mapping	Compare search relevance on your top queries using a sample of re-ingested assets
Usage-driven discovery	Usage and profiling data from connectors and profiler jobs	Needs rework	Confirm which Alation usage signals you rely on and how they are reproduced from source query logs
Lineage	Table, column, dashboard, pipeline and metric lineage, with OpenLineage event integration	Needs rework	Lineage must be re-established by re-running connectors and any OpenLineage producers, then checked against known paths
Glossary	Glossaries with term relationships and assignment to assets	Needs rework	Export glossary terms and definitions from Alation's APIs and map them to OpenMetadata glossary structure
Classifications and tags	Classifications and tags applied to tables and columns	Clean mapping	Map Alation tag and classification names to OpenMetadata classifications before bulk loading
Stewardship and ownership	Owners, domains and data assets organized into domains	Needs rework	Confirm steward roles and approval habits, since workflows may need redesign rather than direct import
Curated articles and descriptions	Descriptions on assets, with the Context Center replacing the Knowledge Center in version 2.0	Needs rework	Extract articles through Alation's APIs and decide which content moves as descriptions and which stays as external documents
Data quality	Data quality tests, profiling and freshness checks	Needs rework	Recreate Alation quality rules as OpenMetadata tests and confirm test coverage per critical table
Sharing and access control	Role-based access and team permissions set in OpenMetadata	Needs rework	Document Alation permissions and map them to OpenMetadata roles and policies, then test access for each group
API access	REST APIs, Python SDK, TypeScript packages and Java libraries	Clean mapping	Confirm which Alation API calls your scripts use, since token handling and endpoints differ
Alation Agent	No direct equivalent in OpenMetadata	Gap	Cloud-only in Alation. Confirm whether your teams need it or whether MCP access in OpenMetadata covers the use case
Microsoft Teams and Slack integrations	Notifications and integrations must be built or configured separately	Gap	Cloud-only in Alation. Confirm which alerts and workflows depend on chat and plan replacements
Chrome Extension	No browser extension equivalent is documented here	Gap	Cloud-only in Alation. Confirm user demand and whether a browser bookmark or search page is sufficient
OAuth 2.0 API authentication	Token-based API access, with sign-in options set in your deployment	Needs rework	Cloud-only in Alation for OAuth 2.0. Confirm how your integrations authenticate before cutover
AWS PrivateLink connectivity	Network access handled by your own VPC and load balancer design	Needs rework	Cloud-only on Enterprise+ plans in Alation. Plan private network paths within your own infrastructure

What data moves, and which integrations you rebuild

Alation holds three kinds of content that behave differently in a move: source metadata that OpenMetadata can read again from the systems themselves, curated knowledge that exists only inside Alation, and integrations that connect the catalog to daily work. Plan each class separately, because each one needs a different extraction or rebuild method.

Source metadata is re-ingested, not copied

Schemas, tables, columns and pipelines should be read again from the warehouses, BI tools and pipeline systems by OpenMetadata's own connectors, which the project lists at more than 130. Re-ingestion keeps lineage and profiling tied to the live source rather than to a snapshot from Alation. Confirm each source's connector, its authentication method and its ingestion schedule in a test environment before you retire the Alation crawl for that source. Expect some Alation-specific tags and custom fields to need manual mapping.

Curated content comes through Alation's APIs

Articles, glossary terms, descriptions, certifications and ownership exist only as curation work inside Alation, so they must be pulled through Alation's token-authenticated REST APIs and mapped into OpenMetadata's glossary, classifications, domains and ownership model. Treat this as a separate workstream with its own validation: compare counts and sample records per object type. Articles often need reformatting, and certification states need an agreed meaning on the OpenMetadata side. Use the export guidance for the payload fields.

Glossary and ownership need a mapping decision

Alation glossary terms, stewards and certified owners do not map one to one onto OpenMetadata's glossary and ownership objects. Decide in advance which Alation roles become OpenMetadata owners, teams or domains, and whether term relationships are kept as written. Record the mapping in a table that stewards sign off before import. Missing owners are the most common reason discovery pages look complete while accountability is unclear.

The Alation import connector is a Collate feature

The connector that imports from Alation belongs to Collate's commercial offering, not to the Apache-2.0 OpenMetadata project. Confirm with Collate whether its licensing and support terms fit your plan before you depend on it for the move. Budget for an open-source path that reads Alation through its APIs if the commercial connector is not approved.

Alation Sink supports coexistence only

The OpenMetadata Alation Sink writes metadata into Alation. It keeps both catalogs aligned during cutover, so analysts can keep working in Alation while stewards validate OpenMetadata. It is not an export path out of Alation, and it will not give you Alation's articles or curation history in a usable form. Plan its use as a temporary sync with a defined end date and a named owner.

Alation integrations must be rebuilt

Slack or Microsoft Teams notifications, the browser extension, BI embeds, SSO configuration and notebook or pipeline hooks each connect Alation to a specific workflow. Alation's documentation lists some of these as available only in Alation Cloud Service, so check which ones your deployment actually uses. Inventory every integration with its owner, then decide whether OpenMetadata provides an equivalent, a custom build is needed, or the workflow is retired. Confirm SSO with your identity provider during the pilot.

How the Alation Sink keeps both catalogs in sync during cutover

The Alation Sink lets you run OpenMetadata and Alation side by side during cutover, but it only moves metadata in one direction: from OpenMetadata into Alation. Plan the overlap around that fact. OpenMetadata ingests the same sources in parallel with your existing Alation setup, so the new catalog is populated and tested while business users keep working in Alation. The Sink then pushes selected OpenMetadata assets into Alation so people who search there see current structure and descriptions. Nothing you change in Alation flows back to OpenMetadata through the Sink, which is why the overlap needs explicit ownership rules.

Before the first sync, the data owners and stewards for each domain should decide which catalog is the system of record for that domain's descriptions, glossary terms, ownership and tags. Write the decision down per domain and name the people who can edit. A common pattern is to keep curation in Alation for domains that are not yet migrated, and to edit in OpenMetadata only for domains that have been cut over. Without this rule, a steward who corrects a description in Alation during the overlap will have that correction silently overwritten or ignored, and nobody will know which version is correct.

Confirm the exact field mapping in a pilot before you rely on it. Ask Alation and the OpenMetadata project which OpenMetadata fields the Sink writes, how it matches assets that already exist in Alation, whether it overwrites or appends to existing descriptions, and how it handles deleted or renamed assets. Run the Sink against a single domain, check the results in Alation's interface and through the APIs, and record what changed. Decide who signs off on that pilot and what result allows the next domain to start. Keep the Sink configuration and the pilot log as part of your migration evidence, and retire the Sink once Alation is no longer used for that domain.

The migration sequence from inventory to decommission

This sequence moves curated Alation knowledge into self-hosted OpenMetadata in controlled stages, so each stage has a written output and the old catalog stays available until the new one is proven. Each step names what is produced and what must be checked before the next one starts.

Pin and test the target OpenMetadata version
Before any data moves, choose one OpenMetadata release, pin it in your deployment definitions, and test it in a non-production environment. OpenMetadata 2.0 introduced breaking changes, including moving embedding credentials into an llmConfiguration block, a new Databricks auth format, rebuilding custom ingestion images for Python 3.12, and migrating Great Expectations to 1.3 before upgrading, so read the 2.0 release notes line by line and check each change against your connectors and custom ingestion code. The output is a signed-off version record and a test environment that has run at least one ingestion from each source type you plan to use. Do not track the latest tag in production, since maintenance releases arrive frequently.
Build the scoped inventory register
Catalog everything that Alation holds for the migration scope: data sources and their connection types, schemas and tables that carry curation, custom fields, integrations such as Slack, Teams or BI links, glossary terms, articles, and the users and groups that own or steward them. Map each source to an OpenMetadata connector and mark any source without one as a gap that needs a custom approach or a decision to leave it behind. Involve data owners and stewards in deciding what is in scope, since much of Alation's value often sits in a small set of heavily curated objects. The output is a scoped register with one owner per source and a documented list of Alation features with no OpenMetadata equivalent, which becomes the basis for the cutover decision later.
Pilot one domain end to end
Choose one business domain with active stewards and re-ingest its sources using OpenMetadata connectors. Extract the domain's articles, glossary terms and curation from Alation's token-authenticated REST APIs, load them into OpenMetadata, and have stewards review the results in the target. Compare object counts, descriptions, ownership, tags and lineage between the two catalogs, and record every mismatch with its cause. The output is a reconciliation report signed by the domain steward, listing what matched, what was transformed, what was dropped and why. Use this report to decide whether the mapping rules are good enough to repeat for other domains, and expect to rerun the pilot after fixing gaps.
Run both catalogs in parallel
Extend the migration to the remaining domains while both catalogs stay live for users. Configure the Alation Sink connector so curation made in OpenMetadata flows back into Alation during this period, which keeps teams that still depend on Alation from drifting. Run scheduled comparisons of object counts and curated fields, and run search and stewardship tests with real users, including discovery queries they use daily and a sample of approval workflows. Confirm which Sink changes reach Alation, and where a field does not sync, record it as a known exception. The output is a parallel-run log with defect counts by category and a list of open exceptions that must close before cutover. Ask the Sink's documentation and your own test results to confirm exactly which objects it writes, since it only writes into Alation.
Freeze edits and cut over
Announce an edit freeze in Alation for the migration scope, then run a final delta extract through the APIs and load it into OpenMetadata. Validate the delta against the parallel-run comparisons, confirm that open exceptions are either fixed or accepted by their owners, and switch single sign-on, bookmarks, embedded links and any Slack or Teams integrations to OpenMetadata. Keep Alation read-only for a rollback window agreed in advance. The output is a cutover checklist signed by the business owner, the data platform lead and the security owner, showing each item, its evidence and its rollback path. Do not start the freeze until the checklist has an owner for every line.
Archive, revoke and decommission
After the rollback window closes without a reversal, export and archive Alation content, including articles, glossary, curation history, custom field definitions and the API extracts used for the migration, to storage your records policy controls. Revoke the API tokens used by the extraction jobs and any Sink credentials, remove the Sink connector, and retire Alation access for users. Confirm with the vendor what the contract and data return terms require before you shut down the instance, whether that is Alation Cloud Service or customer-managed Alation. The output is an archive manifest with checksums, a token revocation record and a written decommission confirmation from the platform owner. Keep the archive for as long as your retention rules require, since the export is the only record of Alation-era curation.

What drives migration cost and duration, and how to hold each down

This table lists the main cost and effort drivers for moving from Alation to self-hosted OpenMetadata, with what each one recurs as and what to request in a written quote. Read it as a checklist for scoping, since the largest variables are usually source count, curated content volume and the number of SSO and integration flows. Minimum sizing figures are starting points, not production sizing.

Driver	Why it changes cost or effort	How to keep it down
Source count and connector coverage	Each Alation data source must be mapped to an OpenMetadata connector or a custom ingestion path. OpenMetadata lists more than 130 connectors, but some older Alation sources may not have a direct match.	Inventory every source in Alation first, check connector coverage per source, and retire unused sources before migration starts.
Volume of curated content and custom fields	Descriptions, certifications, tags and custom fields must be extracted through Alation's APIs and mapped to OpenMetadata fields. Larger volumes raise scripting, validation and review time.	Migrate only actively used curated content, define a field mapping table early, and sample-check results with data stewards.
Lineage depth	Table, column, dashboard and pipeline lineage each need a source of truth. Deep column-level lineage often requires OpenLineage events or query log parsing that must be configured and tested.	Decide which lineage levels are required at cutover, and defer deeper lineage to a second phase.
Integrations and SSO flows	Each identity provider configuration, service account and downstream integration must be rebuilt and tested in the self-hosted environment.	List every SSO and API consumer, group them by pattern, and test one representative flow per pattern.
Governance workflow complexity	Stewardship approvals, glossary terms and domain ownership may need to be redesigned rather than copied, because workflows differ between products.	Document current approval paths, simplify them before migration, and confirm which workflows OpenMetadata 2.0 supports natively.
Self-hosted infrastructure (Kubernetes or bare metal)	Kubernetes on Amazon EKS, Azure AKS, Google GKE or on-premises clusters, or bare metal with Java 21, PostgreSQL 15 or later or MySQL 8.0.42 or later, and Elasticsearch 9.x or OpenSearch 3.x. Minimum sizing is 2 vCPUs and 4 GB RAM for the server, and at least 2 vCPUs, 2 GB RAM and 30 GB storage each for database and search. Production sizing is higher and must be set from your own volumes.	Ask for a sizing estimate based on your source count and content volume, and separate one-time build from recurring cloud or hardware costs.
Staff time for upgrades and operations	OpenMetadata 2.0 introduced breaking changes, including new embedding credential blocks, a new Databricks auth format and Python 3.12 image rebuilds. Each minor release adds regression testing and maintenance work that recurs.	Pin versions, schedule upgrade windows, and read release notes before each upgrade. Ask the quote to state who performs recurring upgrades and at what cadence.

What usually goes wrong, and how to prevent it

Most failed Alation exits are not caused by the target platform. They come from skipped exports, unmanaged parallel editing, and assumptions about how metadata maps between systems. Each card below ties a risk to a step in the sequence so you can check it before cutover.

Curation exported too late

Articles, glossary terms, certifications and stewardship assignments live in Alation, and a connector re-ingest only brings back technical metadata. If you wait until the subscription or instance is switched off to export curated content, you may find gaps you cannot recover. Run a full export of articles, glossary and curation through Alation's APIs in the first phase, store the raw output in a versioned location, and check record counts against what the Alation interface shows before anyone retires the instance.

Divergent edits during the parallel run

While OpenMetadata is being populated, stewards may keep editing descriptions and tags in Alation, so the two catalogs drift apart. The OpenMetadata Alation Sink can push changes into Alation, but it only writes into Alation, so it does not reconcile edits made in OpenMetadata back to the source. Pick one system of record per metadata type, freeze edits on the migrated objects for the cutover window, and set a date after which Alation becomes read-only.

Lineage gaps from unmatched names

Lineage breaks when the name a connector writes for a table, schema or database does not match the name in your lineage source or in your curated records. This typically shows up as orphaned assets and lineage edges that stop at one system. Before cutover, compare fully qualified names for a sample of high-use tables across Alation and OpenMetadata, and confirm that OpenLineage events from your pipelines resolve to the same service and table identifiers.

Custom fields without a clean mapping

Alation custom fields and template attributes do not map one to one onto OpenMetadata's entity model. Forcing them into existing fields can silently overwrite descriptions or tags. Inventory every custom field and the objects that use it, decide for each whether it becomes a glossary term, a classification, a custom property or a documented retirement, and test the mapping on a small set of tables before loading the full catalog.

Breaking changes in OpenMetadata 2.0

OpenMetadata 2.0 moved embedding credentials into an llmConfiguration block, changed the Databricks auth format, requires custom ingestion images rebuilt for Python 3.12, and needs Great Expectations migrated to 1.3 before upgrading. If your ingestion workflows were written for an earlier release, they can fail on the first run after the upgrade. Read the 2.0 release notes, rebuild and test your custom images in a non-production environment, and update configuration before pointing production connectors at the new version.

SSO and access rules rebuilt incorrectly

Alation's group, role and object-level permissions do not carry over automatically. Teams often recreate access by hand, which can leave stewards without edit rights or expose restricted sources to broad groups. Map each Alation group to an identity provider group, define OpenMetadata roles and team ownership from that map, and test sign-in and permissions with one user from each group. Review the OpenMetadata security documentation for the authentication options that match your identity setup.

How the move differs by starting point and team size

If your organization installs and maintains Alation on its own servers, you already control the infrastructure, so the move is mainly about who will run the replacement and how the old instance stays available during cutover. Because you own the host, you can keep the existing Alation instance read-only for a defined period and export from it without depending on a vendor-run environment. The work concentrates on standing up OpenMetadata in your own cluster or on bare metal and deciding how long both systems run side by side.

Keep the source reachable: Confirm that the export account, the API tokens and the database backups can be used while Alation stays online, because your team controls those settings.
Size the target early: Check the OpenMetadata bare metal prerequisites or the Kubernetes sizing against your data volume before procurement, since you will carry the hosting cost directly.
Plan the operating handover: Name the people who will patch OpenMetadata, rotate its credentials and watch its search and database services, because no vendor will do this for you.
Retire the host last: Decommission the customer-managed Alation servers only after reconciliation reports confirm that content matches.

Ask your Alation administrator which version you run and whether the export account can read every data source you need before you commit to a timeline.

Questions teams ask before moving from Alation to OpenMetadata

Can our team migrate from Alation to OpenMetadata without outside help?

Yes, a team with data engineering and platform skills can do much of the work in-house. OpenMetadata is released under the Apache License 2.0, so the software carries no license fee, and its documentation covers production deployment on Kubernetes with Helm charts and on bare metal. The harder parts are re-ingesting sources through OpenMetadata connectors and moving curated content such as descriptions, glossary terms and ownership out of Alation through its APIs. If your staff have not run these tools before, DeployOpen plans, implements and documents this work under a fixed scope agreed in writing before work starts, and can support it afterward under a retainer. Whoever quotes the work should split the price by deployment, connector setup, content migration, cutover testing and upgrades.

What drives the effort and cost of an Alation to OpenMetadata move?

The main drivers are the number of sources to connect, the volume of curated content in Alation, and how many Alation features your users depend on. OpenMetadata lists more than 130 connectors, so each warehouse, BI tool and pipeline you connect adds configuration and testing work. Curated articles, glossary terms, custom fields and access rules all need a mapping decision. Infrastructure is a recurring cost, and its floor is set by the published minimums: 2 vCPUs, 4 GB RAM and 20 GB storage for the server, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. Production sizing will be higher. Your Alation subscription, whether cloud or customer-managed, is the cost that ends at decommissioning. Ask for a quote that lists infrastructure, connector work, content migration and cutover separately.

What skills and staff time does a self-hosted OpenMetadata need?

Running OpenMetadata needs people who can operate Kubernetes or bare metal servers, a supported database and a search engine. On bare metal, the documented prerequisites are Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. Upgrades need attention: the 2.0 release notes list breaking changes, including moving embedding credentials into an llmConfiguration block, a new Databricks auth format, rebuilding custom ingestion images for Python 3.12, and migrating Great Expectations to 1.3 before upgrading. Maintenance releases from 2.0.1 to 2.0.5 arrived about every one to two weeks, so plan a recurring patch cycle. Data stewards also need time to review migrated descriptions and ownership. Confirm which of these skills you already have before you size the staff time.

Is the Alation import connector available in open-source OpenMetadata?

No. The Alation import connector is a Collate feature, so it belongs to the commercial offering from Collate, the company that maintains OpenMetadata and sells managed service, commercial support and premium features. The Apache-2.0 release does not include it. The open-source route is to export your Alation content through its token-authenticated REST APIs and load it into OpenMetadata with the REST APIs, the Python SDK or the connectors you configure. Check the current licensing with Collate before you assume any feature is included, and ask for that answer in writing as part of your planning. Also confirm that the export covers the objects you need, such as articles, glossary terms and custom fields.

Can OpenMetadata and Alation run side by side during cutover?

Yes, the Alation Sink connector lets you push metadata from OpenMetadata into Alation, so Alation users can keep working while teams move. The sink only writes into Alation, so it does not pull Alation content into OpenMetadata. Treat Alation as the source for the initial export, then decide which system owns edits for each domain to avoid conflicting changes. Test the field mapping on a sample before you enable sync for all sources. Confirm with Alation whether running both products together is covered by your current subscription terms, including whether your deployment is Alation Cloud Service or customer-managed. Set a written decommissioning date so the parallel period has an end.

How long does an Alation to OpenMetadata migration take?

The sources for this page do not give a standard duration, so treat any number you hear as a claim to verify. The length depends on how many sources you connect, how much curated content must be moved and checked, how many custom fields and access rules need mapping, and how long your parallel run lasts. Infrastructure build and staff availability also set the pace. Ask for a timeline that is written into a fixed scope with named phases, such as environment build, connector setup, content migration, validation and cutover. A written scope makes it possible to compare offers on the same deliverables.

What should we confirm with Alation about exporting our catalog?

Confirm which export paths your Alation edition supports before you plan the move. Ask which REST API endpoints return data sources, schemas, tables, columns, articles, glossary terms, custom fields and curation, and whether they require token authentication. Check whether your deployment is Alation Cloud Service or customer-managed, because Alation's documentation lists features available only in the cloud service, including the Alation Agent, Microsoft Teams and Slack integrations, the Chrome Extension, OAuth 2.0 API authentication and AWS PrivateLink on Enterprise+ plans. Ask about any rate limits, data retention and the contractual terms for bulk export. Record the answers before the scope is signed, so the export plan matches what Alation actually provides.

How DeployOpen scopes and runs this migration

DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted OpenMetadata inside your own infrastructure, whether that is a Kubernetes cluster in your cloud account, an on-premises cluster or a bare metal estate. The written scope should name each of these pieces for your environment: the deployment target, the database and search services, the connectors you need from your source list, the single sign-on setup, the backup and restore routine, and the upgrade path for the OpenMetadata 2.x line. Ask for each item to be listed as a deliverable with an owner on both sides, because the decisions that most affect the work (which sources are in scope, who curates the glossary, which Alation fields must carry over) belong to your team, not to the implementer.

Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts. For this migration, a useful scope separates three phases. The first is a pilot on a small set of sources and one business domain, used to check connector output, lineage, ownership and glossary terms against what Alation shows today. The second is the cutover plan, which covers how the Alation Sink connector keeps Alation in sync while OpenMetadata becomes the system of record, who signs off each domain, and the rollback point if a source fails. The third is the full load and retirement of the Alation instance. Ask for the pilot exit criteria in writing, and check them against your own data before accepting the cutover date. Ongoing support, upgrades and continuous testing can be added as a retainer after go-live.

DeployOpen prepares systems, controls and evidence for compliance assessments, such as access records, backup test results and configuration documentation, but it does not issue audit reports, attestations or certifications. Those come from independent auditors or certification bodies. If your catalog holds data that falls under a regulatory framework, ask the auditor which evidence they expect before the pilot starts so it is captured during the work rather than rebuilt later. To scope a migration with DeployOpen, request a written scope that lists your Alation deployment type, source systems, curated content volume and target environment, and we will return the fixed-scope proposal in writing.

Migrate from Alation to OpenMetadata