Migrate from Atlan to OpenMetadata: what the move involves
Moving from Atlan to self-hosted OpenMetadata is three pieces of work: extracting the metadata you have curated, rebuilding the connectors and lineage that Atlan currently maintains for you, and cutting over the teams that search, govern and steward assets. If your driver is a renewal, data residency pressure or lock-in, the first decision is which of these you must finish before the Atlan subscription ends, because the extraction is the only part that cannot be rebuilt from your source systems. Most teams carry out this work with an internal platform or data team, usually with an implementation partner for the infrastructure and connector work. Effort and risk are best judged qualitatively at this stage: the risk concentrates in glossary terms, ownership and custom metadata that exist only in Atlan, while connector rebuilds are usually the larger volume of work but the lower risk, since source systems can be re-read.
Plan the infrastructure early because it is the first thing your security and operations teams will review. OpenMetadata documents production deployment on Kubernetes, on Amazon EKS, Azure AKS, Google GKE or on-premises Kubernetes, and on bare metal without Kubernetes, with Docker Compose reserved for evaluation. Its bare metal prerequisites include Java 21 and a supported database and search service, so confirm which target fits your network and skills before sizing anything. Atlan's Self-Deployed Runtime is not a copy of the platform: it is a component that runs in your network to reach sources that cannot be reached from Atlan's cloud. Your OpenMetadata ingestion will therefore need its own network path to each source, credentials managed in your own secrets store, and a schedule that replaces the runtime's job runs. Ask your team to inventory every source that currently uses a Self-Deployed Runtime, since each one needs a rebuilt ingestion route.
Treat the cutover as a team change, not a data change. Decide which Atlan users, stewards and integrations move first, confirm which single sign-on method your identity provider will use with OpenMetadata, and agree a freeze window for glossary edits so nothing is lost between export and import. Keep Atlan read-only for a defined period so that teams can check that owners, descriptions and tags have arrived. Ask any implementation partner for a written scope that names the source inventory, the extraction method, the acceptance checks for glossary and ownership, the lineage rebuild and the rollback plan, because that document, not a generic estimate, is what should drive cost and timing.
Which Atlan capabilities map to OpenMetadata and which need rework
This table compares the Atlan capabilities most teams rely on with their OpenMetadata equivalents and marks each as clean, needs rework or gap. Read the rework rows first, since they set the migration effort. Confirm each item against your own Atlan tenant and a pilot OpenMetadata instance before you commit to a cutover plan.
| Atlan capability | OpenMetadata equivalent | Status and what to confirm |
|---|---|---|
| Asset discovery and search | Data discovery across connected sources, with tables, dashboards, pipelines and metrics | Clean for supported connectors. Confirm that each source you use has a connector in the OpenMetadata release you plan to run. |
| Glossaries and terms | Glossaries with terms, descriptions and relationships | Needs rework. Export terms with pyatlan, then load them with the CSV import. Confirm how term hierarchies and related-term links survive the round trip. |
| Owners and stewards | Owner assignment on tables, columns, dashboards and glossary terms | Needs rework. Map Atlan owner and steward fields to OpenMetadata user or team references. Confirm that every owner exists as a user or team before import. |
| Tags and classifications | Classifications and tags applied to assets and columns | Needs rework. Map Atlan tag names to OpenMetadata classifications. Confirm how propagated tags and tag attributes are handled. |
| Custom metadata and attributes | Custom properties on entity types, which need to be defined before values load | Gap to plan for. Confirm which Atlan custom metadata types have a direct OpenMetadata property and which need a redesign. Values often need a transform step. |
| Lineage | Table, column, dashboard, pipeline and metric lineage, with OpenLineage event integration | Needs rework. Atlan lineage is largely rebuilt by re-running ingestion and lineage collection. Confirm lineage coverage for each source after the first full run. |
| Data quality | Data quality tests, profiling and freshness checks | Needs rework. Test definitions and thresholds do not carry over automatically. Confirm which Atlan quality rules have a matching OpenMetadata test and which must be rewritten. |
| Domains | Domains that group assets and ownership | Needs rework. Confirm how Atlan domain hierarchies map to OpenMetadata domains and whether access expectations need to change. |
| SSO and sign-in | OpenMetadata authentication with OIDC or SAML through your own identity provider | Needs rework. Atlan uses Keycloak for SSO, OIDC and SAML. Confirm the replacement IdP configuration, group mapping and admin roles with your identity team before cutover. |
| APIs and SDKs | REST APIs, a Python SDK, TypeScript packages and Java libraries | Clean for scripted export and sync. Confirm that the pyatlan extraction scripts and any downstream consumers are rewritten against OpenMetadata endpoints. |
What to extract from Atlan and what connectors rebuild
Only a small part of Atlan's metadata needs to leave the platform by hand. The rest is rebuilt when OpenMetadata connectors read the same sources again, so the export effort should focus on curated human-authored content and the rules that govern it.
Choosing between pyatlan and the Java SDK
Atlan documents its Python SDK, pyatlan, and a Java SDK as the programmatic routes, and it does not publish an OpenAPI spec for the platform. Pick one SDK per team and confirm the current package versions and authentication method against Atlan's developer documentation before writing scripts. Ask your Atlan account contact whether any bulk export is available outside the SDKs, since that affects how much of the migration must be scripted.
Glossaries, descriptions, owners and tags
This is the content that cannot be regenerated from source systems: glossary terms and their definitions, asset descriptions written by stewards, owner assignments and manually applied tags. Export these to JSON or CSV with the SDK and keep a dated snapshot. Confirm which assets are human-curated versus inherited from a connector, because only the curated ones need to be carried across.
Custom metadata and classifications
Custom metadata attributes and classification definitions are where migrations usually lose meaning. OpenMetadata has its own custom properties and classifications, so map each Atlan attribute to a target field before loading and decide which ones become tags, glossary terms or custom properties. Flag any attribute that drives access control, since its enforcement must be rebuilt and tested in OpenMetadata rather than assumed.
What connectors rebuild automatically
Table schemas, column metadata, usage, pipeline definitions and most lineage come back when OpenMetadata ingests the same sources, so exporting them from Atlan wastes effort. Lineage should be verified after ingestion rather than copied, since the OpenMetadata connector and any OpenLineage events define its shape. Confirm column-level coverage for each source type in OpenMetadata's connector list before you decide to retire a manual lineage record.
Self-Deployed Runtime connectors become ingestion
Atlan's Self-Deployed Runtime lets connectors reach on-premises or VPC-locked sources from your network, and it holds the credentials for those connections. In OpenMetadata, the equivalent is ingestion run inside your own cluster or runners with credentials in your secrets store. Inventory every SDR-backed source, its network path and its service account, then confirm each one has a working OpenMetadata connector before the Atlan runtime is switched off.
Loading glossaries through CSV import
OpenMetadata's glossary import accepts CSV files, so map the exported glossary terms, parent terms, synonyms, related terms and owners to its column layout in a test environment first. Import into a non-production instance, review term hierarchy and ownership in the UI, then repeat against production. Keep the exported JSON as the source of truth so a failed import can be rerun from the same input.
Migration sequence from inventory to Atlan decommission
This sequence moves curated metadata, ownership and access from Atlan to a self-hosted OpenMetadata instance in your own infrastructure in controlled stages. Each step produces a written artifact that the next step depends on, so cutover is a decision you can verify rather than a single switch.
Inventory assets, glossaries, owners and connectors
Your data platform or catalog team lists every Atlan connection, the sources behind it, and the Self-Deployed Runtime agents that reach on-premises or VPC-locked systems. For each source, record the asset count, the glossary terms, the domains, the owners and the tags that people actually use, and mark which assets are stale. Confirm with Atlan which connectors and runtime versions you run, since OpenMetadata connector coverage differs by source and must be checked one by one. The output is an asset inventory and a connector matrix that names an OpenMetadata connector or a custom ingestion path for each source.
Deploy a pilot OpenMetadata with one or two sources
Your platform engineers stand up OpenMetadata in a non-production environment using the deployment option that matches your standards, such as Helm on a Kubernetes cluster or bare metal with the prerequisites listed in the bare metal documentation. Connect one or two representative sources, ideally one that needs the Self-Deployed Runtime today, and run ingestion end to end. Check that database, search and server sizing meet the documented minimums and that SSO is wired to a test realm. The pilot is done when ingestion succeeds on those sources and the team has written down the sizing and the runbook for a rerun.
Build extraction and mapping scripts
Data engineers use the Atlan Python SDK (pyatlan) or Java SDK to pull glossary terms, descriptions, owners, tags and custom metadata from Atlan into flat files, and write a mapping file that translates each Atlan object type to its OpenMetadata counterpart, including glossary terms, tags, owners and domains. Use the OpenMetadata CSV import for glossaries and review the results in a staging instance before loading production data. Lineage is rebuilt from the sources and through OpenLineage events rather than copied as static links, so keep it out of the mapping file. The output is a versioned mapping file, the extraction scripts, and a load log showing every object that was created, skipped or rejected.
Reconcile and rebuild lineage in parallel
Run both catalogs side by side for a defined review window. Domain owners check a sample of high-use tables, dashboards and glossary terms in OpenMetadata against Atlan, and the team compares counts, owners and tags with a script that writes a reconciliation report listing mismatches. Rebuild lineage by enabling the relevant connectors and OpenLineage integrations, then verify that column-level paths you rely on for audits appear. Record each unresolved gap with an owner and a decision. The output is a signed reconciliation report with every open item closed or accepted.
Cut over SSO, users and access
Identity administrators move user access from Atlan's Keycloak-based SSO to your identity provider integrated with OpenMetadata, and confirm roles, group mappings and API tokens for automation. Communicate the cutover date to data owners, stewards and integrators, and point bookmarks, documentation and any Slack or Teams references to the new catalog. Set a rollback path that keeps Atlan read access available until the sign-off. The output is a cutover checklist signed by the catalog owner, the identity owner and a security representative, covering access tests for each role.
Decommission Atlan and the Self-Deployed Runtime
After the parallel period closes, export a final archive of Atlan metadata and retain it under your records policy. Revoke Atlan API keys and user accounts, remove the Self-Deployed Runtime agents from your network, and close the network paths and firewall rules that existed only for them. Ask Atlan in writing to confirm the contract end date, data deletion procedure and any retained-data terms before the subscription ends. The output is a decommission record listing revoked credentials, removed agents, the archive location and the vendor confirmation of data deletion.
How the migration differs by starting point
Teams with a handful of cloud-hosted sources and a short glossary usually have the simplest move. Most of the value sits in a few hundred curated descriptions, owners and terms, so a single extraction pass with the Atlan Python SDK (pyatlan) and a CSV import of the glossary can cover the bulk of the work. Connector rebuilding is often a matter of configuring the OpenMetadata connectors for the same warehouses and BI tools and running a first ingestion.
- Extraction scope: Export glossary terms, descriptions, owners and tags, and skip anything the connectors will rebuild on their own.
- Glossary load: Prepare one CSV per glossary and check term relationships and owner names before import.
- Connector setup: Point OpenMetadata ingestion at each source directly, without a Self-Deployed Runtime in between.
- Deployment: A single-node Docker Compose trial is enough for validation, but production should run on Kubernetes or bare metal.
- Lineage: Re-run ingestion and compare lineage on a handful of critical tables before retiring Atlan.
Before starting, confirm with your team how many sources and glossary terms are actually in use, because the scale of the work depends on that count.
Teams that have built large volumes of custom metadata attributes, and that run many Self-Deployed Runtime connectors into private networks, face the most work. Custom attributes must be extracted through the SDK and mapped to OpenMetadata custom properties before any import, and each Self-Deployed Runtime connector has to be replaced by an OpenMetadata ingestion pipeline that can reach the same source. Mapping errors in custom metadata are harder to spot than missing descriptions, so validation takes longer.
- Custom attribute mapping: Build a mapping table from each Atlan attribute to an OpenMetadata custom property or field before extracting.
- Connector inventory: List every Self-Deployed Runtime connector, its source and its network path, then plan an ingestion host for each one.
- Credential handling: Move source credentials into your own secrets store and confirm each ingestion job can read them.
- Lineage rebuild: Expect lineage to regenerate from the new connectors, then check gaps against Atlan's history for critical pipelines.
- Parallel running: Run both catalogs side by side for a period so owners can compare results.
Ask your Atlan administrator for an export of attribute definitions and connector configurations so the inventory matches what is live.
Teams whose metadata must not leave their own network start from a different point. Atlan runs as a managed SaaS in its own cloud environment, with only the Self-Deployed Runtime inside the customer network, so the metadata store itself sits outside the site. Moving to OpenMetadata means deciding where the platform runs before anything else, and the answer changes the extraction path, since the export and the target must both be reachable from the environment you control.
- Deployment target: Choose on-premises Kubernetes or bare metal, and confirm the host and storage can meet the stated prerequisites.
- Dependency sourcing: Mirror container images, Helm charts and language packages into your internal registry, because air-gapped hosts cannot pull them directly.
- Extraction path: Run pyatlan from a workstation or host that can reach Atlan during the export, then move the output inside the network by approved transfer.
- Connector reach: Run OpenMetadata ingestion inside the same network segment as the on-premises sources.
- Security review: Document the transfer, storage and access controls for the exported files, and confirm them with your security and compliance team.
Confirm with your security team whether the exported metadata itself is classified, since the transfer method depends on that answer.
Some organizations use Atlan mainly as a shared place where individual domains maintain their own descriptions and certifications. In this case the migration depends less on technical extraction than on who owns each domain and how quickly they can review their content in OpenMetadata. Domain owners need to confirm that their assets, owners and terms landed correctly, and they need a short path to update them after cutover.
- Domain ownership: Assign a named owner for each domain and agree the review sequence before the import.
- Review window: Give each owner time to check their assets, glossary terms and owners in OpenMetadata.
- Access setup: Map Atlan roles to OpenMetadata teams and roles, and confirm SSO through your identity provider.
- Training: Show owners how to edit descriptions and terms in OpenMetadata, since their working habits will change.
- Cutover communication: Announce the date for the Atlan read-only period and the place where changes should be made from then on.
Ask each domain owner which assets they depend on most, so you can verify those first.
What drives migration cost and duration
This table lists the main drivers of effort when moving from Atlan to self-hosted OpenMetadata, with why each one moves cost and what to ask for in a written scope. Read it as a checklist for scoping: the drivers with the widest spread are usually the number of Self-Deployed Runtime sources, custom metadata volume and glossary ownership.
| Driver | Why it moves cost or effort | How to keep it down and what to ask for in scope |
|---|---|---|
| Connectors and Self-Deployed Runtime sources | Each Atlan connector and each source reached through the Self-Deployed Runtime must be rebuilt as an OpenMetadata ingestion pipeline with its own credentials, network path and schedule. | Inventory every source and its runtime path first. Ask the scope to list connectors by source type, network reachability and owner, and to state which ones are out of scope. |
| Custom metadata volume and quality | Custom attributes must be extracted with the pyatlan or Java SDK, mapped to OpenMetadata fields or custom properties, and checked. Sparse or inconsistent attributes add mapping rules and review time. | Decide early which custom attributes are kept. Ask for a field-mapping table as a deliverable and a count of attributes in the scope document. |
| Glossary size and ownership clarity | Glossary terms are loaded through OpenMetadata's CSV import, so every term needs parent, owner, synonyms and description in a consistent format. Terms without a named owner stall review. | Clean terms and assign owners before export. Ask the scope to state how many terms are migrated, who approves the import file, and how duplicates are resolved. |
| Lineage depth and rebuild approach | Lineage is rebuilt through connectors and OpenLineage events rather than copied, so depth of pipelines and column-level requirements determine validation work. | Prioritize the lineage paths that auditors or data owners use. Ask for a written list of lineage paths to validate and the acceptance test for each. |
| SSO, roles and user cutover | Identity integration, role mapping and team-by-team cutover need coordination with the identity team and communication to users. Atlan's SSO uses Keycloak, so the target identity setup needs its own design. | Map existing groups to OpenMetadata roles before build. Ask for the SSO protocol decision, the cutover sequence and the rollback plan in the scope. |
| OpenMetadata 2.0 upgrade and breaking-change work | Version 2.0 introduces breaking changes, including moved embedding credentials, a new Databricks auth format, Python 3.12 ingestion images and a Great Expectations 1.3 migration before upgrade. Each affected connector or pipeline needs testing. | Pin the target version and check the breaking-change list against your connectors. Ask for an upgrade plan covering the version chosen, the test environment and ongoing maintenance releases. |
| Infrastructure sizing against documented minimums | The documented minimum is 2 vCPUs and 4 GB RAM for the server, with at least 2 vCPUs, 2 GB RAM and 30 GB storage each for the database and search services. Production load, number of assets and ingestion frequency push these higher. | Size from the asset count and ingestion schedule, not the minimum alone. Ask for a sizing note for each of the Kubernetes or bare metal targets and the hosting cost owner. |
| Ongoing operation and support | Once live, upgrades, backups, connector maintenance and user support recur. Costs depend on who operates the platform and whether commercial support from Collate is used. | Agree who owns each recurring task. Ask for a written handover, runbooks and a retainer option if support is needed after go-live. |
Cost components: what is one-time and what recurs
Moving from Atlan to self-hosted OpenMetadata changes who pays for what. Today the Atlan subscription covers the platform hosting, upgrades and most operations, while your team pays for the Self-Deployed Runtime hosting and connector upkeep. After cutover, you pay for the OpenMetadata server, its database and its search service, plus the people who run them. The server minimums in the bare metal docs (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) are a floor for sizing, not a production estimate. Ask your infrastructure team to size for your metadata volume, number of sources and high availability requirements, and to price those resources in your own cloud or data center.
One-time work is concentrated in the migration itself: extracting glossaries, owners, tags and custom metadata with the Atlan SDK, loading glossaries through OpenMetadata's CSV import, configuring ingestion for each source to replace the Self-Deployed Runtime connectors, rebuilding lineage, and cutting over SSO and users. Implementation work is usually priced from a written scope, so ask for each item to be listed separately, including validation of owners and lineage against a sample of assets. Training for stewards and data owners is also one-time, but plan for refresher sessions when the OpenMetadata 2.0 features you adopt change. Expect a parallel-run period, which adds temporary infrastructure cost and effort on both sides.
Recurring costs are infrastructure, ingestion scheduling, upgrades and support. OpenMetadata has shipped frequent releases (2.0.0 on August 24, 2026, with maintenance releases through 2.0.5 on October 8, 2026, according to the project's GitHub releases page), and 2.0 included breaking changes that require pre-upgrade work, so budget recurring time for testing each upgrade in a non-production environment. Support is a choice: your own staff can run the platform, or you can buy commercial support and managed hosting from Collate, the company that maintains OpenMetadata and offers those services. Ask Collate and any implementation partner for a quote that separates managed hosting, premium support and project work, and confirm which items are included, what response times apply and which terms cover your data location.
What usually goes wrong in an Atlan to OpenMetadata move
Most failed catalog migrations break at the edges: metadata that did not survive the export, definitions that drift while two catalogs run side by side, and users who never left Atlan. The cards below name the risks that recur in this move and the check that prevents each one.
Lost ownership and classification detail
Owners, tags and classifications often live on assets in ways a flat export does not capture, especially when ownership is set through Atlan personas or propagated through lineage. Before cutover, compare a sample of assets in Atlan against the same assets in OpenMetadata, field by field, and confirm that owner types and classification names match. Treat any mismatch as a blocking defect rather than a cleanup item for later.
Glossary term drift during parallel run
While both catalogs stay live, business users keep editing terms in Atlan, so the OpenMetadata glossary falls behind. Define one system of record for glossary edits from the start of the parallel run, and freeze that glossary for a set window before the final CSV import. Re-run the import against a fresh export and diff term names, definitions and related terms before sign-off.
Lineage gaps after connector rebuild
Lineage in Atlan is built from connector runs and any custom lineage processes your team added. When Self-Deployed Runtime connectors are replaced by OpenMetadata ingestion, lineage captured only by the old connectors or by hand-built processes will be missing. Inventory the lineage edges of your most-used dashboards and pipelines before cutover, then confirm each one appears in OpenMetadata after ingestion and, where you rely on it, through OpenLineage events.
SSO and permission mismatches
Atlan's identity setup, Keycloak-based SSO and its role model do not map one to one onto OpenMetadata's users, teams and policies. Users may log in but see the wrong assets, or be unable to edit glossaries they owned in Atlan. Map each Atlan role to an OpenMetadata team and policy on paper, then test login and read and write permissions with one account per role in a staging instance.
Teams who keep working in Atlan
After cutover, some analysts and stewards will keep bookmarks, Slack alerts and notebooks that point at Atlan, and they will keep editing there. Metadata then splits across two systems and the OpenMetadata copy goes stale. Set a date after which Atlan access is read-only, redirect known links and integrations, and check the Atlan audit or usage data for continued edits in the weeks after cutover.
OpenMetadata 2.0 upgrade breaking changes
OpenMetadata 2.0 moved embedding credentials into an llmConfiguration block, introduced a new Databricks auth format, and requires custom ingestion images to be rebuilt for Python 3.12. Teams that pin older connector images or copy old configuration files will see ingestion fail after an upgrade. Read the 2.0 release notes before installing, migrate Great Expectations to 1.3 first, and rebuild and test each custom image in staging before production.
Questions teams ask before migrating from Atlan to OpenMetadata
How much effort does moving from Atlan to OpenMetadata take?
Effort depends mostly on how much curated metadata you have in Atlan and how many sources you connect. The largest pieces are usually the glossary, ownership and custom metadata, because those are created by people and cannot be rebuilt by a connector. Connector setup and deployment are a separate workload that scales with the number of sources, their access patterns and the network paths between them. Ask any partner to split the estimate into metadata extraction, glossary and custom metadata mapping, connector replacement, deployment, cutover and training, so you can see which part drives the total. No effort figure is stated here because none was supplied for this migration.
How long does an Atlan to OpenMetadata migration typically run?
The timeline is set by the number of sources, the volume of curated glossary terms and custom metadata, how many teams must move over at once, and how much of your SSO and access model must be rebuilt. Teams with a small number of sources and a clean glossary move faster than teams with many Self-Deployed Runtime connectors and inconsistent ownership data. Parallel running, where Atlan and OpenMetadata both serve users for a period, adds time but lowers cutover risk. Confirm the expected duration in writing with your partner or internal lead before work starts, since no duration was supplied as a researched fact for this migration.
What does the migration need from our own team?
You will need a data platform owner who can decide how sources are grouped and who owns each domain, a steward who can review glossary terms and ownership before they are loaded, and someone with access to the source systems so connectors can authenticate. Security or identity staff are needed to configure SSO and role mapping, and whoever runs your Kubernetes or bare metal hosts must be ready to operate OpenMetadata after cutover. Engineers who can run Python scripts against the Atlan SDK will shorten the extraction step. Plan for stewards to spend time on cleanup, because migrated metadata is only as accurate as what was curated in Atlan.
Can our internal team migrate from Atlan to OpenMetadata without a partner?
Yes, a capable internal team can do it, provided it has engineers who can script against the Atlan SDK, operate a Kubernetes or bare metal deployment, and maintain connectors. The main risks for an internal team are underestimating glossary and ownership cleanup, leaving SSO or role mapping until late, and losing lineage that connectors do not rebuild. A partner is useful when the team lacks capacity during the cutover window or needs written scope, testing and hardening evidence. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
Is lineage rebuilt or migrated when we move from Atlan?
Lineage is generally rebuilt rather than copied. OpenMetadata builds table, column, dashboard, pipeline and metric lineage from its own connectors and from OpenLineage events, so the lineage you need should come from re-running ingestion against your sources. Manually curated lineage edges that do not come from a connector or pipeline event must be exported and recreated, which is the part to inventory first. Validate lineage on a sample of critical tables and dashboards before cutover, and confirm with your vendor which lineage types each connector supports in your version.
Can we retire the Atlan Self-Deployed Runtime after the move?
Yes, once every source it reaches is connected to OpenMetadata and its ingestion runs successfully. The Self-Deployed Runtime exists to reach on-premises or VPC-locked sources from Atlan's cloud platform, so it has no role after you stop using Atlan. In OpenMetadata, ingestion runs inside your environment, so you will need network paths and credentials for each source from your own cluster or hosts. Remove the runtime only after a parallel run confirms that metadata freshness and access meet your requirements, and confirm the decommissioning steps with Atlan in writing.
What should we check for security and compliance during the move?
Move the access model first. Map Atlan roles and personas to OpenMetadata roles, configure SSO with your identity provider, and confirm who can edit glossaries, classifications and ownership. Metadata extracted through the Atlan SDK may contain sensitive descriptions or tags, so store exports in a controlled location and delete them once loaded. Review OpenMetadata's security documentation for authentication and transport settings in your version. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.
What a DeployOpen engagement covers for this migration
A fixed-scope engagement for this migration starts with an inventory of what leaves Atlan and where it lands in OpenMetadata. The inventory lists each connector feeding Atlan, each Self-Deployed Runtime host, every glossary, the owner and tag assignments, custom metadata types, and the SSO configuration that teams use today. DeployOpen then writes the extraction scripts against the pyatlan or Atlan Java SDK, produces the glossary CSV files for OpenMetadata's import path, and documents which Atlan-generated objects will be rebuilt by ingestion instead of copied. The scope, deliverables and timeline are agreed in writing before any work begins, and the inventory is the document a client should check first, because it defines what the engagement does and does not cover.
On the target side, the work covers deploying OpenMetadata inside the client's own infrastructure, whether on Kubernetes with Helm or on bare metal, along with the MySQL or PostgreSQL database and Elasticsearch or OpenSearch search service it depends on. Hardening follows the client's security baseline, including identity integration, secrets handling, backups and access roles. Connectors are rebuilt in OpenMetadata to replace the Self-Deployed Runtime jobs, with credentials kept inside the client's network. A parallel run compares the two catalogs source by source, and cutover support covers the switch of teams and bookmarks. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations; independent auditors and certification bodies do that work. Ongoing upgrades, support and continuous testing are available as a separate retainer after cutover.
How DeployOpen scopes, runs and supports the migration
DeployOpen plans, implements, integrates, documents and supports self-hosted OpenMetadata inside your own infrastructure, including the Atlan export, glossary load, connector rebuild and lineage work this migration involves. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory the Atlan glossaries, owners, tags and custom metadata that the written scope will migrate.
- Confirm which sources need Self-Deployed Runtime connectors replaced by OpenMetadata ingestion.
- Agree the target deployment, such as Kubernetes or bare metal, and the teams and SSO cutover order.
How we build
- Extract metadata with the Atlan Python or Java SDK and map it to OpenMetadata glossary CSV import.
- Configure OpenMetadata ingestion connectors, then test lineage and ownership against the Atlan baseline.
- Document each step, including the Python 3.12 and breaking-change checks for OpenMetadata 2.0 upgrades.
How we hand over
- Deliver runbooks for the deployment, connector schedules, backups and rollback steps in writing.
- Walk the operations team through the catalog, its APIs and the ingestion pipelines before cutover.
- Provide a record of what was migrated, what was rebuilt by connectors and what was intentionally left behind.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan upgrades against the OpenMetadata release notes so breaking changes are reviewed before rollout.
- Ask for the support scope, response expectations and upgrade responsibilities in the written quote.
