What OpenMetadata customization covers
Customization in OpenMetadata means extending the catalog's data model and workflows through the product's own extension points, so the platform can be upgraded without carrying a fork. In practice that covers custom entity properties on core assets, classifications and tags that reflect your policies, custom intake forms (added in OpenMetadata 2.0) that let stewards collect structured information, custom connectors built on the Python SDK for sources the project does not cover, and API-driven automation that uses the REST APIs, Python SDK, TypeScript packages or Java libraries. Each of these lives in configuration, code you own, or scripts outside the project source.
Teams usually arrive here for a specific reason. A glossary model may not fit the default fields for terms, owners or domains. A steward process may need structured intake, such as a request form for a new dataset, instead of free-text comments. Or a source system that matters to your governance has no connector, so its metadata has to be pushed in through the API. Confirm your target version against the OpenMetadata 2.0 release notes before designing forms, because intake forms and some extension behavior depend on it.
Most teams can make small configuration changes in-house, such as adding a property, creating a classification or tuning a tag hierarchy. Larger connector or workflow builds are different. They need Python or Java skills, a test environment that mirrors your sources, and time to maintain the code through each release. When your internal team lacks that time or those skills, a partner often takes the build, but the decision should rest on a written scope that names the connectors, forms and automations involved.
Before you start: list each customization against the business question it answers, then decide which ones must survive upgrades. Anything that changes shared metadata or ingestion code will need regression testing with every OpenMetadata release, so count that ongoing work when comparing options.
What the work includes
Each workstream produces named artifacts that your team keeps after the engagement. Deliverables, acceptance checks and the exact scope are agreed in writing before work starts.
Custom properties on catalog assets
We design the property schema that extends catalog assets such as tables, dashboards and pipelines, covering property types, allowed values, which entity types each property applies to and who may edit it. The deliverable is a documented property schema with examples, plus a check that existing ingestion runs do not overwrite manually entered values. Confirm the property types your OpenMetadata version supports before finalizing the schema.
Classification and tag design
We model classifications and tags for sensitivity, retention and business meaning, and decide how they are applied: manually, by ingestion rules or by propagation through lineage. The deliverable is a tag taxonomy with ownership rules, an application guide for stewards and a test set showing how tags appear on sample assets. Check who may create tags, since uncontrolled tag growth is the most common cleanup cost later.
Custom intake forms for stewards and requesters
We configure intake forms that collect structured information from requesters, such as a new dataset description, a glossary term proposal or an access question, and route the submission to the right steward. The deliverable is the form set with field validation, routing rules and a short guide for approvers. Confirm which form types your target version supports, since OpenMetadata 2.0 added custom intake forms.
Custom connectors with the Python SDK
We build connectors for sources that have no native OpenMetadata connector, using the Python SDK or the ingestion framework. The deliverable is a packaged connector with configuration templates, unit and integration tests against a representative source, and a build procedure. Ask who will rebuild the ingestion image when OpenMetadata or Python versions change, because custom images must be rebuilt during upgrades.
API automation for bulk updates and sync
We script bulk updates and synchronization between OpenMetadata and systems of record such as HR, CMDB or a data dictionary, using the REST APIs or the SDKs. The deliverable is an automation job with idempotent logic, dry-run mode, logging, a scoped bot identity and a runbook covering failure, rollback and rerun. Agree the source of truth for each field before automation writes to it, so the job does not overwrite steward decisions.
What drives cost and duration
This table lists the customization choices that most change OpenMetadata effort, why each one matters and how to keep it contained, so you can ask for effort per item in a written quote.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Custom properties and their types | Each custom property needs a type, a place on the asset types it applies to, validation rules and documentation for stewards. Rich types such as entity references or enums add design and testing work. | Limit properties to fields that drive a decision or report. Prefer simple types and reuse existing fields before adding new ones. |
| Classifications and policy mapping | Every classification must map to a tagging rule, a sensitivity level and the policy that acts on it. Overlapping classifications create conflicting tags and rework. | Agree a short classification set with your data protection owner first. Map each tag to one named policy before building anything. |
| Intake forms and approval paths | Each form needs fields, validation, routing and approvals, and each approval path needs testing with the people who sign off. Multi-step approvals with conditional logic take the longest. | Start with one or two forms on the highest-volume request types. Keep approval chains to the minimum your governance model requires. |
| Custom connectors and source API surface | A connector without a shipped version must be built, tested against the source API, and maintained through source changes. The number of endpoints, pagination rules and authentication methods drives the work. | Check the connector catalog before scoping a custom build. For each source, list only the entities you need to ingest and confirm the API supports them. |
| Number of environments | Development, test and production each need their own OpenMetadata instance, database, search service, ingestion runners and configuration. Changes are promoted and verified in each one. | Keep configuration in version control and promote it through the same steps each time. Use a smaller test environment for most checks. |
| Edition and OpenMetadata version | The open-source release (Apache License 2.0) and Collate's commercial offering differ in what is supplied. Version changes affect APIs, schemas and custom ingestion images, so each release can require rework. | Confirm which features your edition includes before design. Pin one version for the project and plan upgrades as separate work items. |
| Compliance evidence requirements | Assessors may ask for proof that properties, classifications, approvals and access rules operated as documented. Evidence capture, retention and export all add build and test work. | Ask your assessor which evidence they expect and build only that. Collect evidence from the system's own logs and records where possible. |
Project phases and outputs
The sequence moves from understanding the current catalog and its owners to a tested, documented customization that your own team can operate after handover.
Discover the metadata model and owners
We review your current catalog model, entity types, domains, glossary terms and the people who own and steward them, working with your data governance leads. The output is an approved metadata model listing which properties, classifications and forms are needed and who signs off on each.
Design properties, classifications and forms
We specify custom properties, classifications, tag hierarchies and intake forms against the approved model, including field types, validation rules and who can edit each item. The output is a design document that your owners review and accept before any configuration is written.
Build configuration and connectors in a non-production environment
We build the custom properties, classifications, forms and any custom connectors or API automation in a non-production OpenMetadata environment, keeping the work in version control. The output is a versioned configuration set and a connector repository that can be reviewed and redeployed.
Test against a copy of the catalog
We load a copy of your catalog into the test environment and run functional checks on forms, validation, permissions, API calls and connector runs, then fix defects in the versioned set. The output is a test report listing each result, defect and retest, which you review before rollout.
Roll out in a controlled way
We apply the approved configuration to production in a planned change window, verify the same checks on live data and keep a documented rollback path ready until your owners confirm the result. The output is a signed-off change record and a confirmed production state.
Hand over with documentation and runbook
We train your administrators and platform team, then deliver the configuration documentation and a runbook covering change procedures, connector maintenance and upgrade impact on custom items. The output is a handover pack that your team can use to operate and extend the customization without DeployOpen.
What stays in-house and what a partner takes on
This table shows, for each part of an OpenMetadata customization, which work your data stewards and platform team usually keep, which work a partner usually takes on, and the skills each side needs.
| Work area | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Metadata model decisions | Stewards decide which entity attributes, domains and glossary terms the business needs and who owns each definition | Partner documents the options, maps each decision to the configuration it requires and records the outcome | Data governance, business domain knowledge, catalog modeling |
| Property and classification configuration | Stewards approve classification tiers, sensitivity labels and custom property values | Partner creates the custom properties and classifications in the platform and checks how they behave in search and tagging | OpenMetadata administration, data classification practice |
| Intake form design | Data owners define which questions a requester must answer and what counts as a complete request | Partner builds the intake forms, validation rules and routing to the right approvers | OpenMetadata 2.0 intake form configuration, UX review, workflow design |
| Custom connector development | Platform team names the source systems in scope and reviews what metadata each connector should expose | Partner writes and packages connectors in Python or Java against the ingestion framework | Python or Java development, ingestion framework internals, source system APIs |
| API automation | Owners specify which bulk updates, ownership syncs and tagging rules the business wants automated | Partner builds scripts or pipelines using the REST APIs and the Python, TypeScript or Java libraries | REST API design, service authentication, scripting, scheduling |
| Testing | Stewards validate that definitions, tags and ownership match business intent before go-live | Partner writes unit and integration tests for connectors, API jobs and configuration, and runs regression checks | Test automation, test data handling, familiarity with CI pipelines |
| Ongoing connector maintenance | Platform team decides which releases to adopt and approves changes to connector scope | Partner updates connectors when source APIs change and retests them after each OpenMetadata release | Source system API changes, version management, incident response |
| Definitional calls behind the mechanics | Stewards make the final decisions on what terms mean, who is accountable and which data is sensitive | Partner implements those decisions faithfully and flags conflicts or gaps it finds during the build | Clear written requirements, decision logs, stakeholder sign-off |
What usually goes wrong
Most problems in customized OpenMetadata start with small changes that look harmless when they are made, such as a property name, a form setting or a connector import. Each card names a failure mode and the step that prevents it.
Custom properties without a naming standard
Teams often add custom properties with near-identical names, such as cost_center and costCenter, so search and reporting split one attribute into several fields. Before any property is created, agree on naming, data types and the entity types each property applies to, record them in a shared register, and review new properties through the same change process as code.
Classifications that duplicate tags
A team may create a classification for a sensitivity level that already exists as a tag, so the same label is applied two different ways and access policies only catch one of them. Map each proposed classification against existing tags and glossary terms first. Decide which mechanism drives access control and which only describes the asset, then confirm that automated tagging writes to one place.
Intake forms that bypass approval
A custom intake form can be configured to create assets directly, so the form exists but its approval step never runs. This is most likely when a form is published to a broad group or a bot account can create assets. Test each form with a user who lacks approval rights, and confirm who can publish forms and edit the workflow definitions behind them.
Custom connectors broken by minor releases
Custom connectors depend on internal interfaces, and those interfaces can change in a minor release, so a connector that ran successfully before an upgrade may fail afterward. Pin the release each connector was built against, keep its code in version control, and run it against a staging instance on each target release before production. Check the release notes for interface changes before you upgrade.
Ingestion images not rebuilt for Python 3.12
OpenMetadata 2.0 moved ingestion images to Python 3.12 with Apache Airflow 3.3.0, so a custom ingestion image built on an older Python base or with pinned dependencies may fail to start or load its plugins. Rebuild each custom image on the 2.0 base, retest every dependency, and tie the build pipeline to the release version so later rebuilds are repeatable.
2.0 breaking changes missed before upgrade
OpenMetadata 2.0 moves embedding credentials into an llmConfiguration block, introduces a new Databricks auth format, and requires Great Expectations to be migrated to 1.3 before upgrading. Customized deployments that set these values, or custom tests built on Great Expectations, can break at upgrade. Inventory every affected setting and test, then verify each one in staging before cutover.
How the work changes by starting point
A fresh install begins on the 2.0 line, so custom ingestion images and API scripts are built once against the current runtime. Test effort concentrates on new work because no older configuration needs to be carried forward.
- Build: Custom ingestion images target Python 3.12 and Apache Airflow 3.3.0 from the start.
- Design: Custom properties and intake forms can be designed against 2.0 features, including the custom intake forms added in that release.
- Test: Verification covers your own customizations and the connectors you onboard.
- Confirm: Check the 2.0 release notes and the maintenance releases from 2.0.1 to 2.0.5 for fixes that affect your build.
An upgrade from 1.x carries customizations forward, so the effort moves from building to inventorying and regression testing. Each custom component needs review against the 2.0 breaking changes before cutover.
- Inventory: List every custom property, classification, intake form, connector and API script in use.
- Breaking changes: Move embedding credentials into the llmConfiguration block, update Databricks auth to the new format and rebuild custom ingestion images for Python 3.12.
- Prerequisite: Migrate Great Expectations to 1.3 before upgrading.
- Confirm: Use the 2.0 release notes as the authoritative breaking change list and confirm the upgrade order with the vendor documentation.
The OpenMetadata documentation covers production deployments on AWS EKS, Azure AKS, Google GKE and on-premises clusters. The cluster platform adds integration work, but the customization logic stays the same.
- Build: Plan storage classes, network policies and secret handling for connector credentials on your chosen platform.
- Registry: Confirm where ingestion images are pulled from and who rebuilds them after each release.
- Test: Add checks for pod restarts, scheduled ingestion runs and access from the ingestion workers to each source.
- Confirm: Verify the supported Kubernetes versions and chart values for your platform in the deployment documentation.
A bare metal deployment without Kubernetes requires you to provision and manage each service yourself. The listed prerequisites are Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x.
- Sizing: The bare metal documentation lists minimums of 2 vCPUs, 4 GB RAM and 20 GB storage for the server, and at least 2 vCPUs, 2 GB RAM and 30 GB storage each for the database and search services.
- Build: Plan service installation, process management, backups and version pinning for each component.
- Test: Verify restarts, failover of each service and restore from backup before go-live.
- Confirm: Check the bare metal deployment documentation for current version requirements and sizing.
In an air-gapped or restricted network, connector packages and container images must come from an internal registry. Every dependency the build needs must be mirrored before work starts, which adds planning and test steps.
- Mirror: Stage server images, ingestion images, connector packages and their Python dependencies in the internal registry.
- Build: Rebuild custom ingestion images from mirrored base images so no build step reaches the public internet.
- Test: Confirm the platform makes no outbound calls it cannot complete, and that connectors reach their sources through approved routes.
- Confirm: Ask the vendor which components fetch resources at runtime, and check the licensing terms that apply to mirrored content.
What you need to provide
Before any customization work starts, your organization must name a business owner for the metadata model. This person decides which custom properties, classifications and intake form fields exist, and they sign off on changes that affect how teams describe data. Alongside them, name a steward group that approves intake form submissions. Without a named group, approval requests stall, and nobody can say who was accountable for a given change.
Naming standards, approval rules and the scope of each custom property are decisions only your organization can make. DeployOpen can propose options and document trade-offs, but the choices must be made by your team and recorded in writing before build. Keep the decision log with the configuration baseline so that an auditor or a future upgrade reviewer can see why a field exists and who approved it.
For each source system, provide an API or service account with scoped permissions. Read access is usually enough for metadata extraction, and write access should be limited to the specific entities a custom connector or automation must update. Also provide sample data or a non-production OpenMetadata catalog, so that custom properties, forms and connectors can be tested without touching live metadata. Confirm with the source system owner which permissions are required, and ask for them to be documented.
State the current OpenMetadata version and how it is deployed, whether on Kubernetes, bare metal or Docker. The version determines which customization options exist and which breaking changes apply. For any custom connector, supply the source system documentation, including its API reference, authentication method and data model. Finally, agree a change window for rollout with the operations team, so that configuration changes and any restarts happen when downstream users and scheduled ingestion can tolerate them.
Frequently asked questions
Can OpenMetadata be customized without forking the project?
Yes, the planned approach keeps changes outside the core codebase and uses the extension points the platform exposes, including custom properties, classifications, intake forms, REST APIs and SDKs, with custom connectors packaged as separate code. Supportability comes from keeping a written inventory of every customization, the OpenMetadata version each one was tested against, and a rebuild path for each upgrade. Because OpenMetadata is released under the Apache License 2.0, you can run it in your own infrastructure. For each customization, confirm that a supported extension point exists in your target version before the design is fixed.
What drives the effort of an OpenMetadata customization project?
The number of custom properties, intake forms and connectors is the main driver, because each one needs a definition, testing against the target version, documentation and a named owner. Connectors usually add the most work. OpenMetadata lists more than 130 connectors, so check whether a supported one already covers your source before writing custom code. Other drivers include the approval workflow for classification changes, the access model, how many teams use the forms and how many sources need credential handling. Ask for a written scope that lists each item and its test plan, because quotes follow from that scope.
Can our own engineers customize OpenMetadata using the SDK and REST APIs?
Yes, a team with Python, TypeScript or Java experience can handle simple property and automation work alone, since OpenMetadata provides REST APIs, a Python SDK, TypeScript packages and Java libraries. Team capacity matters more than tooling. Someone must own the custom code, rebuild ingestion images for the Python 3.12 and Apache Airflow 3.3.0 stack in the 2.0 line, and run regression tests after each maintenance release. Map your planned customizations against those skills before deciding. A partner is worth considering when the scope spans many connectors or a fixed cutover date, and the people who build the work should also be the people who maintain it.
How do custom connectors keep working after an OpenMetadata upgrade?
They keep working when each connector is version-pinned, tested against every target release and rebuilt whenever the ingestion image changes. OpenMetadata 2.0 moved ingestion images to Python 3.12 with Apache Airflow 3.3.0, and the 2.0 release notes list rebuilding custom ingestion images for Python 3.12 as a breaking change. Maintenance releases 2.0.1 to 2.0.5 followed about every one to two weeks, so schedule a recurring regression run and repeat it with each patch. Keep a connector test suite that runs against a sandbox source, and record the version pair each release was checked with.
What does a partner need from our team before quoting an OpenMetadata customization?
A partner needs a list of the customizations you want, the deployment target, the OpenMetadata version you run or plan to run, and access to a non-production environment. Also provide the source inventory, your policy for connector credentials, identity provider details if SSO is in scope, and named owners who approve designs and test results. The deployment target changes the work. For bare metal, 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. Confirm these against the deployment documentation for your chosen version.
Does an OpenMetadata customization engagement include the Collate commercial edition?
Not by default, because the engagement scope is written for each project and any commercial edition is a separate decision. OpenMetadata is released under the Apache License 2.0, and Collate, which maintains the project, offers commercial enterprise capabilities and premium support. Before the design is fixed, compare the features the open-source build provides with the capabilities you need. Confirm licensing and support terms directly with Collate and your procurement team, and ask any partner to state in writing which edition the quote assumes.
How DeployOpen approaches OpenMetadata customization
DeployOpen plans, builds, documents and supports OpenMetadata customizations inside your own infrastructure. Work is fixed-scope, and the written scope is agreed before any build begins.
How we scope
- Written scope lists each custom property, classification, intake form and connector before any build starts.
- We check which customizations the current OpenMetadata release supports, so the build avoids forking the project.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- Each custom property, classification and intake form is configured in a repeatable way and tested before release.
- Custom connectors are built on OpenMetadata's REST APIs and Python SDK, with source credentials kept in your secrets store.
- API automation uses the REST APIs, Python SDK or Java libraries and is tested on a non-production instance.
How we hand over
- Handover includes a written record of every property, classification, intake form, connector and API script delivered.
- Your team receives runbooks for deploying, rerunning and troubleshooting custom ingestion jobs and scripts.
- Knowledge transfer sessions cover the admin console, API tokens and where each customization lives in your environment.
How we support
- Ongoing support is available as a retainer covering upgrades, patches and regression checks on your customizations.
- Each OpenMetadata release is reviewed against your custom properties, intake forms and ingestion images before you upgrade.
- Upgrades to 2.0 include planned handling of breaking changes, such as rebuilding custom ingestion images for Python 3.12.
