Atlan cost vs self-hosted open-source catalog

Atlan cost vs a self-hosted open-source catalog: where the money goes

If your Atlan renewal is coming up and the number on the quote is larger than expected, the useful question is what that subscription is actually buying. The short answer is that an Atlan subscription bundles hosting, upgrades and day-to-day platform operation into one recurring fee. Atlan describes itself as a cloud-first, single-tenant SaaS platform hosted on AWS, Azure or Google Cloud, and customers can run only a Self-Deployed Runtime in their own network to reach on-premises or VPC-locked sources. Self-hosting an open-source catalog moves those same functions to your side of the table: infrastructure, implementation and migration, and the people who operate the catalog. This page does not give a subscription price. Obtain Atlan's written quote and ask for it to list every component it covers, including the Self-Deployed Runtime, support tier and any upgrade or hosting charges.

Both candidate platforms are released under the Apache License 2.0, so the software itself carries no license fee. OpenMetadata is maintained by Collate, which also offers managed service, commercial enterprise capabilities and premium support. DataHub is maintained by the company behind DataHub Cloud. In both cases, the costs you will carry are infrastructure, implementation, upgrades and staffing. Infrastructure is the most measurable. OpenMetadata's bare metal documentation lists a minimum server of 2 vCPUs, 4 GB RAM and 20 GB storage, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. Those are minimums, not production sizing. For DataHub, its Docker quickstart requires 8 GB of RAM, and its Kubernetes guide says more than 7 GB is needed to run DataHub and its dependencies on Minikube. Production sizing for Kafka, Elasticsearch and the database will be far larger, so ask your platform team to size it against your asset count and query load.

Treat the open-source route as a one-time build cost plus a recurring operating cost. Implementation and migration are largely one-time, covering connector setup, glossary and ownership migration, SSO and cutover. Upgrades recur: DataHub's Helm chart runs a system-update job to apply schema changes and reindex search, and OpenMetadata 2.0 introduced breaking changes, including new embedding credential and Databricks auth formats and a Python 3.12 rebuild of custom ingestion images. Those upgrades need a named owner. Ask your Atlan account team in writing what it would cost to renew with the Self-Deployed Runtime only, what support and upgrade work is included, and what exit assistance it offers. Then build a comparison that prices your own infrastructure, implementation, and the operating hours of the engineers who will run the catalog.

Which cost components change between Atlan and self-hosting

This table compares each cost component of an Atlan subscription with Self-Deployed Runtime hosting against running OpenMetadata or DataHub yourself. Read the one-time and recurring columns first, because most of the difference sits in people time and migration work rather than software licenses. Both open-source projects carry no license fee, so the decision turns on who operates the platform.

Cost component	Atlan side	Self-hosted side (OpenMetadata or DataHub)	One-time or recurring
Software license or subscription	Annual or term subscription to the hosted platform, priced by Atlan under your contract	Zero license fee for Apache-2.0 OpenMetadata and DataHub Core; paid options are Collate and DataHub Cloud	Atlan: recurring. Self-hosted core: none
Hosting infrastructure	Atlan hosts the platform on AWS, Azure or Google Cloud, so you carry no core compute	Kubernetes or bare metal capacity, plus database and search services; DataHub also needs Kafka and a graph index	Self-hosted: recurring cloud or data center spend
Connector runtime	Self-Deployed Runtime runs in your network to reach on-premises or VPC-locked sources	Ingestion runs as part of your deployment, scheduled and monitored by your team	Recurring compute and staff time
Implementation and setup	Configuration by Atlan onboarding and your admins	Deployment, SSO, connector configuration and lineage setup, delivered in-house or by a fixed-scope partner	One-time
Migration of existing metadata	Export of glossaries, owners and tags is possible through Atlan's SDKs, with your own effort	Import of exported metadata and rebuilt lineage into the new catalog, with validation by data owners	One-time
Upgrades and maintenance	Atlan performs platform upgrades as part of the service	Your team plans and tests releases; DataHub's Helm chart runs a system-update job on upgrade, and OpenMetadata 2.0 has documented breaking changes	Recurring
Support	Vendor support included in the subscription tier you buy	Community support for open source, or a paid support contract from Collate or DataHub Cloud, or a retainer with an implementation partner	Recurring if contracted
Internal skills and operations staff	Smaller admin role, focused on configuration and access	Platform engineers for Kubernetes, databases, search, Kafka (DataHub), backups, SSO and on-call	Recurring; the largest driver of total cost

What moves the comparison up or down

The gap between an Atlan subscription plus Self-Deployed Runtime and a self-hosted OpenMetadata or DataHub moves with a handful of inputs. Each driver below changes either the infrastructure bill, the operating workload or the vendor fees, so check them against your own estate before comparing totals.

Number of sources and connectors

Every source you connect adds an ingestion schedule, credentials to rotate and a connector version to keep current. With Atlan, connectors that reach on-premises or VPC-locked systems run in the Self-Deployed Runtime inside your network, so that footprint grows with the source count. With OpenMetadata or DataHub, each connector runs in your own ingestion environment, which adds compute and an owner for each pipeline. Count sources by network zone, not only by total, because each zone may need its own runtime.

Metadata volume and profiling frequency

Large table and column counts, frequent crawls and heavy profiling drive search index size, database growth and compute time. Profiling is the usual surprise: sampling every table on a short schedule costs more in warehouse queries and cluster hours than metadata harvesting alone. Ask Atlan how its consumption and runtime charges scale with asset counts, and size the search and database nodes for your own asset count and crawl schedule.

Number of users and SSO integrations

Named seats are a recurring line in a SaaS quote, while a self-hosted catalog is usually priced by the infrastructure that serves them. Adding users is cheap on open source, but wiring SSO is not free: DataHub Core needs the operator to configure OpenID Connect on the frontend, and each identity provider adds a test and support path. Confirm with Atlan how it prices seats and whether SAML and OIDC are included in your tier.

Availability expectations and on-call coverage

A vendor uptime commitment shifts the risk of outages to the vendor, and that commitment should be priced into the comparison. A self-hosted catalog moves the same risk to your team, so you need an on-call rota, tested backups and a tested upgrade path for Kafka, the database and the search tier where the platform depends on them. Ask Atlan for its contractual availability terms in writing, then compare them with the staffing you would really commit to the catalog.

Edition choices such as Collate or DataHub Cloud

If the open-source core lacks features you need, a commercial edition from the project's company changes the calculation. Collate offers managed OpenMetadata, commercial support and AI features, and DataHub Cloud adds data quality monitoring, compliance forms, access request workflows and an SLA. Each option turns part of the self-hosted cost into a subscription, so decide which features are required before you compare totals. Get each edition's feature list and terms in writing.

Skills already on the team

The largest variable is often the people. A team that already runs Kubernetes, Helm, Elasticsearch or OpenSearch, and Kafka can absorb a DataHub deployment with modest added effort. A team without those skills should price training, hiring or a support contract into the self-hosted side. Also count the staff time for upgrades, since DataHub's Helm chart runs a system-update job on upgrades and OpenMetadata 2.0 includes breaking changes that need planning. Be honest about who would own the catalog after launch.

How to build the comparison with your own numbers

This sequence turns the cost categories on this page into a three-year comparison built from your source inventory, Atlan's written terms and your own rates, so the result reflects your environment rather than general estimates.

Inventory every metadata source and connector
Start by listing each system the catalog must read from: warehouses, BI tools, transformation jobs, pipelines, ML platforms and any source that sits in a VPC or on-premises network. For each one, record its type, where it runs, who owns the credentials and how often metadata must refresh. Mark which sources need the Self-Deployed Runtime in Atlan and which can be reached directly. The step is done when a single table lists every source with its network location and owner, and your data platform lead has signed off on it.
Request Atlan's written quote and runtime footprint
Ask Atlan for a written subscription quote that states the licensed scope, user count, connector count, included support tier, and any fees that apply to the Self-Deployed Runtime. In the same request, ask for the Self-Deployed Runtime's hardware or cloud footprint, its update process and what you must operate yourself. Ask whether the quote covers renewal uplifts across the three-year window. The step is done when you hold a dated document you can cite line by line in the model.
Size the open-source catalog against published minimums
Use the published minimums for OpenMetadata and the Kubernetes guidance for DataHub as the starting floor, not the target. For OpenMetadata, the bare metal documentation lists minimum server, database and search sizing; for DataHub, the Kubernetes guide lists its main components and their dependencies. Add headroom for your source count, search volume and retention, and plan separate production, staging and disaster recovery environments if your policy requires them. The step is done when you have a sized architecture diagram and a list of cloud resources with their monthly price taken from your own cloud provider's calculator.
Price infrastructure and staff time from your own rates
Convert the sizing into recurring infrastructure cost using your cloud contract or on-premises hardware depreciation. Then estimate the staff hours needed to operate the stack each month: Kubernetes or host patching, connector maintenance, upgrade rehearsals, backups, access reviews and on-call coverage. Price those hours at your fully loaded internal rate. Keep the estimate in your own spreadsheet with its assumptions written beside each line. The step is done when recurring infrastructure and recurring people costs are separated and each has a named assumption that a colleague can challenge.
Scope migration and implementation in a written proposal
One-time costs usually dominate the first year, so request a fixed-scope written proposal from an implementation partner or from your internal team, covering deployment, connector rebuilds, glossary and ownership migration, SSO configuration, cutover and training. The proposal should name deliverables, acceptance criteria and exclusions. For Atlan exits, ask how custom metadata and lineage will be rebuilt rather than exported. The step is done when the one-time costs are a document, not an internal guess, and you know which items sit outside the proposal.
Build the three-year view with one-time and recurring lines
Lay out three annual columns. Put one-time items in year one only: migration, implementation, initial training and any parallel running of both catalogs. Put recurring items in every year: Atlan subscription and runtime hosting, infrastructure, staff operation, upgrades, support contracts and the Self-Deployed Runtime's maintenance. Add a sensitivity row for the two drivers you cannot control, which are Atlan renewal uplift and cloud price changes. The step is done when totals per year and over three years are visible for both options, with each line tagged as one-time or recurring.
Confirm assumptions before you decide
Review the model with Atlan's account team, your cloud provider's pricing pages and the teams who will operate the catalog. Ask Atlan to confirm the included support, runtime responsibilities and any cost the quote does not show. Ask operators to confirm the hours assumed for upgrades and connector changes, since DataHub's Helm chart runs a system-update job on upgrades and OpenMetadata documents version-specific breaking changes. The step is done when each assumption has a named confirmer and a written answer, and the model is used as a basis for a decision rather than a substitute for vendor documents.

What running OpenMetadata or DataHub costs each year

The recurring cost of a self-hosted catalog sits in four places: the infrastructure it runs on, the upgrades you apply, the support you buy or staff you keep, and the people who operate it. For OpenMetadata, the bare metal minimum for the server is 2 vCPUs, 4 GB RAM and 20 GB storage, and the database and search services each need at least 2 vCPUs, 2 GB RAM and 30 GB storage. Production deployments on Kubernetes, Amazon EKS, Azure AKS, Google GKE or on-premises clusters use the same sizing logic plus replicas and backups, which you should size with your own ingestion volume in mind. Ask your platform team to price these nodes in your own cloud or data center rather than relying on minimums.

DataHub carries a heavier stack. Its Kubernetes guide lists GMS, the MAE Consumer, the MCE Consumer and the Frontend, plus Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch for search and a graph index on Neo4j or Elasticsearch. The guide notes that more than 7 GB of RAM is needed just to run DataHub and its dependencies on Minikube, which is a development floor, not a production size. Each of these components needs monitoring, patching and backup, so count them individually when you compare against an Atlan subscription and its Self-Deployed Runtime. Upgrades are the cost most often underestimated. DataHub's Helm chart runs a system-update job on upgrades to apply schema changes and reindex search when needed, so plan a maintenance window and a rollback path for each release. 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. Release cadence matters here: OpenMetadata 2.0.0 shipped on August 24, 2026, with maintenance releases 2.0.1 to 2.0.5 following, and DataHub 1.7.0.1 was released on September 3, 2026. Budget engineering time for regular patch intake, not just major versions.

People are the largest recurring line for most teams. Someone must own the Kubernetes or bare metal platform, the databases and search clusters, the Kafka or ingestion scheduler, SSO configuration (for DataHub Core, the frontend OIDC settings are set by the operator), and connector credentials. Ask whether this work sits with an existing platform or data engineering team, and what share of an engineer's time it consumes each month. Commercial support from Collate for OpenMetadata or from the DataHub company for DataHub Cloud shifts some of this work to a vendor, at a subscription fee you should compare line by line with the Atlan quote. Request written support scope, upgrade assistance and incident response terms from each option before you decide.

Atlan, DataHub Cloud, Collate or fully self-run: which cost profile fits

Atlan is a cloud-first, single-tenant SaaS platform hosted by Atlan on AWS, Azure or Google Cloud. The subscription generally covers the hosted platform itself, its operation and its upgrades, so your team does not run the metadata store, search or identity layer. Atlan's architecture documentation describes the platform as built on Apache Atlas for metadata storage, with Cassandra and Elasticsearch, and uses Keycloak for SSO, OIDC and SAML.

Hosting and upgrades: The vendor operates the single-tenant platform on the cloud provider you select, and applies platform updates.
Self-Deployed Runtime: Connectors that reach on-premises or VPC-locked sources run in your network, so your team hosts, patches and monitors that component.
Network and identity: Confirm with Atlan how SSO is configured for your identity provider and what network paths your sources need.
Recurring fees: The subscription recurs, and the contract terms determine what is included, such as support levels and connector runtime capacity.
Exit effort: Metadata export is a separate workstream. Ask what export options your contract includes.

Before signing, ask Atlan for a written breakdown of which components are in the subscription, what the Self-Deployed Runtime needs in terms of compute and network, and who is responsible for each upgrade.

Costs teams forget on each side

Subscription fees are only one line in an Atlan comparison. The costs that surprise teams sit on both sides: the runtime Atlan asks you to host, and the operational work a self-hosted catalog adds, plus the cost of leaving. Use these cards to build a quote request that compares the same scope.

Self-Deployed Runtime upkeep

With Atlan, the platform runs in Atlan's cloud, but connectors that reach on-premises or VPC-locked sources run in your network through the Self-Deployed Runtime. That component still needs a host, network rules, patching, monitoring and a named owner. Ask Atlan which operating systems, container runtimes and outbound endpoints it requires, and who is responsible for upgrading it when the platform changes.

Backup and restore of stores

A self-hosted catalog keeps its metadata in a relational database and a search index, and both need backups you have tested by restoring. OpenMetadata's bare metal guide lists MySQL or PostgreSQL and Elasticsearch or OpenSearch as prerequisites, and DataHub depends on MySQL or PostgreSQL, Kafka and Elasticsearch. Budget storage, backup tooling and restore drills for each store, and agree on recovery targets in writing before go-live.

On-call and hardening

Self-hosting moves uptime, certificate renewal, vulnerability patching and security configuration to your team. Atlan's SaaS model keeps that work with the vendor, while in a self-hosted deployment an outage in the catalog, Kafka or search layer becomes your incident. Ask who covers alerts out of hours, how base images and dependencies are patched, and which hardening baseline your security team will accept.

SSO and frontend configuration

Atlan includes Keycloak-based SSO, OIDC and SAML in its platform. On self-deployed DataHub Core, the frontend server must be configured by the operator, including the OpenID Connect settings for providers such as Okta or Azure AD. Count the hours to set up SSO, group mapping and role assignment, then retest them after each upgrade, since identity changes are a common source of access defects.

Staff turnover and skills

A self-hosted catalog depends on a few people who understand its Helm charts, schema migrations, connectors and search reindexing. When one of them leaves, knowledge gaps appear quickly. On the Atlan side, the skills to manage tenant configuration and the runtime sit with your administrators. Document the runbooks, cross-train at least two operators, and price the recurring time of these roles in your comparison.

Cost of leaving Atlan

Exit has its own one-time costs: extracting glossaries, owners, tags and custom metadata with pyatlan, reconnecting every source through new connectors, rebuilding lineage that Atlan does not export as-is, and running parallel catalogs while teams cut over. Estimate these as a separate project with its own scope, and check your contract's notice period and data return terms before you plan the date.

What the one-time migration costs and what drives it

Migration is usually the largest one-time cost, and its size depends less on the number of users than on what has to be moved and rebuilt. The main drivers are the volume of curated metadata (business glossaries, asset ownership, tags and custom metadata), the number of connectors running through Atlan's Self-Deployed Runtime that must be replaced with OpenMetadata or DataHub ingestion, the lineage that has to be rebuilt rather than copied, and the number of SSO and team cutovers. Each of these scales with a different part of your estate, so ask for them to be quoted separately. Atlan's SaaS model means its metadata store is not something you can dump directly, so extraction is done through its SDKs. Glossaries and ownership are usually the highest-value items and the ones teams cannot afford to lose, while many connector-derived assets are cheaper to re-ingest than to export. Before scoping, inventory which Self-Deployed Runtime connectors you run, which custom metadata fields carry real governance meaning, and how many business terms are actively used. The method for each path is covered on the sibling pages on migrating from Atlan to OpenMetadata and on migrating to DataHub, and the export mechanics are covered on the page on exporting metadata from Atlan. A quote follows from a written scope that lists these items, the target platform and the cutover plan, and no duration is given here because it depends on that scope. Ask any provider to state which items are fixed, which are priced per connector or per team, and what acceptance test confirms that glossaries, ownership and lineage match the source before Atlan is switched off. Plan for a parallel run period in the budget, since teams often need to check downstream dashboards and access rules against the new catalog before retiring the old one.

Questions buyers ask before comparing Atlan costs

What is the total cost of self-hosting OpenMetadata or DataHub versus an Atlan subscription?

The honest answer is that the comparison has two sides, and the software licence is the smallest part of each. An Atlan subscription bills for the platform, hosting and vendor-run upgrades, while your Self-Deployed Runtime and the connector work still sit in your network. Self-hosting moves cost into infrastructure you pay for directly, the staff who operate Kubernetes, databases and search, the implementation, and the upgrades you schedule yourself. Both OpenMetadata and DataHub are Apache-2.0 licensed, so the recurring cost is compute, storage and people. Build a model that lists each component separately, marks which items are one-time and which recur, and then compares it with the Atlan quote for the same scope of sources and users.

How long does a migration from Atlan to a self-hosted catalog take?

No single duration applies, because the timeline depends on drivers you can measure in your own environment. The main ones are the number of sources and how many need a connector rebuilt, how much curated metadata (glossaries, owners, tags, custom attributes) must be extracted and mapped, how many teams and SSO integrations must cut over, and how much lineage has to be rebuilt by re-ingestion rather than copied. Atlan's Python and Java SDKs are the documented route for extraction, so the scripting effort scales with the metadata model you use. Ask any implementation partner for a written plan that lists these drivers and the milestones they produce before agreeing a scope.

Can our own team run OpenMetadata or DataHub without outside help?

Yes, many teams do, provided they have the skills and time for it. Both projects are open source and document production deployments, so there is no licence barrier. The practical question is capacity: someone must own the deployment, upgrades, backups, connector maintenance and incident response after go-live. OpenMetadata 2.0 introduced breaking changes, including moving embedding credentials into an llmConfiguration block, a new Databricks auth format and rebuilding custom ingestion images for Python 3.12, so upgrades need a reviewed runbook. Decide honestly whether your team can absorb that work alongside its normal duties, or whether a fixed-scope implementation followed by a retainer fits better.

What skills does a self-hosted catalog need from our engineering staff?

The skills depend on the deployment path you choose. For a Kubernetes deployment, DataHub is installed with Helm charts from its Helm repository plus a separate prerequisites chart, and OpenMetadata supports Helm on EKS, AKS, GKE or on-premises clusters. Your staff need Kubernetes operations, a managed or self-run MySQL or PostgreSQL database, Elasticsearch or OpenSearch for search, and identity integration. DataHub also needs Kafka for streaming metadata changes. On bare metal, OpenMetadata requires Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. Map each skill to a named person before you estimate effort, and confirm the gaps with your platform team.

Is the open-source catalog software free, and what do the paid editions add?

The core software is free to use under its licence: OpenMetadata and DataHub are both Apache-2.0 licensed, and Apache Atlas is also Apache-2.0. What costs money is everything around the software. Collate sells managed OpenMetadata and commercial support, and DataHub Cloud is the managed product from the company behind DataHub. DataHub Cloud adds features that are not in open source, including data quality monitoring, compliance forms, access request workflows, a 99.5% uptime SLA and AWS PrivateLink. Read the licence and the feature comparison for each product, and separate the free core from any managed or support contract in your quote.

What should we ask for in a quote for a self-hosted catalog engagement?

Ask for a fixed scope in writing before any work starts. A useful quote lists the sources and connectors in scope, the deployment target (Kubernetes or bare metal, and which cloud or on-premises cluster), the metadata to migrate and the method for extracting it, the SSO and team cutover work, and the testing and documentation deliverables. It should separate one-time items (design, implementation, migration, hardening, initial training) from recurring items (upgrades, backups, monitoring, support retainer). Ask what is excluded, such as your own infrastructure costs, licences for any paid edition, and connector maintenance after handover. DeployOpen plans and implements these engagements on a fixed-scope basis, and it does not publish a price list, so the quote follows from the written scope.

When the cost case favors self-hosting and when it does not

Self-hosting tends to win on cost when the organization already runs Kubernetes or bare metal, already has people who upgrade and patch platforms on a routine basis, and has a hard requirement for metadata to stay inside its own network. In those conditions the subscription line is the main saving, and the marginal cost of one more catalog is mostly compute, storage and staff hours that are already budgeted. OpenMetadata documents production deployment on Kubernetes with Helm charts and on bare metal with Java 21 and a supported database and search service, and DataHub is deployed on Kubernetes with Helm charts plus a separate prerequisites chart. If your platform team can absorb those components, the open-source case is strong. A renewal date is also a reason to model the options now, because a self-hosted build takes time to implement and migrate.

Atlan can cost less in total when the team lacks platform skills or prefers a vendor-operated service. Atlan hosts the platform on AWS, Azure or Google Cloud and runs upgrades for you, so the people line in your model is largely the internal administrators and the time spent on the Self-Deployed Runtime. Self-hosting shifts that work to your staff: someone owns the Kubernetes cluster, the database, the search index, SSO configuration and the upgrade path, including breaking changes such as those in OpenMetadata 2.0. The uncomfortable question is whether those skills already exist on your team or would need to be hired or contracted. An illustrative case: a team with two platform engineers already on call may find the upgrade work fits, while a team with no Kubernetes experience will pay for it in either hiring or implementation fees.

Before deciding, write down your assumptions in one place: the number of catalog administrators, the expected upgrade frequency, the hosting you would use, the sources you need to reach, and the exit cost if you later leave. Then request two written quotes: one from Atlan for the subscription and Self-Deployed Runtime hosting, and one from an implementation partner for a self-hosted build, scoped to the same connectors and users. Ask each side to state what is one-time and what recurs, which support tier and uptime commitment are included, and who is responsible for upgrades and backups. Confirm the current release cadence and support terms directly with each vendor and project, because a cost comparison built on last year's assumptions will mislead. DeployOpen can scope and quote the self-hosted side as a fixed-scope engagement, but the comparison should be checked against both written proposals.

How DeployOpen scopes a fixed-price implementation and hands it over

DeployOpen approaches Atlan cost vs a self-hosted open-source catalog as a written, fixed-scope engagement. We agree what gets planned, built, tested and documented before any work starts, so your team can compare the cost components on this page against a concrete quote.

How we scope

We start from your current Atlan subscription, Self-Deployed Runtime footprint and the sources each team depends on.
The written scope lists the catalog platform, connectors, SSO, lineage and glossary items included in the engagement.
Scope also names which metadata is exported, which connectors are rebuilt, and who in your organization signs off on each deliverable.

How we build

We deploy OpenMetadata or DataHub inside your own cloud accounts, data centers or air-gapped network, as agreed in scope.
Connector ingestion, lineage, glossary import and SSO configuration are built and tested against your real sources.
Hardening, backup setup and sizing decisions are documented so your platform team can review them before cutover.

How we hand over

Handover includes runbooks for deployment, upgrades, connector changes and backup and restore procedures.
We document the architecture, configuration keys, access model and the evidence your compliance team may need for assessments.
Your operators are trained on day-to-day administration, and the handover is confirmed against the written scope.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover version upgrades, including breaking changes listed in the vendor release notes for the version you run.
Ask for the retainer terms, response expectations and what is excluded in writing before you commit to a platform choice.

Atlan cost vs a self-hosted open-source catalog