We moved Vault to OpenBao 2.7.1 from two starting points, the last open-source Vault (1.14.8) and current Vault (2.1.2). The data arrived intact every time. What broke was the way back, a set of plugins, and one audit setting that stops OpenBao serving at all.
The data moves
We seeded Vault the way a real install looks. It held versioned KV secrets including a destroyed version, a PKI hierarchy with a revoked leaf, transit keys, and live tokens issued to userpass and AppRole logins. Then we pointed OpenBao at the same raft storage with the same config file and unsealed it with Vault's keys.
Its API answered in 694 ms and it was active in 1,237 ms. Every KV version read back, the revoked serial was still in the CRL, and a new leaf from the old intermediate verified against the Vault root. Vault's transit ciphertext decrypted, Vault-issued tokens still worked, and the old passwords still logged in. A snapshot restore, a file storage migration and the rolling three-node replacement from OpenBao's guide all passed the same 34 of 35 checks.
Then we ran the same seed and the same checks from Vault 2.1.2, the current release. OpenBao's guide says newer Vault versions are untested. It made no difference here. OpenBao unsealed with the 2.1.2 keys, went active in 1,362 ms, and passed 34 of 35 in place, from a snapshot and as a rolling cluster. The one catch was the snapshot. A normal restore refused with could not verify hash file, and the force restore worked.
Clients barely notice. VAULT_ADDR and VAULT_TOKEN work with the bao CLI, and the Vault 1.14.8 CLI works against OpenBao. New tokens look different, s. plus 26 characters where Vault issued hvs. plus 95.
Swapping the binary back isn't a rollback
On its first unseal, OpenBao rewrites the mount table into a new layout. Vault can't read it.
We started Vault again on the migrated storage. It logged no mounts; adding default mount table at INFO level and came up as an empty Vault. 27 of our 35 checks failed. Starting OpenBao again on that storage didn't bring the original mounts back either.
Restoring the raft snapshot taken before the swap brought back all 35. Anything written on OpenBao after the swap was gone. So the rollback plan is a snapshot taken immediately before the cutover, and a decision about how many writes you can afford to lose.
About two thirds of plugin mounts stopped serving
OpenBao doesn't ship every plugin Vault does. From 1.14.8, 16 of our 25 mounts stopped serving. Of the mounts we created, 6 of 11 secrets engines and 10 of 14 auth methods came up listed but with no backend behind them. That's every cloud engine (AWS, Azure, GCP), Consul, Nomad, GitHub, Okta, and in 2.7 also LDAP, Kerberos and RADIUS.
From 2.1.2 it was 17 of 26. Vault 2.x adds an agent-registry/ mount by default, and OpenBao has no backend for it. It logs plugin not found in the catalog: agent_registry, then an INFO line saying the mount succeeded.
Their configuration stays in storage where nothing can reach it. The mount still shows in the list, so a quick look says everything arrived. List your mounts before the move and check each one against what OpenBao ships.
A jsonx audit device stops OpenBao from serving
Vault supports a jsonx audit format. OpenBao 2.7.1 doesn't. With a jsonx device as the only audit device, OpenBao unsealed and then never became active. From 1.14.8 it retried failed to setup audit table 88 times in 62 seconds, sys/health returned 429, and no request was served. From 2.1.2 it did the same thing, 90 times in 61 seconds.
It fails closed, which is the right default for an audit log. It also can't be fixed through the API, because OpenBao refuses to create audit devices that way and wants them declared in config. Change the format on Vault before the move.
Standby reads can be stale
On a three-node cluster we wrote a secret and immediately read it back through a standby, 50 times. Vault returned the old version 0 times, on both 1.14.8 and 2.1.2. OpenBao returned it 50 times, then caught up within 2 seconds. With disable_standby_reads = true OpenBao returned the old version 0 times. If anything writes then reads straight back, set it.
What this covers
We tested two sources, Vault 1.14.8 and 2.1.2, with the same seed. Features that exist only in newer Vault, holding real data, are where a storage problem would show, and we didn't seed those. We also left out Enterprise features, auto-unseal and anything at scale. Full records: vault-lab 2026-10-12-v1-vault-1.14.8-to-openbao-2.7.1 and 2026-10-13-v2-vault-2.1.2-to-openbao-2.7.1.
Planning a move off Vault and want it rehearsed against your own mounts first? Talk to us.
OpenBao Advisory Watch - one email per OpenBao security release, listing the fixed versions and what each advisory covers. Subscribe.
