OpenBao's migration guide replaces a Vault cluster one node at a time, followers first and the leader last. We ran that path from Vault 2.1.2 to OpenBao 2.7.1 and killed the Vault leader halfway through. The cluster survived when a Vault node took over. When an OpenBao node took over, it lost every write for the rest of the run.
What happened when the leader died
The cluster had three nodes. One follower was already OpenBao, the other follower and the leader were still Vault, and a load generator sent about 42 requests a second. Then we killed the Vault leader with SIGKILL.
In the first run the OpenBao follower won the election 9.5 seconds later. Its first act as leader was to migrate the mount table to OpenBao's transactional layout. 81 ms after that, the surviving Vault follower crashed on the log entry:
storage.raft.fsm: failed to store data: error="64 is not a supported transaction operation"
panic: failed to store data
That left one node of three. OpenBao lost quorum 2.6 seconds later and stepped down. For the remaining 87 seconds of the run there was no active node. Not one of 2,185 writes and logins after the kill succeeded. Reads and transit kept working from the standby, 1,555 of 2,185.
In the second run, with the same setup, the Vault follower won instead. It was active 5.7 seconds after the kill, served every request afterwards, and passed 35 of 35 checks.
With both followers already on OpenBao, an OpenBao node took over in 11.4 seconds, served everything and passed 34 of 35. The one failure is LDAP auth, which isn't in OpenBao 2.7.
The crash isn't caused by the kill
The guide's last step is to step the Vault leader down so an OpenBao node takes over, then replace the old leader. We did that in all three runs. Each time, the old Vault leader crashed 38 to 39 ms after handing over, with the same 64 is not a supported transaction operation.
In the documented order that does no harm, because that node is the next one replaced. But it shows the rule. Once an OpenBao node leads, every Vault node still in the cluster crashes on the first write OpenBao makes as leader. A leader failure while two or more Vault nodes remain is the risky moment. If an OpenBao node wins that election, the Vault survivors crash and the cluster loses quorum.
We ran two leader kills with one OpenBao follower, and each side won once. Two runs can't give odds, but they show an OpenBao node can win.
The snapshot gets you back in under 40 seconds
Before changing anything we took a raft snapshot from the Vault leader. It was 69,444 bytes for our seeded store. After each run we threw the whole cluster away and restored that snapshot into a fresh Vault 2.1.2 node.
The restore worked every time. A healthy three-node Vault cluster was back in 35.9 to 39.6 seconds and passed 35 of 35 checks with the original unseal keys and root token. A secret written after the snapshot was gone, as it should be. Finishing the migration from there took 31.1 to 33.0 seconds.
So the rollback is real and fast at this size. It costs every write made after the snapshot, which is why the snapshot should be taken minutes before you start, inside a write freeze or a short window.
How to run the migration
- Take a raft snapshot immediately before the first node is replaced, and check you can restore it.
- Keep Vault leading until every follower is OpenBao. Don't step it down early.
- Keep the mixed phase short and watched. A rolling change left half done for a day is the case that can take writes down.
- If the leader dies mid-migration and an OpenBao node wins, don't try to repair the cluster. Restore the snapshot and start again.
We didn't test whether joining the OpenBao nodes as non-voters until the last step stops one winning early. If it does, the risk goes away. We also left out TLS, auto-unseal, Vault Enterprise and larger stores, where restore time grows with snapshot size. Full record: vault-lab 2026-10-26-v4-leader-failover-mid-migration-and-snapshot-recovery.
Planning a move off Vault and want it rehearsed against your own cluster first? Talk to us.
OpenBao Advisory Watch - one email per OpenBao security release, listing the fixed versions and what each advisory covers. Subscribe.
