Export data from HashiCorp Vault before the contract ends
A Raft snapshot is a cluster-bound backup, not a portable export. Vault's operator raft snapshot save command writes the current state of an integrated storage cluster to a file, but a snapshot can only be restored into the same cluster with the same unseal keys. If your reason for leaving is a renewal, a licensing change or a residency requirement, the snapshot will not give a new platform your secrets. Moving secrets elsewhere means reading them out through the Vault API, one path at a time, and then writing them into the target system.
The export scope depends on your edition. Vault Community offers snapshots but not automated ones. Automated snapshots to local or cloud storage and individual secret recovery are Vault Enterprise features, so a Community cluster has to schedule its own snapshot jobs and an Enterprise cluster has to confirm which of those capabilities its contract covers. HCP Vault Dedicated is managed by HashiCorp, so your export path runs through the same API and access controls, and you should ask the vendor what backup copies you can obtain and in what format. The HashiCorp Vault documentation is the basis for what can be taken out, and it should be checked against your exact version before any plan is written.
Before the contract ends, inventory every KV mount, dynamic secret configuration, auth method and policy, then confirm with the vendor which of these can be read through the API under your current license. Keep a restore test on a separate cluster to prove the snapshot is usable for your own recovery, even though it will not move your data. Confirm your target platform's import path and retention rules in writing, and record who approved each export so the audit trail survives the move.
Which Vault data you can export and how
This table compares the main Vault data types, the method used to get each one out, the file or response format, and the limits that apply. Read each row as a separate path, since snapshots and API reads do not move the same data. The main takeaway is that a Raft snapshot only returns to the same cluster with the same unseal keys, so secrets meant for another system must be read out through the API.
| Data type | Export method | Format | Limits |
|---|---|---|---|
| Cluster state (integrated Raft storage) | Raft snapshot with the operator raft snapshot save command | Binary file written to disk | Restores only into the same cluster with the same unseal keys |
| Cluster state (Raft used only for HA) | Not supported for snapshots | Not applicable | Export state from the separate storage backend instead, and confirm with your storage vendor |
| Automated snapshots | Snapshots to local or cloud storage on a schedule | Binary snapshot files | Vault Enterprise feature only |
| Individual secret recovery | Recovery of single secrets from a snapshot | Secret data as stored | Vault Enterprise feature only |
| KV secrets | Read each secret through the Vault API | JSON response per secret | Requires a token with read access to each path, one request per secret |
| Configuration (policies, auth mounts, secrets engines) | Read through the Vault API | JSON responses per object | Must be read object by object, and dynamic secret definitions may need re-creation at the destination |
| Secret values moved to another system | Scripted read through the API, then import | Depends on the target system | Plan the import and re-pointing of applications as a separate step, and confirm target support with the target's documentation |
What does not leave Vault and the workaround for each
Vault's snapshot tooling protects a cluster but does not give you a portable copy of it. The cards below cover what stays behind when you leave, and a practical workaround for each so the export plan does not depend on a restore that cannot happen elsewhere.
Snapshots restore only into the same cluster
A Raft snapshot written by vault operator raft snapshot save captures the cluster state, but it can only be restored into the same cluster using the same unseal keys. Restore also continues in the background after the command returns, so you cannot treat a successful command as a finished restore. Workaround: treat snapshots as disaster recovery for the current cluster only, and plan the move as a separate read-out of secrets and configuration into the new platform. Confirm the restore behavior for your Vault version in the operator documentation before you rely on it.
Snapshots unavailable on HA-only Raft
Snapshots are not supported when Raft is used only for high availability storage. If your cluster uses Consul or another backend for data and Raft only for HA coordination, the snapshot command gives you nothing to save. Workaround: check your storage stanza before planning. If snapshots are not available, export through the API, kv get for each path, and record the storage and seal configuration separately so the target can be built from code.
Automated snapshots and single-secret recovery
Automated snapshots to local or cloud storage and individual secret recovery are Vault Enterprise features. Community deployments therefore need a scheduled job that runs the snapshot command and copies the file off the cluster, with encryption and retention you control. Workaround: script the snapshot schedule and a KV export, store both encrypted in your own backup location, and test a restore into a scratch cluster. Ask HashiCorp which Enterprise features your agreement includes.
Dynamic secret state and leases
Dynamic secret engines issue credentials that Vault tracks through leases. The leases and the record that a database user was created by Vault do not have a documented portable export. Workaround: do not migrate live dynamic credentials. Let them expire or revoke them, then configure the target platform to issue new credentials from the database side. Inventory each database role and its TTL before the cutover so applications can be re-pointed in order.
Tokens and client identity
Tokens and the auth state behind them are issued by the running cluster, and they do not have a documented export path. Applications holding tokens will fail after cutover unless they re-authenticate. Workaround: move workloads to an auth method that can be recreated from code, such as AppRole for servers, JWT/OIDC or Kubernetes auth, and have clients log in again on the new platform. Note that OpenBao issues tokens in a different, shorter format, so client parsing logic should be reviewed.
Auth mounts, policies and configuration
Auth mounts, policies and secrets engine configuration live in Vault's storage and are not exported as a portable bundle. Recreating them by hand is where drift and missed roles happen. Workaround: keep the configuration in version-controlled code, such as policy files and Terraform or OpenTofu definitions, and apply it to the new cluster. Compare the resulting mounts against an inventory exported from the old cluster before any application is switched over.
The sequence for a complete export from Vault
This sequence moves secrets, policies and authentication configuration out of Vault in a order that keeps a restorable backup and a readable copy of every secret, and ends with a check that the copies match the source. Each step names what it produces so the next one has a clear input.
Inventory mounts, policies and auth methods
The Vault administrator lists every secrets engine mount, KV version, auth method, policy and namespace the cluster uses, then records which team owns each one. Run the list commands with a token that has read access to system configuration, and save the output in a version-controlled or access-restricted location. The step is complete when the inventory covers every mount and auth method and a second administrator has reviewed it against the running configuration. Plugin-backed mounts go on a separate list, because a target platform may not ship the same plugins.
Take a Raft snapshot
On an integrated storage cluster, the administrator runs the raft snapshot save command against the active node to write the current state to a file. Snapshots are not available where Raft serves only as high availability storage, so confirm the storage type first. Record the snapshot time, the Vault version and the cluster identifier beside the file. Be aware that a snapshot restores only into the same cluster with the same unseal keys, so this file is a disaster recovery copy, not a migration format.
Store the snapshot encrypted with unseal material
The snapshot contains encrypted secret data, and restoring it depends on the unseal key material, so store the two under separate controls. Encrypt the snapshot file at rest with a key held by a different custodian than the one holding the unseal shares. Record checksums of the encrypted file in your change log. The step is done when a named custodian can decrypt a test copy in a restricted environment and the checksum matches the original.
Read KV secrets into an encrypted staging store
Because a snapshot cannot move to another platform, the engineering team reads each KV secret through the Vault API, including every version the policy allows, and writes it to a staging store encrypted with a key separate from the source. Use a dedicated read-only policy with an audit trail, and page through paths with the list endpoint rather than guessing names. Individual secret recovery is an Enterprise feature, so on Community editions this read is the only route for secret-level copies. The step is complete when the staging inventory lists the same paths and version counts recorded in step one.
Export policies and auth configuration as code
Write each policy, auth method configuration, role and identity binding to files in a version-controlled repository, using the Vault API or CLI output. Remove any values that are secrets, such as AppRole secret IDs or LDAP bind passwords, and store them through the staging process instead. Review the files against the step one inventory, noting any auth method or plugin with no equivalent on the target platform. The step is done when a reviewer can rebuild the policy set from the files alone.
Wait for the restore to finish before checking
If you test the snapshot by restoring it into a scratch cluster, remember that the restore continues in the background after the command returns. Do not start comparisons until the cluster reports that the restore has finished and the node is healthy. Check the server logs and the status endpoint, and record the time the restore completed. Running verification early will show false gaps and may hide real ones.
Verify counts, versions and checksums
Read the same paths a second time from the source or restored cluster, and compare secret counts, version numbers and a checksum of each value against the staging store. Use a hash that is computed on both sides, so plaintext values never appear in the comparison report. Investigate every mismatch, and confirm that deleted or destroyed versions were intentionally excluded. The sequence is complete when the report shows zero unexplained differences and an independent reviewer has signed the record.
Why a Vault snapshot is a backup, not a migration file
A Vault snapshot is a disaster recovery copy, not a migration file. The vault operator raft snapshot save command writes the current state of an integrated storage (Raft) cluster to a file, and that file can only be restored into the same cluster, with the same unseal keys. It protects you if the cluster is lost or corrupted, but it does not carry your secrets into OpenBao or any other product. Snapshots also do not apply to deployments that use Raft only for high availability storage, so confirm your storage mode before you rely on one. Restores run in the background after the command returns, so the restore should be verified rather than assumed complete.
This shapes the exit plan. Keep snapshots during the transition as a rollback option for the Vault cluster you still run, and store them encrypted, with access limited to the people who could restore them. Treat the snapshot's unseal keys as sensitive material in their own right. Moving secrets to OpenBao is a separate task. It means reading each secret out through the Vault API, mapping it to the target's mounts and paths, and re-pointing applications and agents. Ask whether the snapshot retention and access controls meet your own policy, and whether your Vault edition includes automated snapshots, which are a Vault Enterprise feature.
OpenBao's migration guide describes a different path: a node-by-node in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, which OpenBao states it tested only against that version. That in-place upgrade keeps the existing data and cluster identity, so it is not an export. Clusters on later Vault versions, Enterprise clusters, or clusters using other seals or plugins need their own assessment before choosing between an in-place upgrade and an API-driven migration.
What to plan before the Vault renewal or termination date
Exporting from Vault is easier when the work starts before the renewal notice period closes. The cards below cover the decisions, written confirmations and checks that shape the export, from confirming your edition to budgeting internal time. Read them in order. Edition and contract terms determine what you can export, and the snapshot, verification and client steps depend on those answers.
Confirm your Vault edition
Start by identifying which product you run: Vault Community, self-managed Vault Enterprise, or HCP Vault Dedicated. Automated snapshots and individual secret recovery are Vault Enterprise features, so a Community cluster has fewer built-in export options. Check your contract or order form for the edition, the licensed features and the end date. Each edition has a different export path, so this answer sets the rest of the plan.
Get export terms in writing
Ask HashiCorp or IBM, in writing, what export support your agreement includes and what happens to your data when the subscription ends. Ask whether any assistance with exporting secrets or state is included, what format it arrives in, and how long you have to retrieve it. Verbal assurances from a sales or support contact are not enough when a renewal or termination deadline is close.
Freeze a snapshot early
Take a Raft snapshot with vault operator raft snapshot save before the notice period closes, and record when it was taken and which cluster it came from. Remember that a snapshot restores only into the same cluster with the same unseal keys, so it protects your state but does not by itself move secrets to a new system. Store it encrypted, with access limited to the people who run the export.
Keep Vault readable until verification passes
Do not decommission or revoke access to the existing cluster until the secrets you exported have been read back and checked against the source. Keep the cluster running and its unseal keys available during that window. If the subscription ends first, confirm with the vendor whether read access continues during a grace period, because a cluster that stops serving requests cannot be used as a fallback.
Plan token and client re-pointing
Inventory every application, agent, CI job and Kubernetes injector that reads from Vault, along with the auth method and policy each one uses. Note where tokens are issued and how long they live. New OpenBao tokens use a different format, so any code that parses or stores old token strings needs review. Plan the cutover order so that dependent systems switch together, and confirm that each one can fall back during the change.
Budget internal time for the migration
Export and migration work consumes engineering and security hours that are separate from any subscription fee. Account for inventory, export scripting, verification, client changes, testing and sign-off by the owners of each dependent system. Ask any external partner for a written scope and deliverables before work starts, so that the internal calendar and the contract deadline are set against the same plan.
Questions buyers ask about exporting from Vault
Can a Vault Raft snapshot move my data to another product?
No. A Vault snapshot can only be restored into the same cluster, with the same unseal keys, so it is a disaster recovery tool rather than an export format. Snapshots also do not apply to deployments that use Raft only for high availability storage. To move secrets to another system such as OpenBao, you read them out through the Vault API, then write them into the target, and you keep the original cluster running until the cutover is verified. The Raft snapshot command reference sets out the restore limits in detail.
Do automated Vault snapshots require Vault Enterprise?
Yes. Automated snapshots to local or cloud storage are a Vault Enterprise feature, as is individual secret recovery. On Community edition you schedule the vault operator raft snapshot save command yourself, using your own scheduler and storage, and you test restores in a separate environment. Ask your Vault contact to confirm which features your current license includes before you plan around them, since licensing terms can differ between Enterprise contracts and HCP Vault Dedicated.
How much effort does exporting secrets from Vault take?
The effort depends on the inventory, not on the export tool. The main drivers are the number of secrets and their versions, the number of secrets engine mounts and auth methods, how many dynamic secrets engines are in use, and how many Kubernetes integrations, agents and injectors read from Vault. Each mount needs a mapping to a target path, each consumer needs a re-pointing plan, and each dynamic credential type needs a replacement or a cutover window. Build an inventory of these items first, then size the work against it. No general duration applies to every estate.
What drives the cost of an export project up?
Cost follows the same drivers as effort, plus the people involved. Internal staff time for inventory, testing and cutover is the largest recurring cost in most projects, and it is often one-time. External work adds fees for planning, scripting the API read-out, validating the restored data and handling integrations. Ask any provider for a written scope that lists the mounts, secret counts, dynamic engines, Kubernetes integrations and environments covered, and for the assumptions behind each line item. DeployOpen does not publish prices, so request a quote against that scope.
Can our team export and migrate the secrets without outside help?
Often yes, if the estate is small and the team has administrator access to the source cluster, a working knowledge of Vault policies and auth methods, and a test environment that mirrors production. The work is mostly careful scripting, verification and change control. Teams with many mounts, dynamic credentials, or regulated evidence requirements often find the testing and documentation take longer than the export itself. A short internal pilot on one non-production mount is a practical way to decide.
What skills and time must our staff commit to the export?
Plan for a platform engineer who knows Vault administration and at least one security engineer who can review policies and access paths. Application owners must confirm which secrets their services read and when they can change configuration. Expect the team to maintain both clusters during overlap, run verification checks, and keep a rollback path open. Named owners, a change calendar and a sign-off step for each mount reduce the risk of silent breakage during cutover.
When does outside help make sense for a Vault export?
Outside help makes sense when the inventory is large, when dynamic secrets or Kubernetes injectors must keep working through cutover, when you need evidence for a compliance assessment, or when internal staff cannot release time for testing. A fixed-scope engagement, with deliverables and timelines agreed in writing before work starts, lets you buy a defined outcome. DeployOpen plans, implements, validates and documents self-hosted platforms in your own infrastructure, but it does not issue audit reports, so independent auditors still assess your controls.
Does a Vault export also move the audit log and policy history?
Not by default. A snapshot contains Vault's stored state, but audit devices, log retention and change history live outside that file and must be handled separately. Export policies and auth configuration through the API as text, and archive audit logs under your own retention rules before decommissioning the source. Confirm with your compliance team which records must be kept and where, because a secrets export alone rarely satisfies those obligations.
How DeployOpen scopes and delivers a Vault data exit
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Vault data exit is handled as a written, fixed-scope engagement. We agree the scope, deliverables and timeline in writing before any extraction work starts, and the export runs in your environment.
How we scope
- Inventory which secrets, KV mounts, auth methods, policies and dynamic secret configurations must leave Vault and which can be retired.
- Confirm whether your cluster runs Community or Enterprise and whether snapshots or individual secret recovery are in use.
- Agree in writing where the exported data will land and which destination system owns it afterward.
How we build
- Build the read-out process against the Vault API so each secret, path and version is retrieved and recorded deliberately.
- Test the export on a non-production copy and verify secret counts and values against the source before any cutover.
- Keep exported material encrypted at rest and limit access to named operators for the duration of the transfer.
How we hand over
- Deliver a runbook covering the export steps, verification checks, rollback points and who approves each stage.
- Document the mapping from Vault paths and policies to the target system, so reviewers can trace every secret.
- Provide evidence of the export and deletion steps that your auditors can review, while the assessments themselves remain with independent auditors.
How we support
- Ongoing support, upgrades and continuous testing of the receiving platform are available as a retainer after handover.
- Support can cover follow-up questions from application teams that re-point clients or agents after the move.
- Ask for the support scope, response expectations and any retention period for exported material in your written quote.
