Migrating from Azure Key Vault to OpenBao: what moves and what does not
If your drivers are a renewal, a data residency requirement or a wish to stop paying per operation, the good news is that secrets and most application configuration can move to OpenBao. Keys and Azure-bound backups need a different path, because Key Vault backup blobs only restore inside Azure and key material is not something you can copy out and expect to keep working. Plan the migration as two tracks: a value-level transfer of secrets, which you read through the API and write into OpenBao, and a re-creation track for keys and certificates, which you issue or re-import under new OpenBao control with a deliberate cutover. Most teams run this with their platform or security engineering staff, often alongside an implementation partner for the parts that need hardening, integration and evidence. Be clear that the OpenBao migration guide covers in-place upgrades from Vault Community 1.14.1 on Raft storage with Shamir unseal, and it does not apply to Key Vault. It is useful background for running OpenBao, but it is not a path out of Azure. The guide also states that OpenBao was tested only against that Vault version, so treat it as a reference, not a runbook for your case. Effort and risk depend mostly on how many vaults, subscriptions and secret versions you hold, how many applications read through managed identity, and how many keys are used for encryption by Azure services. Before you commit a timeline, ask your team to inventory each vault, count secrets and their version history, list every consumer and identify which keys are customer-managed for Azure services. Confirm with the vendor and your own environment which of these items you can export and which you must rebuild, and agree the cutover order in writing before any work starts.
What maps from Key Vault to OpenBao, and what needs rework
This table maps each Key Vault capability to its closest OpenBao equivalent and marks it as clean, needs rework or gap. Read the rework and gap rows first, because they set the migration effort, and confirm each behavior against current Azure and OpenBao documentation before assuming parity.
| Key Vault capability | OpenBao equivalent | Status and what to confirm |
|---|---|---|
| Secrets with versions | KV secrets engine with version history and check-and-set writes | Needs rework. Version numbers do not carry over automatically, so map which versions consumers read and confirm the KV engine version in use. |
| Secret values readable through the API | KV read by path with the token or role holding read capability | Clean for values you can export. Confirm the policy paths and that each consumer's read call changes from the Key Vault SDK to the OpenBao client. |
| Keys (RSA, EC) with cryptographic operations | Transit secrets engine for encrypt, decrypt, sign and verify | Needs rework. Transit keys are not copied out of Key Vault. Plan to re-create keys, re-encrypt data or keep old keys available for decryption. |
| Certificates and issuance | PKI secrets engine with roles, issuers and short-lived certificates | Gap in direct transfer. Existing certificate private keys and issuance workflows must be re-issued. Confirm ACME and public CA integration separately. |
| Soft delete and purge protection | No direct equivalent. Deletion is handled by versioning, lease revocation and backup policy | Gap. Build a retention and backup process on your side and confirm how deleted versions are restored before you decommission the vault. |
| RBAC or access policies with Entra ID principals | Policies with identity-based access through JWT/OIDC, Kubernetes, TLS certificate or AppRole auth methods | Needs rework. Each Entra principal or managed identity needs a new auth method binding and a policy. Confirm the claim mapping for your identity provider. |
| Managed identity access without stored credentials | JWT/OIDC or Kubernetes auth with workload identity tokens | Needs rework. Applications change their login step. Confirm the trust configuration for Azure workload identity tokens against current Azure and OpenBao docs. |
| Private endpoints and network restrictions | Network controls at your load balancer, firewall and TLS listener | Needs rework. Azure private endpoint behavior does not carry over. Design the network path and TLS certificates for OpenBao yourself. |
| HSM-backed keys | Optional HSM integration through the enterprise or seal configuration, or external KMS for auto-unseal | Gap to confirm. Check which HSM and unseal options your OpenBao build supports before assuming the Key Vault HSM tier maps directly. |
Which data leaves Key Vault through the API and which must be re-created
Key Vault gives you two different kinds of exit. Secret values can be read through the API by an identity with read permission, which makes export a scripted, auditable job. Backup blobs, keys and integrations do not move the same way, so each needs its own plan before cutover.
Secret values through the API
An identity with read permission on the vault can retrieve each secret value and its version history, so the export is a controlled script rather than a restore. Run it under a dedicated, time-limited identity, write each value into OpenBao's key/value engine, and record the source secret name, version identifier and content type as metadata. Confirm the vault's access model first (access policies or Azure RBAC) so the export identity can read every secret without broader rights than it needs.
Backup blobs stay in Azure
Key Vault backup blobs restore only inside Azure, so they are not a portable export and cannot be loaded into OpenBao. Treat them as a rollback safety net for the vault itself, not as a migration artifact. Keep them until the last application has cut over and no rollback is planned, then document the decision and the date.
Keys usually need re-creation
Keys, especially HSM-protected keys, usually cannot be exported as usable key material, so they are normally re-created in OpenBao or its transit engine. Anything already encrypted under the old key must be decrypted with the old key and re-encrypted with the new one, or the old vault must stay available for reads. Confirm each key's export policy and whether it is exportable in Azure before you plan the data path.
Certificates and their private keys
Certificates stored in Key Vault may carry private keys that cannot be copied in the same form. Inventory each certificate, its issuer and its renewal path, then decide whether it is reissued from OpenBao's PKI secrets engine or imported with its key where the export policy allows. Confirm with your certificate authority which chains and trust anchors each consumer expects.
App Service, Functions and AKS rebuilds
App Service and Function app settings that reference Key Vault must be rewritten to point at OpenBao, and AKS workloads that mount secrets through the CSI driver need a new provider or sidecar that authenticates to OpenBao. Each consumer needs its own test, because the reference syntax and the identity it presents both change. List every app setting and pod spec that references the vault before you schedule cutover.
Pipeline variables and expiry alerts
Azure DevOps and GitHub pipelines often read secrets through variable groups, service connections or Key Vault tasks, and each must be repointed and retested. Event Grid expiry notifications also need replacement, since OpenBao does not emit them in the same way, so set lease or certificate expiry monitoring in your own alerting. Ask your platform team to confirm every subscription that publishes Key Vault events.
How applications switch from managed identity to OpenBao auth methods
Managed identity works because Azure issues the identity token and Key Vault trusts Azure's identity service to vouch for it, so every application that moves to OpenBao needs an equivalent trust relationship before its secret client is changed. In OpenBao, that trust is an auth method and a role bound to the workload. For Azure-hosted workloads running under an OIDC-capable identity issuer, the usual choice is the JWT/OIDC method, with a role that accepts only tokens whose issuer, audience and subject claims match the application. For pods, use the Kubernetes auth method with a role per service account. For servers and batch jobs that cannot present a platform token, use AppRole. OpenBao's documentation recommends Userpass only for developer machines, so keep it out of production paths. Confirm each method against the identity provider the organization actually uses, since Entra ID, a self-hosted OIDC issuer and Kubernetes clusters each expose different claims and token lifetimes. Check the claim names in a sample token before writing any role.
Design policies with one role per application and one policy per role. Each policy should grant read access to the specific KV or dynamic-secret paths that application uses and nothing else, with no wildcard paths over whole mounts. Map every existing Key Vault access policy or Azure RBAC assignment to one of these roles during the inventory, and reject any role that would grant an application access it did not have in Key Vault. Keep the mapping in version control so that auditors and the platform team can see which identity reads which path. Dynamic secrets, where an application can be issued short-lived database credentials, are a good place to tighten access after the migration, but they change how the application handles expiry, so treat them as a later step. The code change happens in each application's secret client. Replace the Azure SDK calls for Key Vault with an OpenBao client, or, for applications that should not carry authentication logic, run OpenBao Agent beside the process and have it render secrets into a file or environment that the application reads at startup. Test each application in a non-production environment with the new role and confirm that token renewal and re-authentication work when the token expires. Keep the old Key Vault read path available until every application has been verified, and record which version of each application reads from which store.
The cutover order: inventory, pilot, parallel run, cutover and decommission
This sequence moves each secret, key and certificate path from Key Vault to OpenBao with a tested rollback at every stage, so the Key Vault removal happens only after values and consumers are verified.
Inventory every vault, consumer and identity
The platform team lists each Key Vault, its subscription and region, every secret, key and certificate it holds, and every consumer that reads them, including App Service, Functions, AKS workloads and pipelines. For each consumer, record the Entra ID identity it uses and the role it holds on the vault. Record soft-delete and purge protection settings and their retention periods, because these control how long a deleted object can still be recovered. The output is a register that maps each secret path to its owner, consumer and target OpenBao path, with each key marked as either exportable or to be re-created. The step is done when the application owners have signed off the register.
Pilot one non-production application
Choose one non-production application with a small set of secrets and build a target OpenBao auth role for it, using an auth method that matches its runtime, such as JWT/OIDC for workloads that already federate identity or AppRole for servers. Point the application at OpenBao in a test environment and keep its Key Vault configuration intact so the old path can be restored by a configuration change. The output is a documented auth role, a policy limited to the paths the application needs, and a tested rollback procedure. The step is done when the application has run its test suite against OpenBao and the rollback has been exercised successfully.
Run both stores in parallel
For each migrated path, the application reads from Key Vault and OpenBao, compares the values, and logs any mismatch without changing behavior. Writes continue only to Key Vault during this stage, so the two stores do not diverge without anyone noticing. Operators confirm that each OpenBao policy denies access outside its intended path and that audit logging on the OpenBao side records each read. The output is a verification log showing matching values for every path over an agreed observation window set by the owners. The step is done when no mismatches remain and every path has been read successfully from OpenBao in production-like conditions.
Cut over application by application
Move one application at a time to OpenBao as the primary source. Before the switch, freeze writes to the Key Vault objects that application uses so that no value changes during the handover, and record the freeze in the change ticket. Switch the application's configuration to OpenBao, confirm its health checks, and keep the Key Vault copy readable as a fallback until the next step closes. Keys that cannot be exported must be re-created in OpenBao or an approved HSM-backed store, and the application's cryptographic operations must be retested against the new key. The output is a signed cutover record per application. The step is done when the application has run in production for the agreed period without a rollback and its Key Vault writes are disabled.
Decommission Key Vault after retention rules are met
Once every application is running on OpenBao, export the retained data you need for audit and recovery, store it under controls your security team approves, and document where it lives. Revoke the Entra ID role assignments and managed identity permissions on each vault, then disable the vault's access paths. Delete the vault only after the soft-delete retention window has passed and the owners confirm that no consumer still depends on it. Confirm the retention period and any legal hold requirements with your compliance lead before deletion, since these rules differ by organization. The output is a decommission record listing each vault, its final export location and the date of removal. The step is done when the vault is gone and the register from the inventory shows every item as migrated, re-created or retired.
What drives migration effort, cost and duration
This table lists the factors that change the work and running cost of moving from Key Vault to OpenBao, who is paid for each part, and what to request in a written quote. Use your own Azure invoices and the agreed written scope as the baseline, since no Key Vault prices or durations are set out here.
| Driver | Why it changes effort or cost | Who is paid, and one-time or recurring | What to request in a written quote |
|---|---|---|---|
| Number of vaults and subscriptions | Each vault has its own access policies, network rules and naming, so each one needs an inventory, a mount plan and a cutover step. | Implementation partner or internal team (one-time). Key Vault stays billed until vaults are retired. | Per-vault inventory method, mount layout in OpenBao and the retirement steps for each vault. |
| Applications and pipelines reading secrets | Every consumer needs a changed read path and auth method, and each one needs testing before cutover. | Application owners and platform engineers (one-time). Test effort is often underestimated. | Count of consumers in scope, the auth method per consumer and the test and rollback approach. |
| HSM-backed keys and certificates | Keys generally cannot be exported from Key Vault, so they must be re-created or re-issued, and every dependent service needs a new reference. | Crypto and PKI engineers (one-time). Any HSM chosen for OpenBao is a recurring hardware or cloud cost. | Key inventory with type and protection level, re-issue plan, and whether an HSM is included or optional. |
| Managed identity dependence | Services that authenticate with Entra managed identity need an OpenBao auth method or a workload identity bridge, which varies by service. | Platform and application engineers (one-time). Ongoing identity policy upkeep is recurring. | Auth method per service, how trust to Entra ID is configured, and who maintains role bindings. |
| Kubernetes and CI integrations | Secret injection, sync jobs and pipeline variables each need a different OpenBao integration, and the Helm chart requires Helm 3.6 or later. | Platform engineers (one-time). Chart upgrades and pipeline changes recur with each release. | Integration list per cluster and pipeline, Helm version, and the upgrade process for OpenBao releases. |
| Availability design | Standby nodes, storage choice and load balancing decide how much an outage costs, and PostgreSQL or Raft each carry different operating work. | Infrastructure engineers (one-time design). Servers, storage and backup run as recurring cost in your own cloud or data center. | Node count, storage backend, backup targets, failover tests and the sizing basis for each. |
| Audit evidence needs | Assessors may ask for access logs, change records, key lifecycle evidence and proof of backup restores, which must be produced from OpenBao rather than Azure Monitor. | Compliance and security engineers (one-time setup). Evidence collection and log retention are recurring. | Log destinations, retention period set by your policy, and the evidence list agreed in writing before work starts. |
| On-call and operations | Someone must patch, unseal, monitor and respond to incidents once Key Vault is no longer the operator. | Your operations team or a retained support provider (recurring). | Coverage hours, response targets written as commitments, and how upgrades and security fixes are handled. |
What usually goes wrong and how to prevent it
Most failed Key Vault exits do not fail in the cutover itself. They fail earlier, in assumptions about what can be exported, which identities hold which rights, and whether the OpenBao cluster can be recovered on a bad day. Each card below names one such risk and the check that prevents it.
Keys that cannot be copied
Key Vault does not let you export the private key material of most keys, so a key that encrypts data at rest cannot simply be carried into OpenBao. If that key is lost or left behind, the data it protects becomes unreadable. Build a key inventory before the pilot, record which keys encrypt which data stores, and plan to re-create keys in OpenBao and re-encrypt or re-wrap the data while the old key is still available. Confirm the exportability setting of each key with your own Azure administrator.
Azure backups assumed to be portable
Key Vault backup blobs are encrypted for restore inside Azure, so they cannot serve as a migration path into OpenBao. Teams that plan the move around those backups discover the gap late. Read secret values through the API with a tightly scoped identity, write them to OpenBao, and verify each value by comparing a hash or a test read. Keep the Azure backups for the rollback window only.
Hard-coded Azure SDK calls
Applications that call Key Vault through the Azure SDK or a hard-coded vault URL fail as soon as traffic moves, and some fail silently by falling back to stale cached values. Inventory every service that reads a vault URL, including App Service references, pipeline variables and Kubernetes add-ons. Put a configuration switch in front of the secret client so each service can be moved and rolled back on its own.
Auth roles too broad or missing
Managed identities in Entra ID map to Key Vault access policies or RBAC roles that do not translate one to one into OpenBao policies and auth methods. Copying a broad read rule across every workload gives too much access, while a missing role blocks a service at startup. Review access role by role: for each workload, choose an auth method such as Kubernetes, JWT/OIDC or AppRole, and grant only the paths that workload reads.
Soft-deleted vaults removed too early
Key Vault keeps deleted vaults and objects for a retention period, and purge protection can block permanent deletion. Teams that delete the vault once the cutover looks finished lose the rollback path and may find that a name cannot be reused. Confirm the retention and purge protection settings in your subscription, and keep the vault read-only until the rollback window and the data reconciliation are both closed.
Unseal and backup steps never rehearsed
OpenBao stores its own data and needs an unseal procedure after restarts. If the unseal keys, recovery material and storage snapshots are not documented and tested, a node failure can leave every application without secrets. Write a runbook covering unseal, leader failover, snapshot restore and token rotation, then rehearse it in a non-production cluster. Use the migration guide to confirm the version-specific steps before you go live.
How the migration changes by starting point
A single subscription with a small number of applications is the simplest starting point. Most of the work is inventory and application changes, not platform design. You can usually move one application group at a time and keep the vault as a read-only fallback until each group has been verified against OpenBao. Secret values can be read through the Key Vault API and written to OpenBao, because backups only restore inside Azure. Keys are a separate track, since they generally have to be re-created in OpenBao rather than copied.
- Inventory every secret reference: List each application, pipeline and script that calls the vault, including the identity it uses.
- Replace managed identity calls first: Map each identity to an OpenBao auth method such as AppRole for servers or Kubernetes auth for cluster workloads.
- Move values in batches: Read secret values through the API, write them to a KV path, and record the version numbers you migrated.
- Plan key re-creation separately: Decide which keys can be re-issued and which data encrypted under them needs re-encryption first.
- Keep the old vault until cutover is verified: Disable writes to Key Vault only after applications have been switched.
Confirm first: the number of secrets and keys, whether any consumers read certificates, and whether a single OpenBao node meets your availability requirement.
An estate with many subscriptions and pipelines usually has one Key Vault per subscription, each with its own access policies or role assignments. Consolidating them into one OpenBao service changes the design work more than the data work. You must decide on namespaces or path layout, which teams own which paths, and how pipelines authenticate. Each subscription's vault may hold different secret generations, so the inventory has to be reconciled across all of them before any value moves. Pipelines are often the hardest part because they tend to be referenced by many places.
- Design the path and ownership model: Define how paths map to subscriptions, teams and environments before writing any policy.
- Map pipeline identities: Replace service connections and managed identities with OpenBao auth methods that match each runner type.
- Reconcile duplicates: Identify the same secret stored in several vaults and decide which copy is authoritative.
- Stage by environment: Move non-production first so pipeline changes are proven before production secrets move.
- Track per-vault soft-delete retention: Plan removal dates for each vault so deletions do not conflict with cutover.
Confirm first: which team administers OpenBao, how audit logs from each source vault will be retained, and whether any subscription is in a different geography from the others.
When workloads read secrets through the Key Vault provider for the Secrets Store CSI driver, the delivery mechanism is the main change. The application code often stays the same, but the mounted files, sync behavior and pod identity all move to a different model. The OpenBao Helm chart is the recommended installation path on Kubernetes and requires Helm 3.6 or later. Plan the cluster-side work as a parallel track so that workloads can switch one namespace at a time, with rollback to the original mount if a pod fails to start.
- Install the OpenBao Helm chart in a test cluster first: Confirm the Helm version and storage choice before any production work.
- Replace the CSI provider configuration: Change SecretProviderClass resources so they point at OpenBao paths and the Kubernetes auth role.
- Switch workload identity: Move from Azure workload identity to the Kubernetes auth method and bind service accounts to roles.
- Stage by namespace: Cut over one namespace at a time and keep the previous mounts available until each rollout is confirmed.
- Test rotation and restarts: Check how pods behave when a secret changes and whether applications reload values.
Confirm first: whether your CSI setup syncs secrets into Kubernetes Secrets, which downstream tools read those objects, and whether your cluster meets the operational requirements of the chart you choose.
An estate that runs App Service or Functions with Key Vault references, or that depends on customer-managed keys for other Azure services, has dependencies that cannot all move. Key Vault references in App Service read secrets through Azure identity, so each reference needs an alternative path such as a value fetched by the application from OpenBao at startup. Customer-managed key dependencies for storage, databases or other Azure services generally remain in Key Vault. The practical split is to migrate application secrets and certificates you control, and keep the keys that Azure services depend on where they are.
- List every Key Vault reference: Find app settings and function configurations that resolve secrets from Key Vault.
- Separate application secrets from platform keys: Identify which keys are referenced by Azure services and whether those services support another key source.
- Change the application fetch path: Update code or startup scripts to read from OpenBao using an auth method that fits the app identity.
- Plan certificate moves: Review certificates bound to App Service and decide whether OpenBao PKI or the existing issuer will renew them.
- Coordinate restarts: Schedule configuration changes so that app settings and secrets change together.
Confirm first: which Azure services in your estate hold customer-managed key relationships, and whether the vendor of each service supports keys outside Key Vault for that use.
Questions teams ask before they migrate from Azure Key Vault to OpenBao
How much effort does moving from Azure Key Vault to OpenBao take?
The effort depends mostly on how many applications read from Key Vault, how many secrets, keys and certificates are in scope, and how those consumers authenticate today. Each managed identity or service principal that reads a secret needs a matching OpenBao auth method and policy, and each application needs a code or configuration change to call OpenBao instead. Key material is the other driver: keys are not exported from Key Vault in usable form, so each key used for encryption has to be re-created in OpenBao or replaced by a new key and a re-encryption step. Secret values can be read through the Key Vault API and written to OpenBao, which is straightforward per item but adds up with volume. A written scope should list each of these counts before any estimate is agreed.
How long does a Key Vault to OpenBao migration usually take?
Duration is set by the number of consumers to cut over and by the change approval process in your environment, not by the export itself. Teams usually move in waves: low-risk dev and test vaults first, then production applications grouped by owner, with a rollback path for each wave. Key re-creation and certificate reissue add time because they need coordination with the systems that trust those keys or certificates. Whether OpenBao runs as a new cluster or upgrades an existing Vault Community 1.14.1 Raft deployment also changes the schedule. Ask for a timeline in the written scope that shows each wave, its dependencies and its exit criteria, rather than a single end date.
What does the migration need from our own team?
Three groups carry most of the work. Identity owners decide how workloads will authenticate to OpenBao, for example through AppRole for servers, Kubernetes or JWT/OIDC for cloud workloads, and they approve the policies that replace Entra ID role assignments. Cloud admins own the network paths, the hosting for the OpenBao servers, storage, backup and the unseal process. Application owners know which secrets each service reads, when they can restart, and how to test after a change. Plan time for these people in advance, name one decision maker for cutover, and agree who can approve a rollback. The written scope should name each role and the hours or sessions expected from it.
Can our internal team migrate from Azure Key Vault to OpenBao without a partner?
Yes, a capable internal team can do this, and many teams do. The skills needed are OpenBao administration (auth methods, policies, storage, high availability and backup), a working knowledge of Azure RBAC and Key Vault access patterns, and experience changing application configuration in a controlled release process. The usual gaps are key re-creation planning, testing failover, and documenting controls for an auditor. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms, and most engagements are fixed-scope with deliverables agreed in writing. Your team can use that approach for the parts it lacks, or do everything itself. Confirm your skill coverage before choosing the split.
Can keys and certificates be copied from Azure Key Vault to OpenBao?
Usually no, so plan to re-create them. Key Vault keys are generally not exported as usable private key material, and its backup blobs restore only inside Azure, so they do not move the keys into OpenBao. Secrets are a different case: their values can be read through the API and written to OpenBao. For keys, the practical options are to create new keys in OpenBao's transit engine and rotate applications to them, or to re-encrypt stored data with the new key. Certificates can be reissued from OpenBao's PKI secrets engine, which needs its own trust chain and renewal plan. Each option changes which systems must be updated, so list every key and certificate and its consumers in the scope before deciding.
What does a written quote for this migration depend on?
A quote follows from the written scope, so it depends on the facts that scope captures. Ask for the count of vaults, secrets, keys and certificates, the number of consuming applications and their hosting platforms, and the authentication method each one uses today. Also note the target OpenBao topology, including whether it is a new installation, an in-place upgrade from the supported Vault Community version, or a rebuild, plus the storage backend, high availability design and backup requirements. Compliance evidence, testing expectations and any out-of-hours cutover windows also change the scope. DeployOpen does not publish a price list, so ask for deliverables, dependencies, assumptions and acceptance criteria in writing.
Does a migration from Key Vault to OpenBao lower our licensing exposure?
OpenBao is licensed under MPL-2.0 and is a Sandbox project of the OpenSSF under Linux Foundation stewardship, so its code is open source and self-hosted in your own infrastructure. HashiCorp announced on August 10, 2023 that future Vault releases would move to the Business Source License 1.1, while its APIs, SDKs and most libraries stay under MPL 2.0. Key Vault itself is billed per operation, key and renewal, so the licensing benefit is a separate question from the cost benefit. Ask your legal and procurement teams to review OpenBao's license terms against your use case, and confirm which Vault or Key Vault contracts remain in force during the transition.
How DeployOpen scopes and runs a Key Vault to OpenBao migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted OpenBao inside your own cloud accounts, data centers or air-gapped networks. For a Key Vault move, we start from a written inventory of what lives in each vault, then agree deliverables and sequencing before any cutover work begins.
How we scope
- Inventory every vault, secret version, key and certificate, and record which ones can be read through the API and which must be re-created.
- Map each consuming application from its Entra ID managed identity to an OpenBao auth method such as AppRole, JWT/OIDC or Kubernetes.
- Agree in writing the cutover order, rollback points, retained soft-delete and backup evidence, and the deliverables for the Migrate from Azure Key Vault to OpenBao engagement.
How we build
- Deploy OpenBao in your environment with the storage backend and high availability design chosen during scoping, then configure secrets engines and policies.
- Build a migration script that reads secret values through the Key Vault API, writes them to versioned KV paths, and logs each transfer for review.
- Test application logins, secret reads and failover against OpenBao in a non-production environment before any production application switches over.
How we hand over
- Document the target architecture, auth method mapping, policy definitions, runbooks for unseal and backup, and the decommissioning steps for each vault.
- Walk your platform and security teams through the cutover records, open findings and the list of keys that were re-created instead of copied.
- Provide written evidence of what was migrated, what was verified and what remains in Key Vault, so your auditors can review the change.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.
- Ongoing support, OpenBao upgrades, security patches and continuous testing are available as a retainer after handover.
- Ask any quote to separate one-time migration work from recurring operations, including who patches OpenBao and who holds on-call duty.
