How to export your metadata from Atlan when there is no published OpenAPI spec
If a renewal, a pricing change or a residency requirement is forcing you out of Atlan, the first question is whether your curated metadata can leave with you. The documented route is the pyatlan Python SDK or Atlan's Java SDK, because Atlan publishes no OpenAPI spec that you can generate a client from. Build the export around those SDKs, and treat any direct REST call as something to confirm with Atlan first. Start by listing what your teams actually curated in Atlan, since that list drives every later decision. Glossary terms, descriptions, owners and tags are the metadata people wrote by hand, and no connector can regenerate them.
Curated metadata is the part worth the effort. Glossaries, asset descriptions, owners and tags can be read through the SDKs and loaded into a target catalog such as OpenMetadata or DataHub, both of which support business glossaries and ownership. Technical metadata is a different case. Schemas, table and column names and much of the lineage come back when the new catalog's connectors scan the same sources, so exporting them from Atlan adds work without adding value. Confirm which of your assets come from Atlan's own connectors and which were created by hand, because hand-made assets and custom metadata are the items that must be carried over explicitly.
Before you run the first extraction, ask Atlan in writing which export methods are available on your tenant, which request limits the SDKs run into, which entity types are covered and how custom metadata is returned. These limits are tenant-specific, so this page cannot state them. Run a pilot export on one domain, load it into a test instance of your target catalog and compare counts and owners against Atlan. Keep the raw output as a dated archive, since it becomes your record of what Atlan held at cutover. The Atlan architecture documentation explains where each component runs, which helps you plan the exit window.
What metadata you can export from Atlan with pyatlan
This table lists the metadata types a team usually needs to take out of Atlan and how each one is extracted with the pyatlan SDK. Read each row as a checklist: confirm the method and limits for your own tenant before you schedule a full extraction. The main takeaway is that curated metadata is exported through the SDK in your own script, while connector-rebuilt metadata is usually not worth moving.
| Data type | Export method | Output format | Limits to confirm |
|---|---|---|---|
| Glossary terms and categories | Extracted through the pyatlan SDK by querying glossary and category assets | Structured SDK objects written to JSON or CSV by your script | Page sizes and maximum payloads per request with Atlan documentation or support |
| Asset descriptions | Extracted through the pyatlan SDK from asset attributes such as user description | Structured SDK objects written to JSON or CSV by your script | Rate limits for bulk reads on large asset counts |
| Owners | Extracted through the pyatlan SDK from ownership attributes on each asset | Structured SDK objects written to JSON or CSV by your script | Whether owner groups and users resolve to identifiers you can map |
| Tags and classifications | Extracted through the pyatlan SDK from classification assignments | Structured SDK objects written to JSON or CSV by your script | Propagation settings and how inherited tags appear in the output |
| Domains | Extracted through the pyatlan SDK from domain and data product assets | Structured SDK objects written to JSON or CSV by your script | Nested domain hierarchy depth and how it is returned |
| Custom metadata | Extracted through the pyatlan SDK from custom metadata sets on each asset | Structured SDK objects written to JSON or CSV by your script | Field types and the size of values held in each custom attribute |
What does not export from Atlan and how to rebuild it
Not everything in Atlan is worth moving. Some metadata is derived from sources and comes back when connectors re-run, some is tied to Atlan's own runtime and identity layer, and some may not be exposed through the SDK at all. Sort each item into one of these groups before you plan the export, so the target catalog is populated from the right place.
Source-derived schemas and lineage
Table and column structures, lineage and usage statistics are read from warehouses, BI tools and pipelines. Re-exporting them from Atlan copies stale snapshots, and the target catalog will rebuild them more accurately. Point the target's connectors at the same sources, run a full ingestion, and compare row counts for a few key assets. For OpenMetadata, use its connector ingestion. For DataHub, use its more than 150 integrations, including column-level lineage. Only export curated fields such as descriptions, owners and tags.
Self-Deployed Runtime configuration
The Self-Deployed Runtime runs inside your network to reach on-premises or VPC-locked sources, and its connector credentials and agent settings are held in Atlan's configuration rather than in the metadata itself. These values do not travel with a glossary export. Inventory each runtime connection, the source account it uses and the network path it needs. Then create equivalent credentials in the target, and rotate any secret that was shared with Atlan's tooling during the migration.
Identity and SSO configuration
Atlan uses Keycloak for SSO, OIDC and SAML, so user accounts, group memberships and login federation sit in that layer. Exported owner fields usually carry only usernames or emails, not authentication state or role assignments. Recreate SSO in the target by configuring its OIDC provider, then map group claims to the target's roles. For DataHub Core, the operator configures the frontend server directly, so plan that step before cutover.
Policies and access rules
Access controls, masking rules and any policy objects configured in Atlan are often modeled differently from catalog metadata, so they may not appear in a standard SDK extract. Do not assume they will export cleanly. Ask Atlan which policy objects your tenant uses and whether the SDK returns them. Then write the equivalent rules in the target, and test them with a sample user before any team relies on them.
Custom metadata and SDK coverage
Custom metadata, announcements and some UI-only content may be stored in forms the pyatlan SDK does not expose in full. Before you write the extraction script, list every custom attribute type in use and test each one against a non-production tenant. Record any object the SDK skips, then confirm the gap with Atlan in writing. Plan a manual rebuild for those items rather than assuming the export captured them.
Usage history and audit trails
Query history, user activity and audit logs show who used an asset and when. These records are operational data tied to Atlan's platform, and their retention and export options vary by plan. Ask Atlan which activity records you can retrieve and for what period. If the history is not available, start collecting usage in the target from its first ingestion run, and keep Atlan's records for compliance review under your own retention policy.
Export sequence from Atlan with verification at each step
This sequence turns an Atlan tenant into a dated, checksummed set of curated metadata files that a catalog owner can review before any import. Each step closes with a check, so gaps in scope, access or record counts are caught before the next step starts. It covers glossaries, descriptions, owners and tags, and leaves out metadata that connectors rebuild on their own.
Inventory the tenant and fix the export scope
A catalog owner works with an Atlan administrator to list the asset types, glossaries, domains, custom metadata fields and tags in the tenant, and to record which sources hold curated content. Connector-driven fields such as technical schema and lineage are usually rebuilt by ingestion in the target catalog, so they go on an exclusion list unless the team has a reason to keep them. Record the counts per type from the Atlan UI in a dated scope sheet. Check: the data governance lead signs the scope sheet, and every type in it has a recorded count before any credentials are issued.
Create a read-only service identity
An Atlan administrator creates a service identity or API credential for programmatic access, using the method Atlan documents for SDK use. Confirm with Atlan which role or permission set can read glossaries, assets, tags and owners without write access, and confirm how tokens expire and rotate. Store the token in a secrets manager and keep it out of scripts and repositories. Check: the permissions shown for the identity match the scope sheet line by line, and a test call with the pyatlan client returns the expected tenant without any write permission being granted.
Run read-only extraction into versioned files
An engineer runs an extraction script using the pyatlan client or the Atlan Java SDK, pinned to a specific SDK version. The script pages through glossaries, terms, asset descriptions, owners and tags, and writes JSON or CSV files into a version-controlled folder. File names carry the export date, tenant name and SDK version. The script logs each page requested, the number of records returned and any errors. Check: the run finishes with no unhandled errors, the log shows every page of every in-scope type, and the run is tagged with an identifier for later reference.
Validate counts and sample records against Atlan
The engineer compares the record count for each type in the output with the counts in the scope sheet. A reviewer who knows the catalog then picks a sample of assets and glossary terms and compares descriptions, owners, tags and glossary links in the Atlan UI with the exported files. If Atlan content changes during extraction, note the timestamp of the change and rerun the affected types. Check: counts match the scope sheet or each difference has a documented cause, and the reviewer signs off on the sample before the files are treated as final.
Archive the output with checksums
The engineer computes a SHA-256 checksum for each exported file and writes a manifest listing file names, record counts, checksums, SDK version, tenant name and export timestamp. The files and manifest move to an access-controlled storage location under the organization's retention policy. Access to the archive is limited to the people who will run the mapping work. Check: a fresh download from the archive produces checksums that match the manifest, and only after that check passes does the team start mapping the output to OpenMetadata or DataHub.
Mapping exported Atlan metadata to OpenMetadata or DataHub
OpenMetadata models glossary terms, owners, tags, descriptions and domains as first-class objects, so most fields in an Atlan export have a place to land. Glossary terms suit the glossary CSV import, while owners, descriptions and tags can also be written through the REST APIs or the Python SDK that OpenMetadata provides for programmatic access.
- Glossary terms. Export Atlan glossary terms with their parent categories and related terms, then load them in hierarchy order so parent terms exist before their children. Store the Atlan qualified name in a custom property or in the description so each term can be traced back to its source.
- Owners. Match Atlan users and groups to OpenMetadata users and teams before loading. Owner references fail when the target user or team does not exist, so create the teams first.
- Tags and classifications. Atlan tags usually become OpenMetadata classification tags. Decide whether Atlan tag hierarchies become nested tags, and where any tag that carries attribute values should be stored.
- Descriptions. Descriptions map to the description field on terms and assets. Check how Markdown formatting survives the load, because long Atlan descriptions often contain it.
- Domains. Map Atlan domains to OpenMetadata domains, then confirm how your release assigns domains at the asset level before bulk loading.
Confirm the current CSV columns and API payloads against the release notes for the exact OpenMetadata version you install, then test the load on a scratch instance.
DataHub expresses glossary terms and domains through its business glossary and domain objects. These can be defined in YAML files or created through its APIs and Python SDK. Owners, tags and descriptions attach to datasets, columns and glossary terms as metadata, so the migration is usually a scripted step that reads the Atlan export and writes DataHub metadata, not a single file import.
- Glossary terms and nodes. Atlan glossary categories become glossary nodes and terms become glossary terms. A YAML business glossary keeps this source under version control, so changes can be reviewed in a pull request before they reach the catalog.
- Domains. Create DataHub domains before assigning datasets to them. Decide whether Atlan sub-domains become nested domains or separate domains, because the choice changes how teams browse the catalog.
- Owners. Map Atlan owner roles, such as data owner or steward, to the ownership types defined in your DataHub instance. Confirm the available ownership type names in the version you deploy.
- Tags and descriptions. Tags attach to datasets and columns, and descriptions can be set on entities and fields. Column descriptions only land when the dataset and column names in the export match the DataHub names exactly, so normalize them first.
- Ingestion-owned metadata. Schemas, lineage and usage come from DataHub's own connectors. Export only the curated fields, so the migration does not duplicate what ingestion rebuilds.
Confirm the YAML glossary schema and ownership type names in your DataHub release against the Kubernetes deployment guide, and test with one domain before loading the whole estate.
Some Atlan fields have no direct counterpart in either target, so the team must decide how to carry each one before import. Dropping them silently loses audit context, so every field should have a documented outcome, even if that outcome is to retire it.
- Custom metadata. Atlan custom metadata attributes are structured fields your organization defined. Map each attribute to a custom property or a tag in the target, and record the mapping in a table.
- Certification status. Atlan's verified or certified state has no guaranteed one-to-one field in either platform. Choose between a tag, a glossary status or a custom property, and write down the rule for applying it.
- Announcements and READMEs. Long-form notes may fit a description or a linked document. Decide whether to copy the text or keep a link back to the original source.
- Access policies and personas. Atlan enforces its policies inside Atlan. Neither target copies them automatically, so access control must be designed again in the target and in your identity provider.
- Usage and popularity signals. These values are recalculated by the new platform's ingestion. Do not import historical values and present them as current facts.
Assign an owner to each decision, review the table with data owners, and sign off before the first production import.
How to prove the Atlan export is complete before cutover
Completeness means four checks pass, not just that the export file exists. First, object counts must match per asset type: tables, columns, dashboards, glossary terms, domains and tags should each be counted in Atlan through pyatlan and again in the target catalog after ingestion. Second, a sample of assets must carry the same owners, tags and descriptions in both systems. Pick the sample deliberately: include assets with custom metadata, assets with lineage, and assets owned by teams that changed recently. Third, every glossary term needs a documented destination in OpenMetadata or DataHub, or a recorded decision to retire it. Fourth, connector-generated metadata such as schemas and usage should be confirmed as rebuilt by the new ingestion, not copied, so that the comparison does not count the same fact twice.
Sign-off should be split by ownership, and each approver should see a defined set of evidence. Data owners confirm that their domains' descriptions, owners and tags are present and correct. The governance lead confirms that glossary and classification coverage matches the agreed scope. The security team confirms that access-related metadata, such as sensitivity tags and restricted-asset markings, arrived intact and is not exposed to users who could not see it in Atlan. Keep a written exception log with the asset, the gap, the reason, the approver and the planned fix. An open exception with a named owner is acceptable at cutover; an undocumented gap is not.
Keep the exported archive under your retention rules after the contract ends. Export files and the pyatlan scripts that produced them are records of what the catalog said at a point in time, and they may be needed for internal review, dispute resolution or a later assessment. Confirm with legal and records management how long they must be kept, where they are stored, and who can access them, then check that the archive is covered by the same backup and access controls as the new catalog. Ask Atlan, in writing, how it will handle your data after termination and for how long it retains it, and record the answer in the migration file alongside the export.
What to plan before the Atlan contract renewal or termination
Most of the work in leaving Atlan is decided by contract terms and calendar dates, not by tooling. The cards below cover the decisions to settle before the notice date, so the export, the parallel run and the shutdown of Atlan's Self-Deployed Runtime do not depend on last-minute negotiation. Check your own agreement and notice period, since these vary by contract and this page does not assume any particular terms.
Confirm export methods in writing
Ask Atlan, in writing, which export paths your subscription includes, how large an export can be, how often you can run it, and whether the SDK calls are limited by API quotas for your tenant. Treat pyatlan scripts as a working method you still need to verify against your own volume. Record the answers in the contract file so the exit plan rests on documented terms, not on a sales conversation.
Agree data return or deletion terms
Read the clauses on customer data return, export format, deletion timing and certification of deletion. Confirm whether metadata, lineage, usage history and custom attributes are all covered, and whether Atlan retains backups after termination. Make the return format and delivery date a signed commitment, because a catalog export that arrives late or incomplete will delay every team waiting on the new platform.
Set the parallel-run period
Plan a period where Atlan and the new catalog run side by side, with the same sources ingested into both. Use it to compare glossary terms, owners and tags against a sample of assets that business users rely on daily. Agree the length of the overlap with your business owners and make sure it ends before the contract term, so you are not paying for a catalog nobody is using.
Plan Self-Deployed Runtime shutdown
Inventory every source that reaches Atlan through a Self-Deployed Runtime, including on-premises databases and VPC-locked systems. For each one, decide whether the replacement ingestion runs in your network, record its credentials and network paths, and schedule the runtime shutdown only after the replacement has produced verified metadata. Keep firewall and service account changes in the same change record so access is removed cleanly.
Inform glossary and SSO users
Identify the teams that edit glossary terms, certify assets or sign in through Atlan's identity setup, and notify them of the cutover date. Plan the replacement of SSO for the new catalog, including how OIDC or SAML trust is configured, and confirm which group memberships map to which roles. Users who own glossary content should review the migrated terms before the old tenant closes.
Schedule the final export archive
Run the final export close to the end of access, store it in a controlled location with an access log, and set a retention date that matches your records policy. Keep a checksum of each file, document which Atlan version and date produced it, and confirm with your compliance lead whether the archive must be kept for any regulated period. Verify that the archive can be opened and read before you cancel access.
How much effort and cost does an Atlan metadata export take?
How long does an Atlan metadata export take?
No duration is published in the material available for this page, so the honest answer depends on your tenant. The main drivers are the number of assets you want to carry over, how many glossary terms and custom metadata attributes exist, and how consistent owners and tags are. A small tenant with clean glossary entries is a much shorter job than a large estate where descriptions and ownership are patchy. Ask any provider to estimate the export separately from the mapping and re-ingestion work, and to explain which assumptions the estimate depends on.
What does the export need from our Atlan admin team?
It needs an admin to provision an API credential with read access to the objects you plan to extract, and to confirm which workspaces, domains and glossaries are in scope. Data owners should review the exported glossary, descriptions, owners and tags before they reach the new catalog, because the export reflects what is in Atlan today, including stale or contradictory entries. Plan this review time in advance, since it is usually the step that waits on people rather than on code.
Can our engineers do the Atlan export in-house with pyatlan?
Yes, a competent Python engineer can script an export with pyatlan, the Python SDK Atlan points developers to, provided they have API access and time to read the SDK documentation and test against a sample. The harder part is rarely the extraction itself. It is deciding which objects are curated and worth moving, handling custom metadata, and producing output that the target catalog can import without losing meaning. Many teams keep the extraction in-house and hire help for the mapping and validation steps.
Which cost components apply to moving metadata out of Atlan?
The cost has several parts, and each is paid to a different party:
- Internal engineering time to write and run the extraction and to review results.
- Implementation fees if you hire a provider to map glossaries, domains and custom metadata to the target model and re-ingest sources.
- Target infrastructure for OpenMetadata or DataHub, which recurs every month as compute, storage and search capacity.
- Staff time for owners who validate content.
The extraction is mostly one-time. Hosting, upgrades and the people who run the catalog recur.
What drives the cost of the migration up or down?
Cost moves with how much curated metadata you actually keep, how many custom attributes need translation, how many connectors must be rebuilt from Self-Deployed Runtime into the new platform, and how many teams must cut over. Clean owners and tags lower the effort, and a short list of retained glossary terms reduces review time. Anything you decide not to export, such as metadata that connectors rebuild automatically, reduces scope without losing information.
What should we ask for in a written scope before hiring help?
Ask for a written scope that lists the exact objects to extract, the target platform and version, the mapping rules for glossaries, domains, owners, tags and custom metadata, and the validation method. Require a list of deliverables, the acceptance criteria, the responsibilities of your admins and data owners, the test environment, and the cutover plan. Also ask how credentials are handled, where extracted files are stored, and how they are deleted afterward. DeployOpen works from a fixed scope agreed in writing before work starts, and a quote follows from that scope.
Do we need to export connector metadata that Atlan can rebuild?
Usually not. Connector-derived technical metadata, such as schemas and table structures, is typically rebuilt by re-ingesting the source systems in the new catalog, so exporting it adds cost without adding value. Focus the export on human-curated content: glossary terms, descriptions, ownership, classifications and tags. Confirm this against the specific objects in your tenant, because some custom attributes may hold information that connectors cannot recreate.
How DeployOpen scopes and delivers an Atlan metadata exit
DeployOpen plans and delivers the metadata export from Atlan as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. The work runs inside your own infrastructure, so extracted glossaries, owners and tags stay under your control from the first extraction run.
How we scope
- Inventory which glossaries, descriptions, owners and tags in your Atlan tenant must move, and which connector-derived metadata can be rebuilt instead.
- Confirm with your Atlan administrators which API credentials, SDK versions and Self-Deployed Runtime connections the export depends on.
- Agree the target platform, OpenMetadata or DataHub, and the written deliverables before any extraction begins.
How we build
- Write pyatlan extraction scripts that pull glossary terms, asset descriptions, owners and tags into structured files for review.
- Map exported fields to the target model and test a sample export against a non-production instance of the chosen catalog.
- Run validation checks comparing record counts and ownership assignments between the Atlan export and the imported catalog.
How we hand over
- Deliver the extraction scripts, mapping tables and import procedures with documentation your engineers can rerun independently.
- Document which metadata was intentionally excluded and why, so reviewers can confirm the decision before cutover.
- Walk your platform and data governance teams through the runbook and record the handover in the agreed deliverables.
How we support
- Ongoing support, upgrades and continuous testing of the target catalog are available as a retainer after handover.
- Ask whether a retainer should cover upgrades to the target platform, such as OpenMetadata or DataHub releases that change schemas or APIs.
- Confirm with your team which Atlan SDK or API changes require script updates before the subscription ends.
