OpenMetadata 1.x to 2.0 upgrade

Start by checking your host stack against the documented bare metal prerequisites for OpenMetadata. The listed requirements are Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later as the database, and Elasticsearch 9.x or OpenSearch 3.x as the search service. Check every node that runs the OpenMetadata server, the database and the search service, because a single host on an older Java runtime can block the upgrade or surface as a fault later. Record the exact version each component reports, not the version listed in your deployment template. Then confirm with the 2.0 release documentation which of these prerequisites apply to the 2.0 line in your environment. The bare metal page describes current deployment guidance, so verify it against the release you plan to run.

The documented minimum server sizing is 2 vCPUs, 4 GB RAM and 20 GB storage for the OpenMetadata server. The database and search services each need at least 2 vCPUs, 2 GB RAM and 30 GB storage. Treat these figures as floors that show whether a host can run the stack at all, not as a capacity plan. Actual needs depend on how much metadata you hold, how many connectors run ingestion, and whether profiling and data quality tests run against large tables. Compare each host's current allocation with the floor, then ask your platform team to project storage growth for the database and search indices over the next planning cycle. Undersized search nodes can slow reindexing, which is one of the longer steps in the upgrade window.

Many teams running 1.x will find at least one component below the listed minimum. Compare each database and search version with the requirements. If either is older, plan its upgrade as a separate change with its own backup, rollback point and test window before the OpenMetadata 2.0 upgrade begins. Combining a database or search upgrade with the application upgrade makes it hard to tell which change caused a fault. Also confirm the search engine family. Elasticsearch 9.x and OpenSearch 3.x are the named options, so an Elasticsearch 8.x cluster or an earlier OpenSearch line needs its own planned upgrade before the OpenMetadata change window opens. Check that each engine's vendor upgrade guidance supports the path from your current version to the target.

Confirm the deployment model before you act on any figure. Kubernetes and Docker deployments follow their own documented requirements, so the bare metal numbers in this section do not transfer directly to a cluster or container host. If you run on Kubernetes, pull the requirements for that model and check node sizing, persistent volumes and any managed database or search service you attach. Then build a compatibility matrix with one row per host or service, listing component, current version, required version for 2.0, owner and approval. Mark any row you cannot verify as open. Leave this step with a dated decision on each open row, because a prerequisite that is still unknown on the day of the upgrade often becomes the reason the change is postponed.

Custom ingestion images must be rebuilt for OpenMetadata 2.0 instead of being carried over from the 1.x build. The 2.0 release moved ingestion images to Python 3.12 with Apache Airflow 3.3.0, and the breaking-change list names rebuilding custom ingestion images for Python 3.12 as a required step. Treat every image that bundles connector packages, custom transformers or private Python libraries as stale until a new build passes its checks. Start with an inventory of each image your pipelines reference, including images in a private registry and images built inside CI jobs. For each one, record the base image, the Python and Airflow versions, and every added package with its pinned version. Confirm the base image tags and package compatibility against the 2.0 release notes and against your own pipeline definitions before the first build. If you use Great Expectations, confirm that your migration to 1.3 is complete before you upgrade the server, because that migration is listed as a prerequisite.

The reindex runs against your search service, which must be Elasticsearch 9.x or OpenSearch 3.x according to the bare metal prerequisites. Plan for search to be degraded or unavailable while the index is rebuilt, and confirm with the 2.0 release notes and your deployment documentation which user-facing search, lineage and API queries keep working during the run. Reindex load comes from reading every entity and writing a new index, so it competes with the search nodes' CPU, heap and disk. The documented minimum sizing for the search service is 2 vCPUs, 2 GB RAM and 30 GB storage, which is a floor for running the service, not a sizing for a full rebuild of your catalog. Before you start, take a snapshot of the existing index so you can roll back, confirm free disk for the new index alongside the old one, and watch heap, disk and queue metrics during the run. Ask Collate or your implementation partner for a reindex duration measured on a copy of your catalog, and do not schedule the window from an estimate.

Pipeline redeployment should be sequenced so that no scheduled run reads a catalog that is partly migrated. Pause all scheduled metadata ingestion, profiling and data quality workflows before the database migration starts, and keep them paused until the reindex has finished and the catalog has been checked. Once the server is upgraded and the search index is complete, deploy the new images and redeploy metadata ingestion first, because profiling and tests depend on the entities it creates and updates. Redeploy profiling second and data quality tests last. Check that each workflow still references its connection, service and entity names in the form the 2.0 server expects, since a workflow that points at a missing or renamed entity will fail for reasons that look like test failures. Re-enable schedules in stages, not all at once, and review the first run of each workflow in its logs before you move to the next one. Record the order and the result of each step so that a failed run can be traced to a specific change.

Dynamic Sampling is now the profiler default in OpenMetadata 2.0, so existing profiling schedules may produce different results after the upgrade. Review each profiler workflow to see whether it sets sample size, sample percentage or row limits explicitly, or whether it inherits defaults, and review any table-level overrides in the same way. Confirm in the 2.0 documentation and in your own configuration exactly what changes for schedules that inherit the default and what happens to schedules that set a value. Then run the profiler on a few representative tables in a non-production copy, once with the old settings and once with the new, and compare row counts, null ratios and distinct counts. Data quality tests with thresholds on profile metrics can change status when the sampled values change, so treat any test that flips after the change as a finding to resolve before you re-enable its schedule. Document the settings you decide to keep, because the next upgrade will need the same comparison.

The upgrade is complete only when the teams that depend on the catalog can keep working in it. Before cutover, write a test plan that names an owner for each consumer and a pass condition for each check, and run it against a staging copy restored from production backups. Start with the people who call OpenMetadata directly: REST API clients, Python, TypeScript and Java SDK scripts, and internal tooling built on them. Run each script against 2.0 and record every call that changes behavior. The release notes list breaking changes in the API and data model, and a server that starts cleanly will not reveal them. Ask each team to supply its own scripts and expected outputs, because DeployOpen cannot judge their business logic from outside your organization.

Next, test ingestion for every connector in use, not a sample. Custom ingestion images must be rebuilt for Python 3.12, and the workflows must run on the Apache Airflow version that ships with 2.0. Trigger each connector and compare entity counts, schema changes and ownership assignments with the 1.x baseline. Lineage needs its own check. Confirm that OpenLineage events from your pipelines still arrive, that table, column, dashboard, pipeline and metric lineage render, and that lineage edges created by hand survive the upgrade. Data quality tests and freshness checks should produce the same pass and fail results as before. Any Great Expectations suite must already run on 1.3 before this step begins, so verify that during planning rather than during the test window.

Then test sign-in and search. Sign in through each configured SSO provider, and confirm that no required account depends on basic authentication, because OpenMetadata does not support combining SSO with basic authentication. After reindexing, check that search returns the same tables, dashboards, owners, glossary terms and domains as the 1.x catalog, and spot-check assets that were recently edited. Time the reindex on a copy of production data volume so the cutover window rests on your own measurements. Also confirm that the Context Center and any custom intake forms behave as your governance team expects, because users will see them on the first day.

Decide the rollback trigger before cutover and write it down with the people who are authorized to call it. A rollback means restoring the database snapshot and the search snapshot taken immediately before the upgrade, then redeploying the 1.x images. Both snapshots must come from the same point in time, or search will reference assets the database no longer holds. Metadata edited during the window after cutover is the hardest part. Changes made in 2.0 are lost when you restore the pre-upgrade snapshot unless you export them first, and any consumer that wrote to the catalog in that period must be told. Confirm with OpenMetadata's upgrade documentation whether the schema changes can be reversed, and confirm with your backup vendor that the restore works with your own tooling.

Rehearse the full rollback in staging before production, and time it from the first step to the moment users can read the catalog again. Include the redeployment of the 1.x ingestion images and the reconnection of SSO in the rehearsal. Record who signs off the decision, how long the catalog will be read-only, and who notifies consuming teams. The rehearsal results, not an estimate from this page, should set the change window you commit to with the business.