When Atlan or OpenMetadata fits your data catalog
Atlan fits a team that wants a managed, single-tenant service with vendor-run hosting and upgrades, and that does not want to staff a metadata platform. OpenMetadata fits a team that must keep metadata inside its own network and has engineers who can operate Kubernetes or bare metal, databases, a search cluster and ingestion pipelines. The decision turns on four questions: your hosting requirements, your in-house operating capacity, the connectors you must have on day one, and how heavily you rely on Atlan's managed AI and collaboration features. If any one of these answers is a hard requirement, it usually settles the choice before feature comparison starts.
Start with hosting. Atlan runs as a cloud-first SaaS platform on AWS, Azure or Google Cloud, and on-site it offers only a Self-Deployed Runtime for reaching on-premises or VPC-locked sources. If your rule is that catalog metadata itself must not leave your network, Atlan's architecture does not meet it, and you should confirm the exact data flows in writing with Atlan before assuming otherwise. OpenMetadata documents production deployments on Amazon EKS, Azure AKS, Google GKE, on-premises Kubernetes and bare metal, so the entire stack can sit in your accounts. Next, check the operating side. The bare metal prerequisites include Java 21, MySQL or PostgreSQL, and Elasticsearch 9.x or OpenSearch 3.x, and the upgrade path for 2.0 includes breaking changes such as moving embedding credentials into an llmConfiguration block. Someone on your team must own those upgrades, backups and search tuning.
Then test connectors and features against your estate. OpenMetadata lists more than 130 connectors and OpenLineage event integration, and Atlan's connector set should be compared against the same list of systems you run. Ask Atlan which Self-Deployed Runtime components you would need and who patches them. Finally, weigh the managed features. If your teams depend on Atlan's hosted AI capabilities, collaboration workflows or vendor-run support, those are costs to replace or staff, not free. Write down which of these you use weekly, and price the replacement work before you decide. Teams that answer the hosting and staffing questions honestly usually know which product they need within a single planning cycle.
Which option fits which scenario
This table maps common buying situations to the platform that fits them better, with the reason tied to deployment facts. Read each row as a starting point, then confirm the points marked for verification against your own environment and with each vendor.
| Scenario | Better fit | Reason |
|---|---|---|
| Strict residency for metadata, with no metadata leaving your network | OpenMetadata | Atlan is single-tenant SaaS hosted on AWS, Azure or Google Cloud, and only the Self-Deployed Runtime runs in your network. OpenMetadata can run entirely on your own Kubernetes or bare metal. |
| Small platform team with limited Kubernetes or database operations capacity | Atlan | Atlan hosts and upgrades the platform. OpenMetadata means your team operates the services, database, search index and upgrades, including the breaking changes in 2.0 that require rebuilt ingestion images. |
| Heavy reliance on Atlan's managed AI features | Atlan | Atlan's AI features run in its hosted platform. OpenMetadata's AI-adjacent features, such as MCP, are available, but confirm which Collate features you need before you assume parity. |
| Wide connector estate across warehouses, BI, pipelines and ML platforms | Either, after a connector check | OpenMetadata lists more than 130 connectors and OpenLineage integration. Confirm that Atlan's connectors cover your specific sources, including any on-premises or VPC-locked ones that need the Self-Deployed Runtime. |
| Sources that sit only inside a VPC or on-premises network | OpenMetadata | Atlan requires a Self-Deployed Runtime on your side for these sources, so some metadata still flows through a component you run. OpenMetadata ingestion runs wherever your sources are reachable. |
| Need for a fixed-scope implementation with a named delivery partner | Either, with a written scope | Atlan delivery is usually handled through its own services. For OpenMetadata, DeployOpen can plan, deploy, harden and document a fixed-scope implementation in your environment. Ask each option for its written scope before comparing timelines. |
| Need for vendor-supported production SLAs and premium support | Atlan, or OpenMetadata with Collate | Collate offers managed OpenMetadata and commercial support. Ask for the support terms and uptime commitments in writing from either vendor, since none are assumed here. |
Where your metadata lives with Atlan and with OpenMetadata
Atlan is a cloud-first, single-tenant SaaS platform hosted by Atlan on AWS, Azure or Google Cloud, so the catalog itself runs in Atlan's cloud environment rather than in your data center or cloud account. The only component you can place in your own network is the Self-Deployed Runtime, which Atlan describes as the way to reach on-premises or VPC-locked sources. Before you approve Atlan for a regulated workload, ask Atlan in writing which metadata, sample values, credentials and logs pass through the Self-Deployed Runtime, which metadata is stored in the Atlan-hosted tenant, and in which region each lives. Confirm these answers against the Atlan architecture documentation and your data residency obligations.
OpenMetadata takes the opposite placement. You deploy the whole stack, including the server, database and search service, in your own environment. The deployment documentation covers production installs on Kubernetes with Helm charts on Amazon EKS, Azure AKS, Google GKE or on-premises Kubernetes, and a bare metal option without Kubernetes. Docker Compose is intended for evaluation only. In this model, the metadata store, search index, audit trail and connector credentials sit in the cloud account or data center you already govern, which makes data location a question your own architecture answers. The trade-off is that your team owns backups, patching and capacity for every component.
Atlan's architecture documentation states that the platform stores metadata on Apache Atlas, backed by Cassandra and Elasticsearch, with Keycloak handling SSO over OIDC and SAML. You do not operate these components, but your security team should understand them because they determine what Atlan's tenant holds and how identity is federated. For OpenMetadata, the equivalent decisions are yours: choose MySQL 8.0.42 or later or PostgreSQL 15 or later, choose Elasticsearch 9.x or OpenSearch 3.x, and configure authentication in the deployment. Map each component to a data classification level and record where it runs before the pilot starts.
How connectors, lineage and governance compare
This table sets OpenMetadata's documented capabilities against what Atlan's supplied architecture facts cover, so you can see where the comparison is verified and where you need to check Atlan's current documentation. Read the Atlan column as a list of items to confirm, not as a ranking. The main takeaway is that OpenMetadata's feature list is public and checkable, while Atlan's connector counts, glossary depth and AI features need to come from Atlan directly.
| Capability | OpenMetadata (self-hosted, Apache-2.0) | Atlan (single-tenant SaaS) |
|---|---|---|
| Connector coverage | More than 130 connectors for warehouses, BI tools, pipelines and ML platforms | Confirm the current connector list and count in Atlan's documentation |
| Lineage | Table, column, dashboard, pipeline and metric lineage, with OpenLineage event integration | Confirm lineage types and depth per source in Atlan's documentation |
| Data quality and profiling | Data quality tests, profiling, Dynamic Sampling as the profiler default in 2.0, and freshness checks | Confirm which quality and freshness features are included in your Atlan plan |
| Glossaries, classifications and domains | Glossaries, classifications and domains are built in | Confirm glossary depth, term approval workflows and domain modeling against Atlan's current docs |
| Programmatic access | REST APIs, a Python SDK, TypeScript packages and Java libraries | Atlan documents Python and Java SDKs; confirm REST coverage with Atlan |
| AI features | MCP server enabled by default in 2.0; AI features are offered by Collate, not in the open-source edition | Confirm current AI features and whether they run in Atlan's cloud or in your network |
| Metadata storage | Runs in your own Kubernetes, bare metal or Docker environment | Metadata is stored in Atlan's cloud, built on Apache Atlas, Cassandra and Elasticsearch |
| Connectivity to on-premises sources | Connectors run where you deploy the platform, inside your network | Self-Deployed Runtime runs in your network for on-premises or VPC-locked sources |
What hosting and data control change for compliance
Hosting model decides where catalog metadata, access logs and credentials live, and who can produce evidence when an assessor asks. Atlan keeps the control plane in its own single-tenant cloud environment, while OpenMetadata runs wherever your team deploys it. The cards below set out what to check on each side before you write the control narrative.
Data location of metadata
Atlan hosts its platform on AWS, Azure or Google Cloud, so the metadata store sits in an environment Atlan operates for you. With OpenMetadata, metadata is stored in the database and search services you deploy, such as MySQL or PostgreSQL and Elasticsearch or OpenSearch, in your own cloud account or data center. Confirm with Atlan which cloud region and provider hold your tenant, and confirm which metadata fields, sample values or query logs leave your network.
Hosting responsibility model
With Atlan, Atlan runs the platform and you run only the Self-Deployed Runtime in your network for on-premises or VPC-locked sources. With self-hosted OpenMetadata, your team owns the Kubernetes or bare metal estate, patching, backups and access reviews for every component. Map each control to the party that operates it, and record that split in the system description given to your assessor.
Identity and single sign-on
Atlan's architecture documentation states it uses Keycloak for SSO, OIDC and SAML. For OpenMetadata, confirm in the security documentation which identity providers, token formats and role mappings it supports in your release, and whether you can enforce MFA through your IdP. Verify how user deprovisioning flows into each catalog, because stale accounts are a common finding in access reviews.
Audit evidence and logs
Assessors usually ask who changed a glossary term or classification, and when. Ask Atlan for the audit log export it provides, its retention period and whether logs can be streamed to your SIEM. With OpenMetadata, you own the audit trail, so decide where application and database logs are shipped, how long they are kept and how you prove their integrity. Neither option removes the need for your own evidence collection.
Air-gapped and restricted networks
Atlan runs as SaaS, so an air-gapped or strictly segmented network cannot use the full platform, only the Self-Deployed Runtime on site. OpenMetadata can be deployed on-premises Kubernetes or bare metal and its images can be mirrored into an internal registry, which is the basis for an offline install. Test the install path, including container image mirroring and connector dependencies, before committing to a design.
Vendor and exit dependency
Atlan is a single-tenant SaaS, so exit planning depends on exporting glossaries, owners and tags through its SDKs, since the vendor does not publish a general OpenAPI spec for that purpose. OpenMetadata is Apache-2.0 licensed, so the software itself stays available if a vendor changes terms, but a managed or commercial support contract from Collate is a separate decision. Ask for a written data return and deletion commitment from any vendor you choose.
How licensing and editions differ between the two
OpenMetadata is released under the Apache License 2.0, so the core project can be downloaded, run and modified in your own infrastructure without a license fee. Atlan is different in kind: it is a subscription SaaS product, single-tenant and hosted by Atlan on AWS, Azure or Google Cloud, and what you pay for is the platform service, the hosting and the vendor's operation of it. The licensing question is not whether the software is free, but who runs it and who is accountable when it fails. The project is maintained by Collate, which also offers managed OpenMetadata, commercial enterprise capabilities, premium support and AI features on top of the open-source core.
Because of that split, the costs you carry differ. With OpenMetadata you pay for the infrastructure (Kubernetes or bare metal, a database and a search service), for the people who operate and upgrade it, and for any support or managed hosting you buy from Collate or another provider. The current release line matters for planning: OpenMetadata 2.0.0 was released on August 24, 2026, and maintenance releases followed through 2.0.5 on October 8, 2026. Breaking changes in the 2.0 line, such as the llmConfiguration block and the Python 3.12 ingestion images, are upgrade work you should budget for, whichever edition you choose.
Before you compare quotes, get the edition terms in writing. Ask Collate which capabilities are in the Apache-2.0 core and which sit in its commercial enterprise edition, what the premium support covers and its response commitments, whether AI features and the managed service are separately licensed, and whether any feature you need, such as particular governance workflows or access controls, is available only commercially. Ask Atlan for the same breakdown of its subscription, including what the Self-Deployed Runtime costs to run in your network. Confirm current terms with each vendor directly, since editions and packaging change.
Who runs the catalog day to day under each model
Under Atlan's model, Atlan hosts and operates the platform on AWS, Azure or Google Cloud as a single-tenant service. Your team does not patch the catalog application, its metadata store or its search layer. The customer-side work centers on the Self-Deployed Runtime, the component that runs in your network to reach on-premises or VPC-locked sources. Someone on your side still needs to keep that runtime current, provide the network path and credentials, and watch it when sources change.
- Runtime upkeep: your team installs, updates and restarts the Self-Deployed Runtime inside your network.
- Network and credentials: your team manages firewall rules, service accounts and secrets the runtime uses to reach each source.
- Platform changes: Atlan performs platform upgrades, but your admins should confirm the release timing and what changes for your tenant.
- Monitoring: you watch runtime health and source connectivity, while Atlan's own service monitoring is governed by its contract.
- Identity: SSO integration and access policies remain configured and reviewed on your side.
Confirm with Atlan in writing which runtime versions it supports, how runtime updates are delivered, and what support covers when a runtime fails inside your network.",
Self-hosting OpenMetadata on Kubernetes moves the whole platform into your cluster. OpenMetadata documents production deployments with Helm charts on Amazon EKS, Azure AKS, Google GKE or on-premises Kubernetes. Your platform team then owns the application, its database and search backends, ingestion workloads, backups and version upgrades. Upgrades deserve planning because OpenMetadata 2.0 introduced breaking changes, including new credential blocks and a rebuild of custom ingestion images for Python 3.12.
- Application and chart upgrades: your team tracks releases and applies Helm chart changes in staging before production.
- Stateful services: you run and back up the metadata database and the search cluster, and size them for growth.
- Ingestion: scheduled ingestion jobs run as workloads that need their own images, secrets and failure alerting.
- Security hardening: cluster policies, TLS, SSO and secret handling are configured and reviewed by your team using OpenMetadata's security documentation.
- Monitoring: you own cluster, application and pipeline monitoring, typically in the observability stack you already run.
Confirm which Kubernetes distribution, storage class and search version your platform team will standardize on before estimating the operating load.",
Bare metal runs OpenMetadata directly on hosts without Kubernetes, which suits teams without a cluster or with strict host-level control. The documented prerequisites are Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. The minimum server sizing is 2 vCPUs, 4 GB RAM and 20 GB storage for the application, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. Those are floors for a trial or small deployment, not production capacity.
- Runtime stack: your team patches the operating system, Java runtime, database and search engine on separate schedules.
- Service management: you define systemd units or equivalent, restart policies and log rotation for each service.
- Upgrades: each OpenMetadata upgrade is a manual procedure on the hosts, with a rollback plan you write and test.
- Backups and recovery: you schedule database and search snapshots and test restores on your own.
- Capacity: you add hosts and storage by hand as metadata and ingestion volume grow.
Ask your platform team to confirm the exact version matrix against the bare metal documentation and to estimate the on-call coverage for the database and search tiers before committing to this model.
What a managed subscription and a self-hosted catalog each cost
This table sets the cost components of an Atlan subscription with its Self-Deployed Runtime against running OpenMetadata yourself, marking each as one-time or recurring and naming what drives it. Use it to build a like-for-like quote request, since no price for either side is stated here.
| Cost component | Who is paid or who pays | One-time or recurring | Main cost drivers |
|---|---|---|---|
| Atlan subscription | Atlan, under your contract with it | Recurring | Contracted scope, user count and connected sources as set in your agreement; ask Atlan how each is metered |
| Self-Deployed Runtime hosting (Atlan) | Your cloud or infrastructure team and your cloud provider | Recurring | Compute for connector runs in your network, reach to on-premises or VPC-locked sources, and patching the runtime |
| OpenMetadata software | No license fee; Apache-2.0 software | Not applicable | Licensing is free, so budget goes to infrastructure, operations and support |
| OpenMetadata infrastructure | Your cloud provider or hardware vendor | Recurring | Kubernetes or bare metal footprint, database and search services, and storage growth; minimum sizing is 2 vCPUs, 4 GB RAM and 20 GB for the server, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB (OpenMetadata bare metal docs) |
| Implementation and connector build-out | Your team or an implementation partner, under a fixed scope | One-time | Number of sources, custom ingestion, SSO and glossary load; agree the scope in writing before work starts |
| Migration from Atlan | Your team or a partner | One-time | Extracting glossaries, ownership and custom metadata, rebuilding lineage and cutting over teams |
| Upgrades and breaking changes | Your operations team or a partner | Recurring | OpenMetadata 2.0 moved embedding credentials into an llmConfiguration block, changed the Databricks auth format, requires custom ingestion images rebuilt for Python 3.12, and needs Great Expectations migrated to 1.3 before upgrading |
| Support | Atlan for its subscription; Collate or a partner for OpenMetadata support | Recurring | Support tier chosen; OpenMetadata premium support comes from Collate, while community support is free but carries no guaranteed response |
| Staff who operate the catalog | Your employees | Recurring | Platform and data engineers for ingestion, Kubernetes or database administration, on-call and backup testing; often the largest line item for a self-hosted catalog |
What a move from Atlan to OpenMetadata involves
The sequence turns Atlan's curated metadata into an OpenMetadata catalog that your team operates inside your own infrastructure, with lineage rebuilt and access cut over in a controlled order.
Inventory assets, owners and sources
List every data source Atlan connects to, including the ones reached through a Self-Deployed Runtime, and record which teams own each domain, dataset and glossary area. Your data governance lead and the source owners do this together, and the output is a signed-off inventory that shows which sources need an OpenMetadata connector, which need a network path to be opened, and which can be retired. You know it is done when every source has a named owner and a target ingestion method.
Extract glossaries and custom metadata from Atlan
Use Atlan's Python or Java SDK to export glossary terms, descriptions, owners, tags and any custom metadata attributes your teams rely on. An engineer with API access to the Atlan tenant runs the export scripts and stores the results in version-controlled files outside Atlan. The check is a reconciliation report that matches term counts and ownership assignments against what the Atlan interface shows for a sample of domains.
Load glossaries through OpenMetadata CSV import
Convert the exported glossary and classification content into the CSV format OpenMetadata's import expects, then load it into a non-production OpenMetadata instance. A data steward reviews term hierarchy, synonyms and ownership after import, and corrects any rows that failed validation. The step closes when the glossary in OpenMetadata matches the reconciled export, with no orphaned terms.
Replace Self-Deployed Runtime connectors with ingestion
Configure OpenMetadata ingestion for each source in the inventory, running it on your Kubernetes cluster or bare metal host so that connections to on-premises and VPC-locked sources stay inside your network. Platform engineers set credentials through your secrets tooling and schedule metadata pulls. The check is a successful ingestion run per source, with asset counts compared against the Atlan catalog for the same source.
Rebuild lineage and governance rules
Recreate table, column and pipeline lineage through OpenMetadata's connectors and, where pipelines emit events, its OpenLineage integration. Data stewards then re-apply classifications, domains and any data quality tests that the business depends on. Lineage gaps are logged rather than assumed to be fixed, and the step closes when the lineage graph for the priority data products has been reviewed and signed off by their owners.
Test on a non-production instance
Run the migrated catalog in a non-production environment with a representative group of users. Test search, glossary navigation, permissions, API calls used by your pipelines and any integrations with collaboration tools. Confirm that single sign-on works through your identity provider. The step is complete when pilot users have verified their core workflows and the open issues list has an owner and a resolution path.
Cut over teams and single sign-on
Move teams to the OpenMetadata instance in groups, switch SSO to your identity provider, and set Atlan to read-only for a defined period so that no metadata changes are lost during the transition. Your identity team and catalog administrators coordinate the switch and keep a rollback plan. The cutover is done when all in-scope teams log in to OpenMetadata, Atlan access is retired on an agreed date, and the final export is archived.
What buyers ask before switching from Atlan to OpenMetadata
What does it cost in effort to move from Atlan to OpenMetadata?
Effort is driven by what you need to carry across, not by the tool itself. The main work items are extracting glossaries, ownership and custom metadata from Atlan, rebuilding connectors as OpenMetadata ingestion pipelines, recreating lineage, and retraining the teams who use the catalog. Costs split into one-time work (planning, extraction, ingestion setup, validation, cutover) and recurring work (running the platform, upgrades, and stewardship). The biggest drivers are the number of sources, how much custom metadata and glossary structure you use, and how many SSO and access rules must be recreated. Ask any implementation partner for a quote built from a written scope that lists each source and metadata type.
How long does an Atlan to OpenMetadata migration take?
No timeline is fixed in advance, so treat any single number with caution. The schedule depends on the count of connected sources, the volume of curated metadata to move, how cleanly your glossary and ownership data is maintained, and whether you run both catalogs in parallel during cutover. Teams that keep Atlan running until OpenMetadata is validated usually need a parallel period, which lengthens the project. Ask for a phased plan with milestones per source group and a defined cutover window, and confirm how each phase depends on your data stewards' availability.
Can our own team migrate from Atlan without outside help?
Yes, a capable internal team can do it, provided it has the skills and time. OpenMetadata is Apache-2.0 licensed and documents production deployment on Kubernetes with Helm charts, on Amazon EKS, Azure AKS, Google GKE or on-premises Kubernetes, and on bare metal. Your team will need Kubernetes or Linux operations experience, database and search administration, and someone who can write extraction scripts against Atlan's Python or Java SDKs. Many organizations bring in outside help for planning, extraction and cutover, then keep operations in house. Confirm your internal capacity before choosing a path.
What do our engineers and data stewards need to contribute?
Engineers handle infrastructure, connector configuration, the extraction scripts and SSO integration. Data stewards must confirm which glossary terms, owners, tags and descriptions are current and should move, because a migration is a good moment to remove stale metadata. Plan for stewards to review a sample of migrated assets in each domain before cutover. Engineers should also review OpenMetadata's connector credentials and access model, and confirm that the security configuration in the OpenMetadata security documentation fits your policies. Name these owners in the scope document before work starts.
How do upgrades differ between Atlan and self-hosted OpenMetadata?
With Atlan, the vendor operates the single-tenant SaaS platform and handles its upgrades. With self-hosted OpenMetadata, your team or your partner schedules and tests upgrades. OpenMetadata 2.0.0 was released on August 24, 2026, followed by maintenance releases 2.0.1 to 2.0.5, and the project reports maintenance releases roughly every one to two weeks. The 2.0 release also has 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. Budget for a staging environment and a regression test pass for every upgrade you adopt.
Is OpenMetadata's connector coverage enough to replace Atlan's?
It depends on your source list. OpenMetadata lists more than 130 connectors for warehouses, BI tools, pipelines and ML platforms, and supports an OpenLineage integration. Map every source you run against the connector list before you commit, and separately check the connectors that use Atlan's Self-Deployed Runtime, because those sources need a supported OpenMetadata path or a custom ingestion job. Pay attention to connectors for on-premises or VPC-locked systems, since those must run inside your network. Confirm each mapping in writing and record any gap as a scope item with an owner.
Does moving to OpenMetadata reduce our compliance workload?
Self-hosting moves control of the metadata store into your own environment, which can help with data residency and access review requirements. It does not by itself satisfy any control framework. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do. Ask your auditor which evidence they expect for the catalog, such as access logs, role definitions and change records, and build those into the scope.
When Atlan's managed service is the better fit
Self-hosting OpenMetadata is not the right default for every team. If you have no platform engineers who can run Kubernetes or bare metal services, and no capacity to plan upgrades, the operating burden is the deciding factor, and Atlan's managed service removes most of it. Atlan runs its platform as a cloud-first, single-tenant SaaS on AWS, Azure or Google Cloud, so Atlan handles hosting, patching and platform upgrades. The work that remains on your side is the Self-Deployed Runtime for sources that sit inside your network or a VPC, which still needs someone to keep it running. The advantage also matters if your main goal is the collaboration layer rather than the metadata store. Atlan's product is built around business users, stewards and analysts who need a polished interface and workflows without installing anything. OpenMetadata covers much of the same ground through its glossaries, classifications, domains and data quality features, but a team that wants a polished, vendor-supported experience out of the box should weigh that gap against the cost of building its own front end, tuning search and onboarding users. Be specific about which features your stewards will use every day.
Before you decide, ask Atlan to confirm in writing where your metadata is stored, which regions and cloud accounts host your tenant, how single-tenancy is enforced, and which parts of the stack run inside your network. Ask what the Self-Deployed Runtime requires in terms of hosts, network paths and who on your side must operate it, and how that changes if you need a fully on-premises or air-gapped deployment. Confirm the upgrade notification process, maintenance windows, the support tiers available and the exit terms, including how you would export glossaries, ownership and custom metadata if you later leave. Also confirm which AI features are included and whether they send metadata to third-party models. If the answers show that metadata can stay where your policies require, that your team cannot staff a platform, and that your stewards depend on Atlan's collaboration features, the managed service may be the better choice. If any of those conditions fails, the self-hosted path needs a costed plan for operations, upgrades and support before you commit. Use the written answers from both vendors and your own environment to compare them, rather than relying on marketing claims.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Atlan vs OpenMetadata, we start with a written scope that tests your metadata, connector and access requirements before any platform decision is made.
How we scope
- Inventory which sources, warehouses and BI tools must be cataloged and which connectors each one needs.
- Document where metadata, glossaries and lineage must reside to meet your residency and network rules.
- Agree deliverables, timelines and fixed scope in writing before any build work begins.
How we build
- Deploy OpenMetadata on your chosen Kubernetes, bare metal or Docker environment with its database and search services.
- Configure ingestion, SSO and role-based access, and test connectors against representative sources.
- Test lineage, glossary terms and data quality workflows with your stewards before any team is onboarded.
How we hand over
- Deliver architecture, configuration, runbooks and an export plan for moving glossaries and ownership out of Atlan.
- Run a parallel validation period where your team compares catalog content against the current tool.
- Train administrators and stewards on connector maintenance, upgrades and the 2.x breaking changes.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan upgrade windows and back up the metadata store before each OpenMetadata version change.
- Confirm with the vendor or your own environment which features need a paid Collate tier.
