When HashiCorp relicensed its products under the Business Source License (BSL) in 2023, Vault was affected alongside Terraform. The community forked the last open-source Vault into OpenBao, now a Linux Foundation project. OpenBao forks Vault’s API and architecture, which makes this migration low-risk, but secrets management is trust-critical, so it’s done carefully with no gap in availability.
Why teams move
The driver is licensing, not capability: vendors embedding Vault faced redistribution risk under the BSL, and many users want genuinely open-source secrets management. OpenBao preserves the Vault API, auth methods, and secrets engines, so applications and workflows largely don’t change.
Cost is the other pressure point. HCP Vault prices on a client basis, and several capabilities that platform teams lean on are gated behind paid enterprise tiers. As a fleet grows, both the client-based bill and the pull toward paid tiers compound. OpenBao, as a Linux Foundation project, removes the licensing line item and keeps the roadmap community-governed. The trade is that you own the operational burden and any support you want, so weigh the client-based pricing you would shed against the run cost of self-hosting in the calculator above before committing.
What stays the same
- The API. OpenBao is API-compatible with the forked Vault version, clients, the CLI, and integrations work with minimal change.
- Auth methods and secrets engines, KV, transit, database, PKI, etc. carry over.
- Storage backends, the supported backends are compatible, so your data layer can move across.
- Policies and tokens, the model is unchanged.
The migration, carefully
Because Vault holds your secrets and unseal material, treat this as a controlled cutover, not a casual swap:
- Inventory your Vault deployment: storage backend, auth methods, secrets engines, policies, audit devices, and every client/integration that talks to it. Note your HA topology and unseal method (Shamir / auto-unseal).
- Stand up OpenBao matching your Vault version line, with the same storage backend and HA setup.
- Migrate the storage backend and unseal keys. OpenBao can operate on Vault’s compatible storage; plan the unseal-key/auto-unseal transfer deliberately and keep recovery keys safe.
- Validate auth methods, secrets engines, and policies on OpenBao before any client points at it, read a known secret, exercise dynamic credentials, confirm PKI issuance.
- Repoint clients (change the address/CLI to OpenBao) gradually, ideally behind a load balancer/DNS so you can roll back instantly.
- Cut over once clients are confirmed; keep the Vault cluster recoverable through hypercare.
The storage backend and unseal keys
This is the part that deserves the most rehearsal, because it is where an availability gap or a lost key would hurt. Two things move: the storage backend that holds your encrypted secrets, and the unseal material that lets the server decrypt them at startup. Because OpenBao forks Vault’s storage layer, the encrypted data does not need to be exported secret by secret; OpenBao can operate against a compatible backend directly. What you are really doing is bringing up an OpenBao node, giving it the same backend, and proving it can unseal.
Treat the unseal path as the highest-risk step. If you run Shamir unseal, keep the key shares in the hands of their holders and confirm the quorum works against OpenBao before you retire Vault. If you use auto-unseal against a cloud KMS or HSM, verify that OpenBao reaches the same seal and unseals cleanly. Keep recovery keys accessible but protected throughout, and never let the migration reduce the number of independent copies of your unseal material below what your policy requires.
What moves and what stays put
- Unchanged: the Vault API surface, auth methods, secrets engines, policies, tokens, and the encrypted data in the storage backend.
- Changed: the server binary and the address clients resolve, plus any Vault-enterprise-only feature you were relying on that OpenBao does not carry.
- Watch closely: auto-unseal wiring, HA topology, audit devices, and every integration that authenticates to the server.
Testing engines and keeping a way back
Validation before cutover is non-negotiable for a secrets store. Against OpenBao, and before a single production client is repointed: read a known secret, exercise a dynamic credential from the database engine, confirm PKI can issue a certificate, and run each auth method a real workload uses. Re-test the integrations explicitly, Kubernetes auth, cloud auth, and agent injectors are the usual sources of surprises, because they touch the API in ways a simple secret read does not.
Rollback is what the load balancer or DNS indirection buys you. If a repointed client fails validation, shift its address back to the Vault cluster and investigate out of band. Because both tools share the storage format, there is no data to reverse, only traffic to redirect. Keep the Vault cluster live and recoverable, and keep a storage and unseal-key snapshot, until you have a full hypercare window of clean OpenBao operation.
Version drift, the one real catch
Like Terraform/OpenTofu, Vault and OpenBao diverge over time, OpenBao has added its own features on its own timeline. Practical implications:
- Pin versions and migrate from a Vault version that has a clean OpenBao counterpart.
- Don’t straddle both on one storage backend long-term.
- Re-test integrations (Kubernetes auth, cloud auth, agent injectors) against OpenBao explicitly.
The sibling paths
The same BSL change hit Terraform (→ OpenTofu) and Consul. If you’re moving Vault for licensing reasons, audit the rest of your HashiCorp footprint for the same exposure.
Where this nets out
Vault → OpenBao is mostly mechanical because OpenBao forks Vault’s API and storage, stand up OpenBao on the same backend, migrate storage and unseal material, validate engines and auth, then repoint clients behind DNS/LB for instant rollback. The care is in the secrets/unseal handling and version-pinning, not in rewriting apps. There’s no per-resource license to model here, but use the calculator above to weigh the broader secrets/IaC footprint, and confirm any commercial-support assumptions before cutover.