OpenBao → HashiCorp Vault Enterprise
OpenBao ↔ HashiCorp Vault Enterprise: integration to migration path.
Your secrets plane is load-bearing — break it and every workload's startup fails at once. So OpenBao deploys alongside Vault Enterprise first, seeded from a snapshot of your real data, and your applications cut over one mount cohort at a time against a parallel cluster. No flag day, no forced re-credentialing, and every phase rolls back in minutes.
The honest exception is the Enterprise-only surface — namespaces, Replication, Sentinel, Control Groups, KMIP. Where those are load-bearing for your compliance model, the answer is a partial migration, not a pretend one.
The idea
Seed from a snapshot. Cut over per mount.
The topology that makes this zero-outage: OpenBao runs as an independent HA Raft cluster seeded from a Vault Enterprise Raft snapshot, so it boots with an identical KV and auth-method config behind its own listener. Both clusters speak the same API contract, so apps fetch from a dual-read wrapper that reads Vault Ent first and falls back to OpenBao — Vault Ent keeps owning every un-cutover mount and every lease while apps quietly move across. Cutover is per mount, gated on the longest lease TTL in the cohort, never a single switch.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We read every mount through the API and tag it: static KV (Cohort A), dynamic engines (Cohort B), or anything leaning on Enterprise-only namespaces, Sentinel, Control Groups, KMIP or Transform (Cohort C). Read-only. The Cohort C size is what decides whether full retirement is even on the table.
Stand up OpenBao, seed from snapshot
OpenBao stands up as an HA Raft cluster, multi-AZ, with a matching seal type. We restore a Vault Ent snapshot, strip the Enterprise engine config OpenBao won't accept, and replay auth methods with identical role and policy bindings. No production app talks to it yet.
Dual-fetch wrapper for static KV
Cohort A apps run a wrapper (Vault Agent, bao agent, or ESO) that reads Vault Ent first and falls back to OpenBao. A reconciliation job replays Vault Ent writes into OpenBao idempotently. Writes still land on Vault Ent only.
Static KV cutover
Per mount, lowest blast radius first, we flip the wrapper so OpenBao is primary and Vault Ent is the fallback, ramp from 10 percent to 100, then reverse the reconciliation direction. Vault Ent stays a hot fallback for at least seven days.
Dynamic engines, lease-window cutover
We replay each engine's config to OpenBao — database, AWS STS, PKI via a second intermediate chained to the same root. Both clusters mint credentials during a dual-issue window, then apps flip to OpenBao and we let Vault Ent leases expire naturally. We never mass-revoke — that would drop every active database connection at once.
Cohort C decision — partial or full
If namespaces, Performance Replication, KMIP, Transform or Control Groups are load-bearing, this is the honest end state: Vault Ent is shrunk to Cohort C only and kept. If Cohort C is empty or excisable, each feature is replaced — namespaces to mount-path convention, Sentinel to HCL plus OPA — and soaked 30 days before sign-off.
Decommission Vault Enterprise
Full-retirement path only. We disable auth methods, seal the cluster, hold a sealed snapshot for the evidence window, then tear down nodes and surrender the licence after auditor sign-off.
Feature parity
Where OpenBao matches Vault Enterprise, and where it can't.
| Capability | OpenBao | Vault Enterprise | Parity |
|---|---|---|---|
| Static secret storage | OpenBao KV v2 (wire-identical) | Vault KV v2 | At parity |
| Dynamic database credentials | OpenBao database/creds/<role> | Vault database/ engine | At parity |
| Cloud STS / PKI engines | OpenBao aws/sts/<role>, pki/ via config-replay | Vault aws/sts, pki/ | At parity |
| Transit (encryption-as-a-service) | OpenBao transit/ — keys cannot export-migrate | Vault transit/ | Partial |
| Auth methods | OpenBao auth/kubernetes, auth/aws, auth/jwt | Same | At parity |
| HCL ACL policy | OpenBao HCL ACL (ports verbatim) | Vault HCL ACL | At parity |
| Sentinel (EGP / RGP) | None — HCL plus OPA sidecar | Vault Sentinel | SaaS only |
| Namespaces / multi-tenant | None — mount-path plus policy convention | Vault Namespaces (token-store isolation) | SaaS only |
| Performance / DR Replication | Single-region Raft plus app-side multi-region | Vault Performance and DR Replication | SaaS only |
| Control Groups (multi-party approval) | None — external workflow | Vault Control Groups | SaaS only |
| KMIP / Transform-FPE | None | Vault KMIP server plus Transform / FPE | SaaS only |
| Seal / auto-unseal | Cloud-KMS auto-unseal; HSM seal on roadmap | Cloud-KMS plus HSM auto-unseal | Partial |
| Audit log | OpenBao HMAC-chained (per-cluster salt) | Vault HMAC-chained audit | At parity |
| API / CLI | bao CLI plus hashicorp/vault/api and hvac | vault CLI plus same SDKs | At parity |
| FIPS 140-3 | Operator-built | Vendor CMVP cert | Partial |
| Vendor SLA / SOC / FedRAMP | None — self-hosted | HashiCorp SLA plus FedRAMP | SaaS only |
| Cost model | Compute plus storage plus ops | Per-cluster plus per-client SKU | Partial |
What we're honest about
The caveats most vendors leave out.
Namespaces, Replication and Control Groups are Enterprise-only
OpenBao has no namespaces, no Performance or DR Replication, and no Control Groups. Namespaces collapse to a mount-path-plus-policy convention that loses token-store isolation; multi-region active-active becomes single-region Raft plus app-side fetch; multi-party crypto approval becomes an external workflow. If any of these is a load-bearing compliance control, the honest answer is a partial migration — keep Vault Ent for those mounts.
Transit keys cannot be exported
transit/ keys live encrypted under the source cluster's seal and there is no first-party export. Every encrypted record must be re-keyed through a dual-encrypt-on-write plus re-encrypt-on-read scheme or a bulk re-encryption job. Long-tail records that are never re-read may simply stay on Vault Ent. If transit is in production, this is the single biggest reason a timeline slips, so we scope it explicitly in Phase 0.
Leases and tokens are per-cluster
A lease minted on Vault Ent cannot be renewed or revoked by OpenBao, and tokens don't carry across. That is why dynamic-engine cutover happens at lease-window boundaries and never as a mass revoke — auth-method workloads (Kubernetes, IRSA, JWT) re-authenticate transparently on their first OpenBao call.
Self-hosting means you own uptime and FIPS posture
There is no vendor SLA, no indemnification, and no HashiCorp support escalation once Vault Ent is gone. FIPS is operator-built — you build against FIPS-validated Go crypto and a FIPS-validated seal rather than citing a vendor CMVP cert. That is exactly why we run it as a managed service: HA across zones, a tested DR rebuild, and on-call expertise from Phase 1.
Why this beats a flag day
Reversible at every step, soaked before anything is cancelled.
Every per-phase cutover rolls back in under 15 minutes while the parallel cluster is still live — re-flip the wrapper, reverse the reconciliation, and you are back on Vault Enterprise before anyone notices. And no mount is declared done until it has soaked at least 30 days on OpenBao with zero fallback hits and matching lease-issuance baselines. Only after that soak — and auditor sign-off — does the Vault Enterprise licence get surrendered.
See whether your Vault Enterprise stack migrates cleanly.
A 30-minute call with a senior secrets engineer. We classify your mounts into cohorts, size the Enterprise-only surface that may have to stay, and tell you honestly whether your environment lands at full retirement or a partial migration — before you commit to anything.
Map my migration →