How to export your catalog from Alation

How to export your catalog from Alation before a move

A renewal, a licensing change, a residency requirement or a lock-in concern usually starts an Alation exit plan, and the export begins with Alation's token-authenticated REST APIs. These return data sources, schemas, tables, columns and custom fields, which together form the structural inventory and the custom metadata your teams have added. Some items need separate handling, so treat the API pull as the backbone of the export and plan additional work for the rest. Before you start, confirm which authentication methods your deployment exposes. Alation's documentation lists OAuth 2.0 API authentication among features available only in Alation Cloud Service, so a customer-managed installation may depend on token authentication alone, and your extraction scripts should match that answer.

Curated metadata goes beyond the structural inventory. Descriptions, glossary terms, ownership and stewardship decisions, and the context carried in articles are the work your stewards are least willing to lose, so list each of these as its own export item before cutover. The Collate connector reads Alation, which means it can bring Alation metadata into OpenMetadata. The OpenMetadata Alation Sink works in the opposite direction and only writes into Alation, so it can keep an Alation instance in sync during a transition but cannot serve as an export path. Confirm with your Alation account team which endpoints return each object type in your version, and document the field mapping before you pull anything.

Test the export on a limited scope first, such as one data source, and compare object counts per schema and table with what the Alation interface shows. Record which items returned complete, which came back empty and which need manual transcription, including any item you cannot find in the API responses. Keep the raw output, the extraction date and the Alation version in your migration file. Your auditors, your security team and the receiving platform team will each ask how the export was made and whether it was complete, and that file is the only evidence they will have.

What Alation exposes through its APIs and how to pull it

This table lists the catalog objects you can pull from Alation's token-authenticated REST APIs, the JSON output each call returns, and the points to confirm before you write an export script. Use it as a checklist against your Alation version's API reference, since endpoints, field names and limits vary by version. The main takeaway is that OAuth 2.0 API authentication is listed as cloud-only, so scripts running against customer-managed Alation need a supported sign-in path confirmed before the export starts.

Object	What to pull	Output and authentication
Data sources	Connection-level records for each catalogued source	JSON from REST calls, token authentication
Schemas	Schema records under each data source, with their parent source reference	JSON, confirm the parent ID field in your version
Tables	Table records with descriptions, owners and tags	JSON, check which curation fields each response includes
Columns	Column names, data types and column descriptions	JSON, expect to page through large tables
Custom fields	Custom field definitions and the values set on catalog objects	Confirm whether values return with objects or need a separate call
Curation objects	Articles, glossary terms and policies linked to assets	Confirm endpoints, as these may sit outside the core object APIs
Authentication	Token-based access for export scripts on customer-managed Alation	OAuth 2.0 API authentication is cloud-only, so confirm the on-premises method
Pagination and rate limits	Paging parameters and request limits for full extracts	Confirm in the API reference, then test a full extract on a copy

What does not come out cleanly and the workaround for each

Alation's documented export path covers data sources, schemas, tables, columns and custom fields, but several things your team relies on sit outside it or depend on the deployment model. Each card names one gap, the workaround that fits it, and what to confirm with Alation before you plan the cutover. Feature availability depends on whether you run Alation Cloud Service or customer-managed Alation, so check both against your own version.

Cloud-only features

The Alation Agent, the Chrome Extension, and the Microsoft Teams and Slack integrations are listed as available only in Alation Cloud Service. If you run customer-managed Alation, these do not exist in your instance, so there is nothing to export from it. Most of their value lies in how people reach the catalog, not in catalog content. Rebuild the entry points in your target tool, such as its own search, browser access and chat notifications. Confirm with Alation whether any of these features store configuration you need to keep.

OAuth 2.0 API authentication

Alation lists OAuth 2.0 API authentication as a cloud-only feature. Scripts that pull metadata through the REST APIs must use the token method your deployment supports, so an extraction script written for one model may not run against the other. Before you build the export, confirm which token method your deployment exposes and whether the API surface differs between the two deployment models. Keep the export scripts in version control so you can rerun them during cutover.

Usage history and popularity

Query counts, popularity rankings and usage-driven ordering shape how people search in Alation, but they are observations collected over time rather than curated content. Expect them to be missing or partial in an export. Recompute usage from the source systems, using query logs from your warehouse and BI tools, and load the result into the target catalog's usage signals. Confirm with Alation whether usage data is available through its APIs and how far back it is kept.

Permissions and access policies

Who can view, edit or approve a catalog object is governed by Alation's roles, groups and object-level permissions. These are tied to Alation's own identity model, so they are unlikely to map one to one into another catalog's roles. Do not copy permissions as raw data. Re-derive them from your identity provider groups and from the access rules of the source systems, then document the mapping. Confirm which user, group and permission endpoints Alation's APIs return and whether they include inherited access.

Workflow and approval state

Open steward tasks, pending approvals and in-flight curation workflows describe work that is still moving. An export captures each object at one moment, and it may not carry the workflow history or record who approved what, which auditors often ask about. Freeze a dated snapshot of open items, record approvals in your own change log, and close or reassign pending tasks before cutover. Confirm with Alation which workflow objects its APIs expose and whether approval history can be retrieved.

Which export path fits your Alation deployment

In Alation Cloud Service, the instance runs on Alation's servers and Alation administers and upgrades it. Alation's documentation calls this the recommended option, and your export runs through the APIs available to that service, including OAuth 2.0 API authentication.

Administration: Alation hosts, patches and upgrades the instance, so your export window follows its release schedule. Confirm the timing in writing.
API authentication: OAuth 2.0 API authentication is listed as available only in the cloud service, so token scripts built for it will not run unchanged elsewhere.
Cloud-only features: The Alation Agent, Microsoft Teams and Slack integrations, the Chrome Extension and AWS PrivateLink on Enterprise+ plans are listed as cloud-only. Inventory which of these hold curated content.
Data location: Your metadata sits in a vendor-hosted environment, so ask your account team how data is retained and returned after termination.

Before you plan the export, check which cloud-only features your teams use and which authentication method your scripts need.

The export sequence and how to verify each stage

This sequence turns Alation's curated metadata into a dated, checksummed archive that you can reconcile against the live catalog before any migration begins. Each stage has a check, so gaps are found while Alation is still available to re-query.

Inventory objects, owners and scope
The catalog owner and an Alation administrator list the data sources, schemas, tables and custom fields in scope, along with the stewards who maintain their descriptions and the teams that rely on them. Record which objects are excluded and why, such as retired sources or test instances. This inventory is the baseline every later count is compared against. It is done when the list is signed off by the owners who will accept the migrated catalog, and when the excluded objects are documented with a reason.
Authenticate with a service token
An Alation administrator creates a dedicated service account and issues a token for the REST API calls, so extraction does not run under a personal login. Confirm the token has read access to every source in the inventory, and check that it can return a known object before running a full extraction. Store the token in your secrets manager, not in scripts or shell history. The check is a test call for one known table that returns the expected name, schema and owner, which shows the permissions are correct for the bulk run. Confirm the exact authentication method for your Alation version with your Alation administrator, since token behavior depends on the deployment.
Extract sources, schemas, tables and columns
Using the token, run scripted calls against Alation's REST APIs to pull data sources, then schemas, tables and columns, paginating through every result set. Keep the responses as returned, without transformation, and record the request time and the endpoint used for each object type. Verify by comparing the number of records per object type against the counts the Alation interface shows for the same sources, and by confirming that pagination ended before the last page was empty. Any mismatch means a page was missed and the run must be repeated.
Extract custom fields and object relationships
Pull the custom field definitions and the values applied to each object, along with the links between objects such as table-to-source and column-to-table relations. Custom fields are often where local curation lives, so capture both the field definitions and their populated values. Verify by selecting a sample of tables with custom field values in the interface, then confirming the same values appear in the extracted JSON for those objects. Record any field type you could not map so it is handled in the reconciliation stage.
Extract glossary and curation content
Export glossary terms, their definitions, linked objects, and the curated descriptions, tags and ownership assigned to tables and columns. Include article content if your team relies on it for context. Check the Alation documentation for your deployment to confirm which of these content types the API returns, because coverage varies, and note any content that must be copied through the interface instead. Verify by counting glossary terms and articles against the glossary view in Alation, then sampling ten or so curated descriptions and comparing the text character for character with the export.
Store raw JSON with checksums
Write each response to a versioned folder with a clear naming scheme, such as one file per object type and extraction date, and compute a SHA-256 checksum for every file. Store a manifest that lists each file, its record count, its checksum and the extraction timestamp. Keep this archive in storage that your retention and access policies cover, with restricted read permissions. The check is re-computing the checksums from the stored files and confirming they match the manifest, which proves the archive has not changed since extraction.
Reconcile counts against the live catalog
Compare the archived record counts, sampled descriptions and custom field values against the live Alation catalog, ideally on a second extraction run made close to the first. Document every difference, classify it as a missing record, a changed value or a deliberate exclusion, and resolve each one before sign-off. Record the reconciliation report alongside the manifest. The stage is complete when the counts match for every object type, the sampled curation text matches, and the owners named in step one have signed off on the report.

How to verify a complete Alation export

An export is only useful as decommissioning evidence if you can show what it contains and what it leaves out. Start by counting records per object type, comparing the totals returned by the REST API for data sources, schemas, tables, columns and custom fields against counts you take from the Alation UI for the same scope on the same day. Record the scope, the date, the API user and the token type used, because a token with narrower permissions will return fewer objects and look like a gap. Where counts differ, trace the difference to a permission boundary, a deleted object, or a source that was excluded from ingestion before you draw any conclusion about data loss.

Field-level spot checks catch problems that counts miss. Pick a sample that covers each object type, including tables with long curated descriptions, columns with tags or classifications, glossary terms linked to assets, and custom fields with unusual data types. For each sampled object, compare the exported values for descriptions, owners, stewards and custom fields with what the UI displays. Hash each exported file (for example, with SHA-256) and keep a checksum manifest listing file names, sizes, hashes and record counts, so the archive can be shown later to be unchanged. Store the manifest separately from the export.

Write a known-exclusions list before you sign off. Confirm with Alation, in your own environment, which items the APIs do not return in the form you need, such as attachments, user-level content, query history, or any feature you use that depends on the cloud service. Each exclusion should name the owner, the reason, and whether a substitute copy exists. Keep the complete package, including exports, the manifest, count reports, spot-check notes and the exclusions list, in your decommissioning record, because auditors and internal reviewers will ask how you proved that nothing curated was lost.

What to plan before the Alation contract renewal or termination

Export is only one part of leaving Alation. The cards below cover the contract and deployment facts that set your timeline, the data and token obligations that govern the extract, and the teams that will notice when cloud-only features disappear. Work through them before you request any export.

Notice window and renewal terms

Check the notice period, auto-renewal clause and end-of-term data return terms in your Alation order form and master agreement. Confirm the exact dates in writing with Alation, because the notice window determines how long you can run a parallel catalog before access ends. Ask whether read-only access is available after termination and for how long.

Current deployment type

Establish whether you run Alation Cloud Service, where Alation operates and upgrades the instance, or customer-managed Alation, where your team installs and maintains it. The answer changes who runs the export, which API endpoints and versions you can reach, and whether your own infrastructure team holds the database backups that may contain metadata.

Data retention and deletion obligations

Map which curated metadata, query logs, user activity and attachments fall under your retention policy, and which must be deleted at exit. Confirm with Alation how it deletes tenant data after termination and request written confirmation. Record what is copied into your new catalog so deletion requests can be answered for every copy, not only the source.

API token ownership and rotation

Identify which service accounts and personal tokens the export scripts use, and who owns each one. Tokens tied to a departing employee can stop working when that person leaves, so move export access to a named service account. Schedule revocation of every token after the final extract and record that revocation as part of the exit evidence.

Cloud-only integrations and dependent teams

List every integration your users rely on, including Slack and Microsoft Teams notifications, the Chrome Extension and the Alation Agent. Several of these are documented as available only in Alation Cloud Service, so they may not carry over. Identify the teams that depend on each one and agree on replacement workflows before cutover.

Parallel run and user communication

Plan a period in which Alation and the new catalog run side by side, with a defined cutover date, a rollback point and a sign-off owner for each domain. Tell stewards, analysts and data owners when their curation work moves and where to edit it. Keep the final export and the comparison of record counts as dated evidence of the transfer.

Questions buyers ask before exporting Alation metadata

Can our own team export Alation metadata without outside help?

Usually yes, provided someone on your team owns the Alation instance and can create API credentials. The export reads curated metadata through Alation's token-authenticated REST APIs, then writes it into files or a staging store that the target platform can load. The technical steps are ordinary scripting work. The judgment work is deciding which curated content is worth carrying over and how each field maps to the new model. Outside help adds the most value in those mapping and validation steps. Start by confirming with your Alation administrator which API functions your deployment exposes.

What makes an Alation metadata export larger or harder?

Scope drives effort more than any single setting. The main factors are:

Object volume: the number of data sources, schemas, tables and columns to read.
Custom fields: each one must be read, mapped to a target field and checked for values that do not carry over cleanly.
Number of data sources: each source type can need its own extraction pattern and validation.
Curation depth: descriptions, glossary terms, tags, owners and lineage notes each add handling and steward review.

Plan a pilot on one data source to measure your own volumes before you size the full run.

What access does an Alation export need from our team?

Your team needs a named service account with API access, not a personal login, and a token that the Alation administrator can create and revoke. The account needs read access to every data source, schema and custom field in scope. A stewardship owner should decide which curated content is in scope, approve the field mapping and sign off on the result. Your security team should review where tokens are stored, how they are rotated and which network paths the export uses. Confirm with Alation which token type your deployment supports, since OAuth 2.0 API authentication is listed among cloud-only features.

How long does exporting Alation metadata usually take?

It depends on scope, and no researched figure gives a duration for this work, so treat any number as provisional until you run a sample extraction. The inputs that set the timeline are object volume, the number of custom fields, how many data sources need individual handling, how much curated content needs steward review and how many validation rounds you expect. The target model also affects mapping work. Ask any provider for a timeline built from a written scope and a pilot result on one data source, and confirm that the plan includes a test run against your largest source.

Can Alation export its own metadata with a built-in tool?

Alation's documentation distinguishes Alation Cloud Service from customer-managed Alation, and it lists features that exist only in the cloud service, including OAuth 2.0 API authentication, the Alation Agent and AWS PrivateLink on Enterprise+ plans. Whether your edition and plan include a bulk export of articles, glossary terms, custom fields and curation is a question to confirm with Alation for your version. Compare anything a built-in tool returns against your own inventory before you rely on it. Alation's deployment comparison is a good starting point for that check.

Does the OpenMetadata Alation Sink move our catalog out of Alation?

The OpenMetadata Alation Sink writes metadata into Alation, so it suits coexistence during a move, where OpenMetadata updates Alation while both systems run. Reading content out of Alation is a separate job. The Collate connector that reads Alation belongs to Collate, the company that maintains OpenMetadata and sells commercial support and AI features. Check the licensing terms for that connector with Collate before you plan around it, and confirm how far it covers articles, glossary terms and curation. Whichever connector you use, your extraction still needs a named owner.

When should we bring in outside help for an Alation export?

Bring in outside help when the object volume is high, the custom fields are numerous or the target model needs design decisions your team has not yet made. DeployOpen plans, implements, integrates and documents self-hosted platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask any provider to state what is excluded and who signs off on the stewardship decisions.

What drives the cost of an Alation export project

The largest cost in an Alation export is usually the discovery work that happens before any script runs. Someone has to inventory what is curated in the catalog: data sources, schemas, tables, columns, descriptions, custom fields, glossary terms, and the stewardship and ownership assignments attached to them. Discovery is driven by how much metadata has been curated over the years and how many custom fields have been defined, so it is the first thing to size. Who pays depends on the model. If your own staff do the inventory, the cost is internal time. If DeployOpen does it under a fixed-scope agreement, the deliverable is a written inventory that you approve before extraction is built.

The second group is scripting and API work, plus validation. Extraction runs against Alation's token-authenticated REST APIs, so the build cost depends on how many object types must be pulled, how custom fields map to the target catalog, and how pagination and rate limits are handled in your environment. Validation is a separate cost: reconciling record counts and sampling curated descriptions in both systems is what proves the export is complete. Ask the implementer whether validation is priced as a separate deliverable with its own acceptance criteria. Recurring costs are minimal for a one-time export, but any re-run before cutover adds the same validation effort again.

The last components are documentation and handover, and they decide whether the export is still usable after the project closes. Ask for a runbook that records the extraction scripts, the token and service account setup, the field mapping, and the known gaps. Confirm with the vendor or your own environment which Alation features your instance uses, because features available only in Alation Cloud Service may not have an equivalent in the destination, and that gap changes the scope. In the written scope, request fixed deliverables for discovery, extraction, validation and handover, named acceptance criteria, and a list of what is excluded, such as ongoing sync or content rewriting.

How DeployOpen scopes and delivers an Alation export

DeployOpen treats an Alation export as a scoped engagement inside your own environment, starting with a written inventory of what must leave Alation and why. We plan, build, test and document the extraction, then hand over the output with the evidence your team needs to verify it.

How we scope

We agree in writing which data sources, schemas, tables, columns and custom fields are in the export.
We confirm which curated content, such as descriptions, glossary terms and ownership, must be retained.
We agree the target format and destination with your team before any extraction work begins.

How we build

We build token-authenticated API extraction scripts against your Alation instance using a service account you approve.
We test extracts against a sample of known assets to confirm completeness and field mapping.
We record the Alation version and endpoints used so the export can be repeated during cutover.

How we hand over

We deliver the exported metadata with a documented schema, mapping notes and a reconciliation report.
We document the run procedure, access controls and how credentials were handled and then removed.
We walk your team through the output so the owners of the target catalog can verify it independently.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Each quote follows from the written scope, so ask us to itemize the extraction, testing and documentation work.

How to export your catalog from Alation