How to export data from Azure Key Vault before the vault is removed
If a renewal, licensing change, residency rule or exit decision means Azure Key Vault has to go, plan around four limits: the cap on versions a backup can hold, soft-delete retention, key re-creation and the restore boundary. Secret values can be read through the API, so they can move to a new system. Backup blobs, by contrast, restore only within the same subscription and geography, and keys usually have to be re-created in the target system, so the certificates and encryption dependencies built on them need a re-issue plan. This page covers only documented export paths. Confirm current behavior for your vault in Microsoft's Key Vault documentation before you plan the work.
Start with an inventory of every secret, its name, content type, tags, expiry date and the versions your applications still use. Read the values with an identity that has only the read permissions the export needs, through the Key Vault API or your own tooling, and write them to an encrypted destination that the migration team controls. Key Vault diagnostic logs will record those reads, so ask your security team to review them as part of the export record. Backup blobs are useful for moving data inside Azure, but they do not give you a portable copy for OpenBao on your own infrastructure. For secrets with many versions, confirm how many old versions the backup can carry and decide whether to capture the rest separately or accept losing history.
Soft delete changes the timeline. When you delete a vault, deleted objects remain recoverable for a retention period that the vault configures, and purge protection can block permanent removal until that period ends. Before you schedule deletion, check the retention setting and whether purge protection is on, then write down the earliest date the vault name and its objects can be fully purged. Keep the vault in place until every application has read its secrets from the new system and you have verified the copies. Deleting the vault only after cutover keeps a rollback path open for as long as the retention period allows.
Which Azure Key Vault data you can export and in what form
This table compares each category of vault data by export method, output format and documented limits, and marks which reads depend on data-plane permissions. Use it to build your inventory before planning the move. The main takeaway is that backup blobs stay inside Azure, so plaintext secret values, exportable certificate material and configuration records must be captured through API reads and inventory scripts.
| Data | Export method | Output format and limits | Permission dependency |
|---|---|---|---|
| Secret values | API read of each secret's current value and listed versions | Plain text string or bytes returned by the API. Each version must be read separately if you need history. | Data-plane read on secrets (get and list). Confirm the role or access policy with Microsoft's current documentation. |
| Secret backups | Backup operation per secret | Encrypted blob that restores only into Key Vault in the same subscription and geography. Limit of 500 versions per secret. | Data-plane backup permission. Blobs do not give you plaintext for another platform. |
| Certificates | Download of certificate material through the secret or certificate API | PFX or PEM material only if the certificate policy marks the key as exportable. Non-exportable keys return the public certificate only. | Data-plane read on certificates and secrets. Check the policy's exportable setting on each certificate. |
| Software-protected keys | Backup operation per key | Encrypted blob restorable only in the same subscription and geography. Private key material is not returned in plain text. | Data-plane backup permission on keys. Plan to re-create the key elsewhere rather than copy it. |
| HSM-protected keys | No export of private key material | Only the public key and metadata can be read. Keys must be re-created or replaced in the target system. | Key read permission gives public metadata only. Confirm HSM key export policy with Microsoft's documentation. |
| Access configuration | Manual inventory or management-plane export of access policies or RBAC role assignments | JSON or CLI output that you save as a record. Azure does not provide a direct import into OpenBao. | Management-plane reader rights on the vault and its subscription. Record both access policies and RBAC if both exist. |
| Network rules | Management-plane read of firewall, virtual network and private endpoint settings | Configuration output in JSON or CLI format. Use it to rebuild network access controls in the target. | Management-plane reader rights. Private endpoint configuration may sit in a separate resource. |
| Diagnostic logs | Diagnostic settings sent to a storage account, Log Analytics workspace or event hub | Log records in the destination's format. Logs only exist for the period you enabled collection, so enable it before cutover. | Management-plane rights to read diagnostic settings and the destination. Confirm retention with your own policy. |
What does not leave Key Vault and how teams work around it
Key Vault exports are narrower than they look. Some items restore only inside the same Azure subscription and geography, some cannot be copied at all, and some identity bindings never move with the data. Each card below names one constraint and the workaround teams use before the vault is removed.
Backup blobs stay in Azure
Key Vault backup files are encrypted blobs that restore only into a vault in the same subscription and geography. They are not a portable export. Treat them as a rollback copy inside Azure, not as the migration path. Before cutover, check which secrets have backups, confirm the restore region, and note the 500-version backup limit so older versions are captured another way. A controlled read of current values through the API into your staging process is usually the portable route.
Secret values through the API
Secret values can be read through the Key Vault API by identities with the right data-plane permission. Teams run a scripted export into a restricted staging store, encrypted at rest, with access limited to the migration operators. Record which version of each secret was read, and write the values straight into OpenBao rather than into files on a laptop. Confirm that the reading identity is removed once the export finishes.
Keys must be re-created
Key material, especially keys protected by an HSM, cannot be copied out of Key Vault. Plan for new key pairs in OpenBao or your chosen KMS, then re-encrypt data or re-issue dependent objects. Map each key to the workloads and services that use it, record the cryptographic operations they perform, and decide whether re-encryption, dual reads or a planned cutover fits each one. Keys that are never exported also cannot be proven identical, so verify each consumer.
Certificates reissued, not moved
Certificates in Key Vault include private keys that cannot be exported in most configurations. The practical path is to issue new certificates from OpenBao's PKI secrets engine or another CA and update each consumer, such as App Service bindings or ingress controllers. Inventory every certificate, its expiry date and its consumers before the vault is removed, so renewals do not lapse during the switch.
Managed identity and RBAC do not travel
Managed identities, Entra ID role assignments and Azure RBAC bindings are Azure objects. They do not move with secret data, and none of them is valid against OpenBao. Export a list of every principal, role and access policy attached to the vault, then map each one to an OpenBao auth method and policy. Test each application's new login path in a non-production environment before you change its configuration.
Audit history and soft-delete retention
Key Vault audit logs and diagnostic settings live in Azure Monitor and are not carried into OpenBao. Export the logs you need for compliance and incident response before the vault is deleted, and confirm where they are retained. Soft-delete retention also controls how long deleted secrets and keys can be recovered, so check that setting and plan the purge date with your change and records teams before anything is removed.
How secrets, keys and certificates each leave Key Vault
Secret values are the most direct export path. Key Vault returns a stored value to a principal that holds read permission on that secret, so the value can be retrieved and written into an OpenBao key/value path. A Key Vault backup is not a transfer format for this move, because a backup blob only restores into a vault in the same subscription and geography. Plan for versions as well: a backup covers at most 500 versions of a secret, so decide which versions the applications still need before the export starts.
- Read path: a principal with get permission retrieves the current value and any earlier versions you need, then writes them to OpenBao with the source vault name, secret name and version recorded as metadata.
- What the target receives: the plaintext string or binary value. Content type, tags and expiry dates are not part of the value and must be recorded separately.
- Plaintext approval: the secret owner and the security team should approve which secrets are read in clear, the host used for extraction and where any intermediate output is stored during the move.
- Exposure during extraction: shell history, CI logs and terminal output can echo values, so define where the extraction runs and who can see its output.
- Confirm with Microsoft: the access model that governs reads in your vault, and whether any setting in your tenant limits how secret values can be read.
Before relying on this path, confirm which identities hold read permission on each secret and what the handling rules are for any secret whose value cannot be read.
Keys leave Key Vault differently from secrets. Whether a key can be moved depends on how it was created: its key type, whether it is protected in a hardware security module, and whether it was marked exportable at creation. For most migrations the practical path is to create a new key pair in OpenBao or the target key service and then move the data that depends on the old key. Ciphertext made with the old key stays readable only while the old key is still available, so the old key must remain accessible until re-encryption is complete.
- Re-create by default: generate a new key pair in OpenBao's transit engine or in the target key management service and treat it as the key of record from that point on.
- Re-encrypt data: inventory every system that holds ciphertext from the old key, decrypt while the old key is still available, then encrypt with the new key.
- What the target receives: a new key pair with its own identifier. Key material is moved only for software keys that were marked exportable, and only in a protected format.
- Approval: the key custodian and data owners should approve each re-encryption window, and the security team should approve any movement of private key material.
- Confirm with Microsoft: whether each key was created as exportable, its hardware protection level and what the vault's access and release settings allow.
Before choosing between copy and re-create for any key, check its export setting and list the services that depend on it.
Certificates need the most documentation because a usable certificate is more than one file. The target needs the leaf certificate, its intermediate chain and, for a full move, the private key in a protected format. If the certificate policy did not allow the private key to be exported when the certificate was created, the certificate has to be re-issued by the new PKI or the issuing certificate authority instead of moved.
- Public certificate and chain: export the leaf and intermediate certificates so that every consumer can build the full trust path, and record the expiry date of each.
- Private key: exportable only if the certificate policy allowed it at creation. Otherwise, plan a re-issue and a binding change for each consumer.
- What the target receives: a certificate with its chain and, where exported, the private key in a passphrase-protected or wrapped format, loaded into OpenBao's PKI engine or into the service that consumes it.
- Approval: the PKI owner approves any private key movement, and application owners confirm the renewal dates and the services bound to each certificate.
- Confirm with Microsoft: the certificate policy on exportability, the issuer configured for each certificate and whether any renewal automation still points to the vault.
Before scheduling a cutover, confirm the policy and issuer for each certificate and the list of services that load it.
Steps to export data from Azure Key Vault in a verifiable order
This sequence moves secret values, keys and certificates out of Key Vault in an order where each step leaves evidence that the next step can check. The result is a reconciled inventory that a named owner has signed off before any vault is retired.
Inventory every secret, key, certificate and version
The vault administrator lists every secret, key and certificate, with its type, enabled state, expiry date and number of versions. Compare each version count with the 500-version backup limit, because items above it cannot be backed up in one piece and need a different export plan. Confirm the current limit in Microsoft's documentation before you rely on it. The output is a signed inventory file that becomes the baseline for every later comparison.
Confirm soft-delete and purge protection settings
The cloud administrator records whether soft-delete and purge protection are enabled on each vault and the retention period set for deleted objects. These settings decide how long a deleted secret or key can still be recovered, and purge protection can block permanent removal of the vault. Write down the retention period from the vault properties, not from memory. The evidence is the exported vault properties for each vault, reviewed by the security owner.
Take backups where Azure documents them
The cloud administrator runs the documented backup operation for each secret, key and certificate that supports it, and stores the backup blobs in a restricted location. Backup blobs restore only into the same subscription and geography, so they protect against accidental deletion but do not move data to OpenBao. Record a checksum for each backup file and the object it came from. The output is a backup manifest that the security owner signs before any values are read.
Read secret values into a controlled target
An authorized identity, approved by the service owner, reads each secret value through the Key Vault API and writes it directly into a restricted, encrypted target such as a staging OpenBao namespace. Plaintext should never land in a shared file, chat or ticket. Log the secret name, version identifier and time of each read, and keep a hash of each value instead of the value itself. The evidence is the transfer log, reviewed and signed by the security owner.
Re-create keys and re-issue certificates
The cryptography or PKI owner creates new keys in the target and re-issues certificates from the target's certificate authority, because keys are generally not handed over as the same objects. Check each key's export policy in Key Vault first, and confirm with Microsoft's documentation which key types, if any, can leave the vault. Record the new key identifiers and certificate fingerprints next to the old ones. The output is a mapping table that the owner of each consuming application signs.
Verify counts, versions and test reads on both sides
A reviewer who did not perform the migration compares the inventory with the target by counts of secrets, keys and certificates, version identifiers and checksums. For a sample of items, the reviewer runs a test read on the target and confirms the value matches the hash taken at transfer. Discrepancies go back to the migration owner with a written record. The evidence is a reconciliation sheet with every mismatch closed or explained and signed by the reviewer.
Retain evidence and plan vault removal
The data owner signs the final reconciliation and decides how long the backup manifest, transfer logs and reconciliation sheet are kept under the organization's retention policy. The vault is removed only after soft-delete retention has passed, so the team confirms that retention period from the earlier step. Keep the signed records outside the vault being retired. The output is a closure record that lists what was moved, what was re-created and what was deliberately left behind.
Why soft-delete retention sets your deadline
Soft-delete determines how long you have to finish the export before the vault or its objects are gone for good. When a vault is deleted, Key Vault keeps it in a recoverable state for a retention period that was set when the vault was created, and during that window the vault can be recovered rather than permanently removed. Individual secrets, keys and certificates follow the same pattern within a vault. Treat that retention period as the outer limit of your migration schedule, not as a safety margin you can rely on later.
Look up the retention period configured on each vault before you start, in the Azure portal or with the Azure CLI, and record it next to the vault name in your migration plan. Then check whether purge protection is enabled. With purge protection on, the vault and its objects cannot be permanently deleted before the retention period ends, which protects you from accidental purges but also means the vault stays in your subscription until that date. Confirm with your Azure administrator who can recover or purge a deleted vault, because that role decides who can act on the deadline.
Plan the export, the verification of restored or re-created values and the formal sign-off inside that window, and schedule the vault deletion only after the owning teams have confirmed their applications read from the new store. Keep a dated record of each step so that the sign-off shows which values were moved and when the source was retired. If the window is shorter than your verification work requires, decide early whether to extend the work, recover the vault, or accept the retention period as the constraint, and make that decision in writing with the people who own the workloads.
Questions teams ask before they export data from Azure Key Vault
How long does a full export from Azure Key Vault take?
The duration depends on the work around the export more than on the copy itself. The main drivers are the number of secrets, how many versions each secret holds, how many applications read each secret, and how many keys and certificates must be re-created instead of copied. Reading secret values through the API is usually quick per item, but every consuming application then needs its configuration changed, tested and cut over. No duration figure is supplied for this export, so ask any provider for a timeline based on an inventory of your own vault. Build that inventory first: count secrets, versions, keys, certificates and the applications that read each one. That count is the most reliable input for any estimate.
Can our own team export Key Vault data without outside help?
A capable platform team can run the export internally if it has the time and the access. The work needs an accountable owner, read access to the vault (secret get and list permissions, plus key and certificate permissions where they apply), and a named contact in each application team. Application owners must agree on change windows, because switching a secret source is a production change. Teams with many vaults, many consumers or strict evidence requirements often bring in an implementation partner for a fixed-scope engagement. DeployOpen plans, implements and documents this kind of work in the client's own environment, with scope and deliverables agreed in writing before work starts.
What drives the cost of exporting from Azure Key Vault up or down?
Cost follows effort, and effort follows the number of applications and the type of objects. The largest components are usually:
- Application changes, including how many services switch from managed identity or SDK calls to a new auth method.
- Key re-creation, because keys generally cannot be exported in usable form and must be created again and re-tied to the systems that use them.
- Verification depth, meaning how thoroughly each value is compared against its source before cutover.
- Operations and internal time, including the staff who own the new platform after the move.
When you request a written quote, ask for the scope split by these components, the assumptions about application count and key count, what is one-time and what recurs, and how change windows and rollback are handled.
Can a Key Vault backup restore into a different subscription?
Key Vault backup blobs are designed to restore only into the same Azure subscription and geography in which they were created, so they cannot serve as a general-purpose copy for another cloud or an on-premises platform. This is why many teams read secret values through the API and write them into the target store instead. Backups still matter as a fallback during the migration window, and they need to be retained until you have confirmed the new system works. Confirm the exact restore rules against current Azure documentation for your vault type before you plan, since they determine which steps are possible.
What happens to certificates and keys during the export?
Certificates and keys need a different plan from secrets. Secret values can be read through the API and written to the new store, but keys are generally not exportable in usable form, so they must be re-created in the target system and every dependent service must be re-pointed to the new key. Certificates often need reissuance or a new trust chain, and renewal automation must be rebuilt. Make a list of each key and certificate, its consumers, its expiry date and its renewal process before you start. Plan the cutover so that no certificate expires during the switch, and confirm with your security and PKI owners which items require re-issuance.
How do we confirm that no secret was missed in the export?
Verify against an inventory, not against memory. Start by listing every secret, key and certificate in the vault, including disabled items and older versions you need to keep. After the copy, compare names, counts and version identifiers between source and target, and check value fingerprints or hashes without logging plaintext. Then confirm that each consuming application reads from the new source in a test environment and in production. Keep the vault's soft-delete and purge protection settings in place until this check is complete, and record the results as evidence. Ask any partner to show the reconciliation method and the report it produces.
What should we plan before removing the Key Vault itself?
Removal should come last, after cutover and a monitoring period. Soft-delete retention controls how long a deleted vault or object can be recovered, so check the retention period configured on your vault and the purge protection setting before you delete anything. Keep the vault until all applications have run on the new platform through their normal cycles, including renewal and rotation jobs. Document the retention period you chose, who approved deletion and where the final inventory is stored. Confirm the retention behavior against current Azure documentation for your vault.
What to plan before the Key Vault contract or subscription ends
Removing a vault is the last step of an export, and most of the risk sits in decisions made weeks earlier. The cards below cover who signs off on each one and which records to keep, so the vault can be retired without a gap in secrets, certificates or audit evidence.
Azure subscription and billing commitments
Finance and the cloud owner decide when the subscription, reservations or enterprise agreement commitments end, and whether a vault can be deleted before that date without penalty. Ask Microsoft or your account team to confirm any commitment terms in writing. Keep the billing export and the agreement clause that governs termination, because procurement will ask for both when the Key Vault line item is closed.
Soft-delete and purge protection window
The security owner decides how long deleted secrets, keys and certificates stay recoverable before the vault is purged. Confirm whether purge protection is enabled, since it can block permanent deletion for the full retention period. Record the retention setting and the purge date in the change ticket, so nobody assumes deletion is immediate and nobody deletes early.
Application consumers and managed identity
The platform team owns the list of every application, App Service, function and pipeline that reads from the vault through managed identity or a service principal. Each consumer needs a new authentication path to OpenBao before cutover. Keep an inventory with the identity used, the secret names read and the owner who approved the switch.
Certificate renewal dates during cutover
The PKI owner decides which certificates must be renewed or reissued during the transition window, because a renewal that falls mid-cutover can fail on one side or the other. List each certificate with its expiry date, issuing path and bound services. Keep the renewal schedule and the rollback steps for any certificate that the new issuer cannot yet serve.
Audit and log retention for regulated data
Compliance and the data protection officer decide how long Key Vault diagnostic logs, access records and export evidence must be kept after the vault is gone. Confirm the retention rule with your regulator or internal policy, then export the logs to storage you control. Keep a record of what was exported, when and by whom, so the audit trail survives the vault.
Dated sign-off for decommissioning
The CISO or service owner signs the final decommissioning record after verification that applications run on the new store and backups are readable. Set the sign-off date, name each approver and attach the evidence list. Keep the signed record with the export checksums, the verification results and the date the vault was removed, so the decommissioning can be shown to auditors.
How DeployOpen scopes and delivers a Key Vault exit
DeployOpen plans and implements the move out of Azure Key Vault inside your own infrastructure, with the scope agreed in writing before work starts. We treat the export as a set of separate tracks: secret values, keys, certificates, and the soft-delete retention window before the vault is removed.
How we scope
- Inventory every vault, secret, key and certificate, and record which ones have backup blobs and which must be re-created.
- Confirm the subscription and geography constraints that apply to any Key Vault backup you intend to restore.
- Agree in writing how the 500-version backup limit and soft-delete retention affect the export order and the decommissioning date.
How we build
- Script a controlled read of secret values through the Key Vault API, with access logged and limited to named operators.
- Stand up the target OpenBao or Infisical service in your environment and map Key Vault consumers to the new auth methods.
- Test each migrated secret with a non-production consumer before any production workload is switched over.
How we hand over
- Document the export runbook, the inventory reconciliation and a per-secret record of where each value now lives.
- List every key that was re-created rather than copied, with the owner and the cutover step that depends on it.
- Deliver the decommissioning checklist, including when the vault can be removed and what evidence to keep for your assessors.
How we support
- Engagements are fixed-scope, so changes after kickoff are handled through a written change to the scope.
- Ongoing support, upgrades and continuous testing of the new secrets platform are available as a retainer.
- Confirm with DeployOpen during scoping which post-handover activities your team will own and which a retainer would cover.
