What OpenMetadata upgrades and support involve
An installed OpenMetadata catalog needs a repeatable upgrade routine, not a one-time install. OpenMetadata 2.0.0 was released on August 24, 2026, and maintenance releases 2.0.1 to 2.0.5 have followed roughly every one to two weeks. Treat the upgrade cycle as an operating task with a named owner, a staging environment and a rollback plan from the first day of production.
Four triggers should start the routine. A new release with breaking changes, such as the 2.0 changes to embedding credentials and the Databricks authentication format, needs planning and testing before cutover. A patch for a security or stability issue needs a fast path through staging. A connector change can alter how metadata is pulled from a source and must be regression tested. An expiring dependency, such as the Java, database, search or Python runtime versions the release depends on, needs a scheduled window before support lapses.
In-house or partner is mostly a question of staff and scope. Teams that already run a Kubernetes or bare metal platform, manage PostgreSQL or MySQL, and have data engineers who own ingestion can usually handle routine patches themselves. Major upgrades, such as the move to 2.0, and custom ingestion images, which must be rebuilt for the Python 3.12 and Apache Airflow 3.3.0 baseline, often go to a partner. Confirm with your own team which of these skills you already have before deciding.
What the service includes
Scope is agreed in writing before work starts, and the deliverables for each item are listed on its card. Confirm which items your quote covers before you sign.
Upgrade plan and compatibility review
Before any version change, we compare your current OpenMetadata release, deployment target and connector list with the target release notes. For 2.0, this includes breaking changes such as the llmConfiguration block for embedding credentials, the new Databricks auth format and the Great Expectations 1.3 migration. The deliverable is a written plan listing each change, its owner and what must be verified.
Backup and restore testing
We confirm that the metadata database and search index can be backed up and restored into a separate environment. The restored instance must return the same assets, lineage, owners and test definitions before an upgrade proceeds. Ask which database and search services your installation uses, because backup procedures differ between MySQL, PostgreSQL, Elasticsearch and OpenSearch.
Custom ingestion image rebuilds
If your ingestion images add custom connectors, libraries or certificates, they must be rebuilt for the Python 3.12 and Apache Airflow 3.3.0 baseline that OpenMetadata 2.0 uses. We rebuild each image, pin its dependencies and run it against your pipelines. Ask how image versions are tagged and stored, since that determines how quickly you can adopt a maintenance release.
Connector regression testing
We run every connector on your list against the upgraded release and compare ingested entities, lineage, profiler output and test results with the pre-upgrade baseline. Connectors that rely on third-party drivers or specific source versions receive closer checks. Provide the connector list and source versions early, because they define the test matrix and the effort.
Staged upgrade runs and runbooks
Upgrades run in staging first, then in production, each following a written runbook with a go or no-go checkpoint. Rollback steps for the application, database and search state are rehearsed before cutover. Runbooks and operator documentation are handed over so your team can repeat patch and minor upgrades. Confirm your change window and approval process before scheduling.
Ongoing support under a retainer
After 2.0.0, maintenance releases 2.0.1 to 2.0.5 followed about every one to two weeks, so patch intake is continuous. A retainer covers reviewing each maintenance release, scheduling upgrades, rerunning connector tests and answering operational questions. Agree response expectations and the upgrades included in writing before the retainer starts.
What drives cost and duration
This table lists the factors that change the effort of an OpenMetadata upgrade or support engagement, why each one matters and how to keep it under control.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Installed version and distance from target | Moving from an older 1.x install to 2.0 crosses the breaking changes in one step, so the further behind the install is, the more migration work is needed before cutover. | Keep the install on a recent maintenance line and plan regular patch adoption rather than large jumps. |
| Number and type of connectors | OpenMetadata lists more than 130 connectors, and each one enabled in your environment needs its own configuration, credentials and regression check after an upgrade. | Enable only the connectors you use and document which ones are in scope for regression testing. |
| Custom ingestion images and custom connectors | Custom images must be rebuilt for the ingestion runtime changes in 2.0, including Python 3.12 and Apache Airflow 3.3.0, and custom connectors need their own testing. | Keep custom code minimal, pin dependencies, and script image rebuilds so each release reuses the same pipeline. |
| Breaking-change exposure in 2.0 | Embedding credentials move into an llmConfiguration block, Databricks uses a new auth format, and Great Expectations must migrate to 1.3 before upgrading. | Inventory which of these features you use before the upgrade window and complete those changes in a non-production environment first. |
| Deployment target | Kubernetes deployments use the published Helm and container workflow, while bare metal needs Java 21, a supported MySQL or PostgreSQL database and Elasticsearch 9.x or OpenSearch 3.x managed by your team. | Confirm the target platform early and standardize on one deployment model across environments to reduce variance. |
| Environments and change windows | Each environment (development, test, staging, production) needs its own upgrade run, and the number of approved change windows limits how fast patches can land. | Use the same runbook in every environment and agree standing windows for the frequent maintenance releases. |
| Backup and restore evidence required | Your change board or assessor may require a tested restore from a backup taken before the upgrade, not just a successful backup job. | Automate pre-upgrade backups and schedule a restore test on a copy of the database and search index. |
| Compliance evidence requests | Auditors and internal reviewers may ask for change records, test results, version history and access reviews for each upgrade, which adds documentation work to every cycle. | Agree the evidence list at the start and generate it from each upgrade run so it does not need to be assembled by hand. |
How an upgrade engagement runs
The sequence moves an OpenMetadata installation from its current release to a target release with inventoried custom components, tested connectors, rehearsed recovery and a patch routine the client can run after handover.
Inventory versions and custom components
DeployOpen records the running OpenMetadata version, deployment target (Kubernetes or bare metal), database and search service versions, every ingestion connector in use, custom ingestion images and any custom configuration. The client receives a written version inventory they can check against the release notes. The step closes when the client confirms the inventory is complete.
Assess compatibility and breaking changes
DeployOpen compares the current install against the target release notes, including the 2.0 breaking changes such as the llmConfiguration block for embedding credentials, the new Databricks auth format, Python 3.12 image rebuilds and the Great Expectations 1.3 migration. The client receives a written impact list with each item marked as required before upgrade, required before cutover, or not applicable. The step closes when the client signs off the list.
Build and test the staging environment
DeployOpen stands up a staging copy of the production stack, upgrades it to the target release, and rebuilds custom ingestion images against the required Python and Airflow versions. The client receives a working staging environment, rebuilt images with recorded versions and a list of configuration changes made. The step closes when staging starts cleanly and the rebuilt images are stored in the client's registry.
Run connector regression tests
DeployOpen runs each connector in use against the staging release and compares ingested metadata, lineage, profiling and data quality results with the pre-upgrade baseline. The client receives a regression report listing passing connectors, differences and any open defects with owners. The step closes when every connector in scope passes or each exception has an agreed fix or accepted risk.
Rehearse backup and restore
DeployOpen takes a backup of the database and search index, restores it into an isolated environment and confirms the catalog, lineage and ownership data are intact after the restore. The client receives a documented restore procedure with the commands or steps used and a record of the measured restore results. The step closes when the restore reproduces the expected catalog state.
Cut over to production with rollback criteria
DeployOpen runs the production upgrade in the agreed window using the rehearsed steps, then checks services, ingestion schedules and sample connector runs. Rollback criteria are agreed in writing before cutover, so the team knows which failures trigger a restore. The client receives a cutover record, post-upgrade checks and the rollback decision log. The step closes when the agreed checks pass and the client accepts the release in production.
Hand over with a recurring patch routine
DeployOpen documents the upgrade runbook, image rebuild steps, regression test scripts and monitoring checks, then trains the client's operators on them. The agreed patch routine covers how maintenance releases are reviewed and applied, and whether that work stays with the client or moves to a retainer. The client receives the runbook, the routine and a named support path. The step closes when the client's team runs one patch cycle with DeployOpen observing or confirms the routine in writing.
What usually goes wrong
Most OpenMetadata upgrade problems come from a small set of known changes and skipped checks. Each card names one risk and the step that prevents it.
Custom ingestion images fail on Python 3.12
OpenMetadata 2.0 moved ingestion images to Python 3.12 with Apache Airflow 3.3.0, so custom ingestion images built on the older base can fail at startup or when a connector loads. Rebuild every custom image on the 2.0 base in a staging environment, then run one pipeline per connector before anything reaches production.
Connectors change behavior silently
A connector can keep running after an upgrade while returning different metadata, such as altered field mappings, lineage edges or profiler results. Keep a fixed set of source fixtures and compare catalog output before and after each upgrade, paying close attention to the 2.0 change that made Dynamic Sampling the profiler default.
Pre-2.0 migrations skipped
Two 2.0 breaking changes need work before cutover: migrating Great Expectations to 1.3 and moving embedding credentials into the llmConfiguration block. Skipping either can leave data quality tests or AI features broken after the upgrade. Inventory both in your configuration and test them against a restored copy first.
Restores never tested
Teams often back up the metadata database and search index without ever restoring them. A backup that has never been restored cannot be trusted to roll back a failed upgrade. Restore to a separate environment on a schedule and confirm that the catalog loads, lineage displays and search returns expected results.
Search and database version mismatches
Bare metal deployments require Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. A database or search service that drifts below these versions during an operating system or infrastructure update can block the server after an upgrade. Compare each component against the documented prerequisites before every release.
Patch fatigue leaves releases unapplied
Maintenance releases 2.0.1 through 2.0.5 followed the 2.0.0 release at roughly one to two week intervals. Teams that defer them accumulate several releases and then face a larger, riskier jump. Agree a patch window, a named owner for release review and a maximum gap between production and the current release.
Recurring costs after go-live
This table lists each recurring cost after go-live, what it covers and what to request in a quote, so you can compare running OpenMetadata with your own team against a partner-supported model.
| Component | What it covers | What to ask in a quote |
|---|---|---|
| Server hosting | Runs the OpenMetadata server at the documented bare metal minimum of 2 vCPUs, 4 GB RAM and 20 GB storage, then grows with users and ingestion load. | Instance sizes, number of server replicas, and whether the quote assumes Kubernetes or bare metal. |
| Database and search hosting | PostgreSQL 15 or MySQL 8.0.42 or later, plus Elasticsearch 9.x or OpenSearch 3.x. Each starts at 2 vCPUs, 2 GB RAM and 30 GB storage. | Whether these are managed or self-run, storage growth assumptions, and high availability nodes included or excluded. |
| Backup storage | Database snapshots and configuration backups for restore testing. Storage grows with retention period and metadata volume. | Retention period, backup location, restore test frequency, and who performs restore drills. |
| Patch and release routine | Applying OpenMetadata 2.0.x maintenance releases, which have followed about every one to two weeks, after testing in a staging environment. | Staging scope, who tests each patch, and the rollback window covered by the agreement. |
| Connector maintenance | Keeping connector versions and source credentials working as warehouses, BI tools and pipelines change. OpenMetadata lists more than 130 connectors. | Number of connectors in scope, regression test coverage, and who handles source API changes. |
| Ingestion image rebuilds | Rebuilding custom ingestion images for Python 3.12 and Apache Airflow 3.3.0 in 2.0, then again whenever base images change. | Rebuild frequency, base image pinning policy, and the registry where images are stored. |
| Support retainer | Ongoing access to engineers for incidents, upgrades and questions, usually as a recurring agreement rather than a one-off project. | Written response expectations, upgrades included, coverage hours, and how stand-by work is billed. |
| Internal staff time | Data stewards maintain glossary, ownership and quality rules. Platform engineers handle upgrades, monitoring, backups and access reviews. | Estimated hours per month for each role, based on the connectors, domains and users in scope. |
| Collate commercial offering | The Apache License 2.0 release is self-hosted. Collate, which maintains OpenMetadata, offers commercial enterprise capabilities and premium support as a separate line. | Which enterprise capabilities and support tier are included, and whether your scope requires them. |
How the work changes by starting point
A new install starts on 2.0.0, released August 24, 2026, so there is no upgrade path to plan. The work is choosing the target version, sizing services and setting the baseline you will patch from.
- Pin the version: Start on the latest 2.0.x maintenance release available at install time and record it in your change log.
- Build ingestion images on Python 3.12: Custom connector images need to target the Python 3.12 and Apache Airflow 3.3.0 base from the start.
- Review 2.0 defaults: Dynamic Sampling is the profiler default and MCP is enabled by default, so confirm both match your policy before connecting sources.
- Check sizing: Confirm the server, database and search services meet the documented minimums before loading data.
*Usually owned by:* the platform team for installation, with the data governance owner setting defaults.
An upgrade from an earlier 1.x install carries the 2.0 breaking changes, so most of the work happens before the version change. Data movement and cutover planning are covered in the migration topic.
- Move embedding credentials: Place them in the llmConfiguration block before the server starts on 2.0.
- Update Databricks auth: Convert any Databricks connector to the new authentication format.
- Migrate Great Expectations to 1.3: The 2.0 release notes list this as a step to complete before upgrading.
- Rebuild custom ingestion images: Rebuild for Python 3.12 and retest every custom connector against a sample source.
- Back up first: Take a restore-tested backup of the database and search index before the change window.
*Usually owned by:* platform engineering for the cutover, with each connector owner confirming their pipelines pass.
Kubernetes deployments follow the same application upgrade, but the cluster layer changes with the platform. Confirm the chart or manifest version that matches your target release before any cluster change.
- Managed control planes: EKS, AKS and GKE each set their own Kubernetes version, node image and add-on upgrade windows, which must be sequenced with the OpenMetadata release.
- On-premises clusters: Ingress, storage classes and certificate issuers are your responsibility, and the platform team should verify them before the server upgrade.
- External database and search: Confirm connection details, secret rotation and version compatibility against the 2.0 release notes.
- Ingestion workloads: Verify that scheduled ingestion picks up the rebuilt Python 3.12 images after rollout.
*Usually owned by:* the cluster team for Kubernetes upgrades, and the data platform team for the OpenMetadata release.
A bare metal install runs the OpenMetadata server directly on hosts, with the database and search services deployed as separate components. Runtime and version checks come first, because a mismatch usually shows up at startup.
- Java 21: Confirm the runtime on every server node before the upgrade begins.
- Database: Use MySQL 8.0.42 or later, or PostgreSQL 15 or later, and confirm the database upgrade order with your DBA.
- Search: Use Elasticsearch 9.x or OpenSearch 3.x, and check index health after the server restarts.
- Sizing: The server needs at least 2 vCPUs, 4 GB RAM and 20 GB storage, and each of the database and search services needs at least 2 vCPUs, 2 GB RAM and 30 GB storage.
*Usually owned by:* systems administrators for hosts and runtimes, and the database administrator for database upgrades.
In an air-gapped or restricted network, the upgrade depends on bringing release packages, container images and Python dependencies in through approved routes. Confirm the full artifact list for your target release before the change window opens.
- Artifact transfer: Plan how packages and images enter the network and how they pass your intake scanning and approval process.
- Offline image builds: Custom ingestion images must build from an internal mirror that holds the Python 3.12 and Apache Airflow 3.3.0 dependencies.
- Source reachability: Confirm which metadata sources each connector can reach, since restricted routes can block ingestion runs.
- Vendor procedure: Ask Collate or the OpenMetadata documentation for the offline procedure that applies to your release and deployment model.
*Usually owned by:* security and network teams for transfer approvals, and the platform team for execution.
What you need to provide
Before any upgrade work starts, the upgrade team needs a complete picture of what is running today. Provide the current OpenMetadata version, the deployment target (Kubernetes or bare metal), and an inventory of every server, database, search service and ingestion runner that touches the catalog. Confirm which connectors are live, which ones are scheduled, and which run from custom ingestion images. Access to staging and production should be agreed in writing, with named accounts for the people who will run the work and a rollback path that does not depend on one individual.
Ask for read access to the metadata database and the search service, and for a bot or service account with the permissions needed to inspect connector configuration. Connector credentials for regression testing should be issued under least privilege, scoped to read-only queries on the sources under test, and rotated after the engagement. Share the list of custom ingestion images with the team that owns each one, including the build pipeline, base image and Python version. Where those images were built for an earlier release, confirm who will authorize a rebuild.
Confirm the backup storage location, the retention policy and who can restore from it. Agree the maintenance windows, the change approval path and the people who sign off a production change. Name the owners for data quality rules and catalog decisions, including who accepts a failed test, who resolves a broken lineage edge and who decides when a deprecated connector is retired.
Unclear connector ownership usually delays the first upgrade more than the technical work. When nobody can say who owns a Snowflake or dbt connector, who can approve a credential change, or whether a team still uses a dashboard source, the regression run stalls while questions are routed. Settle these owners before the schedule is set. Illustrative example: an ingestion image built by a team that has since reorganized needs a new owner before anyone can approve its rebuild for the release in use.
Frequently asked questions
How much does an OpenMetadata upgrade cost?
The cost depends on the written scope, and DeployOpen does not publish a price list. The main cost drivers are the version gap being crossed, the number of connectors and custom ingestion images that need rebuilding and regression testing, the deployment target (Kubernetes or bare metal), and the depth of backup and restore verification. Ask for a quote that separates one-time work, such as the upgrade and its rehearsal, from recurring work, such as patch cycles and support hours. Also ask which items are fixed in scope and which would be handled as change requests.
How long does an OpenMetadata upgrade take?
Duration depends mainly on how many releases separate your installed version from the target, and on how many connectors and custom ingestion images must be tested. Upgrades that cross into the 2.0 line carry more work because of its breaking changes. OpenMetadata 2.0.0 was released on August 24, 2026, and maintenance releases 2.0.1 to 2.0.5 followed about every one to two weeks, so the target version may change during planning. Ask for a timeline in the written scope that names the staging rehearsal, the cutover window and the rollback point.
Can our own team upgrade OpenMetadata without an outside partner?
Yes, if your team has the skills and capacity to run the upgrade. The work touches the application, the database, the search service and every ingestion image, so the team needs operations experience for your deployment target, Python packaging knowledge and a tested backup and restore path. OpenMetadata's bare metal documentation lists Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x as prerequisites. Assess whether your team can build and keep a runbook current across releases, since patch cadence is what makes upgrades a recurring task.
What breaking changes does OpenMetadata 2.0 require us to handle?
OpenMetadata 2.0 changes several settings and build steps that must be ready before the server moves. The documented breaking changes include moving embedding credentials into an llmConfiguration block, a new Databricks authentication format, rebuilding custom ingestion images for Python 3.12, and migrating Great Expectations to 1.3 before upgrading. Ingestion images also move to Apache Airflow 3.3.0. Ask the implementer to inventory every custom image, connector credential and Great Expectations usage, and to test each one in staging against a copy of your production metadata.
How often should OpenMetadata patches be applied in production?
Patches should follow a set cadence that your team can test and roll back, with urgent security fixes handled out of cycle. OpenMetadata 2.0 maintenance releases 2.0.1 to 2.0.5 followed about every one to two weeks after 2.0.0, so a fixed review window is one option to discuss. Each patch cycle should include a fresh backup, connector regression checks and an approval step. Define in the written scope who reviews release notes, who approves changes and how backup restores are tested. Confirm the cadence against your change management and security policies.
How does a retainer differ from a fixed-scope upgrade?
A fixed-scope upgrade delivers agreed work with set deliverables and an end point, such as one version move with verified backups and connector regression results. A retainer covers ongoing capacity over an agreed period, typically patch planning, upgrade work, support requests and recurring connector testing, with response terms set in writing. DeployOpen offers both, and support covers the agreed platform only. Confirm in writing what is excluded, such as new connectors, custom feature development, identity provider changes or work outside the agreed OpenMetadata version.
How DeployOpen delivers this service
DeployOpen plans, implements, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, so OpenMetadata upgrades follow a written plan for your deployment target and connector set.
How we scope
- The written scope names your OpenMetadata version, deployment target and the connectors that need regression coverage.
- Scope lists custom ingestion images, Python and Airflow dependencies, and any custom connectors that must be rebuilt for each release.
- Most engagements are fixed-scope, so deliverables, timelines and responsibilities are agreed in writing before upgrade work starts.
How we build
- We take a verified backup of the metadata database and search index before any upgrade step begins in a staging copy.
- We review breaking changes for your target release, such as embedding credential moves and Great Expectations migration, and plan each change.
- We rebuild custom ingestion images and run connector regression tests against your sources, then record pass and fail results per connector.
How we hand over
- You receive the upgrade runbook, rollback steps and restore procedure written for your environment and tested during the engagement.
- Handover covers rebuilt ingestion images, configuration changes, version pins and the list of connectors verified for each release.
- Operating notes explain how to review new maintenance releases, what to test after each patch and who approves production changes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped to your release cadence and connector list.
- A retainer can cover monitoring of new OpenMetadata maintenance releases and planned patch windows agreed with your team.
- Confirm with DeployOpen during scoping which support hours, response channels and escalation paths the retainer includes.
