Migrate from Google Cloud Dataplex to OpenMetadata

This option freezes Dataplex as the record of what was published before the migration started. Stewards stop editing entries, glossary terms and aspects there, and OpenMetadata is loaded from the metadata export and then becomes the only place where new changes are made. It is the simplest model for stewards because there is never a question about which copy is current, but it leaves consumers who still depend on Dataplex search and tags working from a snapshot until they are moved.

• Clear ownership: Stewards know that all edits happen in OpenMetadata from a fixed date, so reconciliation work is limited to one direction.
• Snapshot drift for consumers: Anyone reading Dataplex during the freeze sees older descriptions, so tell analysts and application owners where the new catalog lives before the freeze begins.
• Export as the reference point: Record the export timestamp and scope, so later comparisons check against the same snapshot rather than a moving target.
• Fewer overlap costs: Fewer Dataplex scans and syncs run during a freeze, which may lower spend, but confirm this against your own billing and scan schedule.
• Rollback difficulty: If OpenMetadata proves incomplete, returning to Dataplex means re-applying any changes made during the freeze by hand.

Before freezing, confirm with Google Cloud how scan and export charges are billed for your organization and which teams rely on Dataplex for policy tags or search.

This option keeps both catalogs editable for a defined window and requires stewards to publish each glossary term, description and classification change to both systems. It suits organizations where Dataplex users cannot switch on a fixed date, but it is the option most likely to produce conflicting metadata, because a change made in one catalog is easy to miss in the other. The window needs a stated end date and a named owner for each glossary area.

• Defined window: Agree the start and end of dual publishing in writing, and record which terms are in scope.
• Named source for each term: Mark one catalog as authoritative for each glossary area, even while both accept edits.
• Reconciliation checks: Run a comparison of glossary terms, owners and classifications between the two catalogs at a fixed interval and log each difference.
• Higher operating effort: Stewards do the work twice for the length of the window, which is a labor cost that depends on how often metadata changes.
• Custom properties mapping: Map Dataplex aspect types to OpenMetadata custom properties and classifications before the first dual publish, so the same field is not written under two different names.

Ask your steward team how many glossary changes they expect per week, since that volume drives the effort of dual publishing more than the length of the window does.

This option moves one business domain at a time, such as finance datasets or customer data, so each domain has a single source of truth at all times. Once a domain is cut over, its stewards edit only in OpenMetadata and Dataplex stops being updated for that domain. Domains with the fewest downstream dependencies are usually the safest first moves, and the order should be set by the business owners rather than by the platform team alone.

• One source per domain: Each domain has one authoritative catalog at any point, which keeps steward workflows simple.
• Staged ingestion: Connect and validate the BigQuery and other source connectors for one domain before starting the next.
• Dependency mapping: List which dashboards, policy tags and access processes rely on each domain before scheduling its cut over.
• Longer total overlap: The full migration can run for many weeks or months, so Dataplex scan and export costs recur for longer than in a single cut over, and this is the main cost to model.
• Mixed user experience: Users must know which catalog holds which domain, so publish a current map and keep it updated during the rollout.

For each domain, ask the vendor or your Google Cloud account team to confirm what Dataplex scans and exports cost during the overlap, and whether those charges change if scope is narrowed by project or entry group.

When one Google Cloud project holds most of the data and BigQuery is the only engine in use, the migration is mostly a connector exercise. OpenMetadata's BigQuery connector can pull tables, columns, schemas and usage into the new catalog, so the metadata that Dataplex derives automatically is rebuilt from the source rather than copied. The work that remains is the curated layer: descriptions, owners, tags and glossary links that people added by hand in Dataplex. That content is the part to export and review carefully.

• Connector first: Configure the BigQuery connector against the project, confirm the service account has read access to metadata, and run a test ingestion before loading anything else.
• Curated fields second: Use the metadata export job to pull descriptions and tags into a working file, then map them onto OpenMetadata assets with a script you can rerun.
• Glossary as a small set: A single project usually has a short glossary, so load it by hand or from a spreadsheet and check term names against existing descriptions.
• Policy tags need a decision: Confirm whether BigQuery policy tags stay in Google Cloud for column-level access control, since OpenMetadata classifications describe data without enforcing it.
• Cutover is short: Run both catalogs in parallel for a fixed review window, then retire the Dataplex view once owners confirm their assets.

Before you start, confirm with your team which BigQuery datasets are actively used, because stale datasets add review work without adding value.

An organization with many projects usually has glossaries, entry groups and policy tags spread across teams. Here the sequence matters more than the connector count. Governance decisions, such as who owns a glossary term and which domain a dataset belongs to, must be settled before content is loaded, otherwise the new catalog reproduces the inconsistencies of the old one.

• Inventory before loading: List every project in scope, its owners and the glossaries and entry groups attached to it, and mark which assets are authoritative.
• Domains before connectors: Define OpenMetadata domains and ownership rules first, then ingest project by project so each source lands in the right domain.
• Glossary mapping: Translate Dataplex glossary terms into OpenMetadata glossaries, deciding which terms are shared and which belong to one business unit.
• Classifications over policy tags: Map sensitivity labels to OpenMetadata classifications for discovery and review, and keep enforcement in the Google Cloud policy layer where it already runs.
• Owner sign-off per domain: Ask each domain owner to approve their imported descriptions before the old catalog is retired.

Confirm with your Google Cloud administrators which policy tags and IAM bindings must remain untouched, since changing them during the catalog move can affect access to live data.

When data also sits in AWS, Azure or on-premises databases, Dataplex covers only part of the picture, and the migration becomes a consolidation project. OpenMetadata's connector catalog lets you bring those sources into one self-hosted instance, but each source needs its own credentials, network path and ingestion schedule. Plan the network and identity design before you choose which systems to bring over first.

• Source-by-source plan: Rank sources by business value and by how often people search them, then ingest the most used ones first.
• Network placement: Decide where OpenMetadata runs relative to each source, because connectors must reach databases and cloud APIs from the ingestion environment.
• Credentials and rotation: Store connector credentials in your secrets manager and confirm rotation procedures for each cloud and database.
• Lineage gaps: Cross-cloud lineage depends on the connectors and OpenLineage events you configure, so test lineage paths that cross platforms rather than assuming them.
• Unified ownership: Agree on a single owner per domain across clouds so the catalog does not split into one team's view per provider.

Confirm the exact connector list for each source type in the current OpenMetadata release notes before scoping, since connector coverage changes between versions.

Organizations with strict data residency or restricted networks often need the catalog to stay inside their own boundary, including the metadata about sensitive datasets. In this case the migration sequence is set by the security architecture: where the catalog runs, how it authenticates users and how the audit trail of changes is kept. The metadata itself can describe regulated data, so the catalog is part of your control scope.

• Deployment target first: Choose between Kubernetes and bare metal, based on the platform your operators already support, and size the database and search services accordingly.
• Access model: Define roles and SSO integration before any users are onboarded, and review the security documentation for authentication options.
• Export handling: Treat metadata exports as sensitive files, store them in controlled locations and delete working copies when the migration ends.
• Evidence trail: Keep records of who approved each import and each glossary change, since these records support later compliance reviews.
• Upgrade planning: Schedule upgrades with the release notes in hand, because breaking changes between major versions require preparation.

Ask your security and compliance teams which controls the catalog must satisfy, and confirm with an independent assessor how those controls will be evidenced.