Migrate from CyberArk Conjur to OpenBao

Migrate from CyberArk Conjur to OpenBao: what the move involves

A renewal notice, a licensing change or a data residency requirement is usually what brings a team to this question. The move from Conjur or CyberArk's commercial Secrets Manager to OpenBao is a re-platforming of secrets, policies and workload identities, not a file import, and the effort depends on how many hosts, CI pipelines and Kubernetes clusters read from Conjur today. Each of those consumers has its own authentication path, its own variable paths and its own failure mode when the endpoint changes, so the inventory is the first deliverable, not the last. The work is shared. Platform engineering owns the new OpenBao cluster, storage, unseal and upgrades. Security owns the policy model, auth methods and audit logging. Application and pipeline teams own the change in how each workload authenticates and reads its values. Starting points differ: Conjur Open Source server code is under the GNU LGPL v3.0, with API clients and extensions under Apache 2.0, while CyberArk's commercial Secrets Manager is licensed and supported under separate terms. Confirm with your CyberArk account team which edition and contract terms apply, because that determines what export and support options you can use during the cutover.

OpenBao is an open-source fork of Vault licensed under MPL 2.0 and stewarded by the Linux Foundation's OpenSSF as a Sandbox project. That governance matters for a team that must justify the target to a board or an audit committee, because the license and project home do not depend on a single vendor's product roadmap. It does not remove the need for your own operating model: you will run the cluster, patch it and own the keys. Before committing, check the current release and the supported upgrade path with the OpenBao releases page, and confirm with your own security team which auth methods and audit requirements your workloads need. The rest of this page covers the decision and the migration steps in turn.

Which Conjur capabilities map to OpenBao, and which need rework

This table compares the main Conjur capabilities with their closest OpenBao equivalents and labels each as clean, needs rework or gap. Read the rows as planning inputs: anything marked for rework needs a design decision before cutover, and the authenticator rows need confirmation in your own environment.

Conjur capability	OpenBao equivalent	Status	What to plan
Policy and layered RBAC	Policies in HCL with path-based ACLs, plus namespaces	Needs rework	Conjur policy language does not translate line by line. Redesign roles as OpenBao policies on secret paths, then map each Conjur host and group to an auth role.
Host and Kubernetes workload authentication	Kubernetes auth method bound to service accounts and namespaces	Needs rework	Replace the Conjur authenticator and host identity with a Kubernetes auth role per cluster. Confirm the service account and namespace bindings in your own clusters.
JWT and OIDC workload identity	JWT/OIDC auth method	Needs rework	OpenBao documents JWT/OIDC, but the claim mapping and bound claims differ from Conjur's authenticator settings. Test each identity provider and claim set.
AppRole for servers and CI	AppRole auth method, recommended for servers	Needs rework	Secret IDs and role IDs replace Conjur host API keys. Plan how secret IDs are delivered, rotated and wrapped for each pipeline.
TLS certificate workloads	TLS certificates auth method	Gap to confirm	Confirm that your Conjur certificate-based authenticator maps to this method and that certificate chains and revocation checks match your PKI.
Secret variables and versioning	Key/value secrets engine with versions	Clean	Export values through the API and re-write them under new paths. Version history from Conjur is not carried over, so decide whether it must be kept as an archive.
Dynamic secrets for databases and Kubernetes	Database and Kubernetes secrets engines	Gap to confirm	Conjur dynamic secrets do not carry over automatically. Confirm the database and Kubernetes engines and plugins against your target versions.
Leasing and revocation	Leases with automatic and bulk revocation	Clean	Lease durations and renewal logic in clients must be updated. Test revocation behavior in staging before cutover.
High availability and storage	Integrated Raft storage or PostgreSQL HA	Needs rework	Conjur storage and unseal design do not transfer. Choose the backend, unseal method and HA layout as a new deployment, and confirm the supported versions.
Audit logging	Audit devices writing to file, syslog or socket	Needs rework	Rebuild audit device configuration and SIEM parsing. Confirm that existing alerts still fire on the new event fields.

What data and integrations move, and what is rebuilt

Moving from Conjur to OpenBao is less a data import than a rebuild of the access model around it. Secret values are read again through the API, policies and host identities are translated by hand, and every workload is reconnected to an OpenBao auth method. Each area below needs its own owner and test before cutover.

Secret values re-read through the API

The conjurctl export archive is encrypted and paired with a separate key file, and it was designed for Conjur, so do not assume it loads directly into OpenBao. Plan a read job that pulls each secret through Conjur's API with a tightly scoped identity, writes it into the OpenBao KV path you designed, and records a count and checksum per path. Confirm with your own tooling which secret types, such as certificates or binary values, need special handling.

Policies translated into OpenBao policies

Conjur policy is written as YAML that grants hosts, users and groups permissions on resources. OpenBao uses HCL policies attached to tokens or entities, so each Conjur grant needs a deliberate mapping rather than a line-by-line conversion. Review every grant that uses wildcards or inherited group membership, since these are the most likely to be lost or widened during translation.

Host identities mapped to auth methods

Conjur hosts authenticate with API keys, Kubernetes service accounts, or other workload identities defined in policy. Map each host to an OpenBao auth method, such as AppRole for servers as recommended in the auth docs or Kubernetes for pods, and decide which role each identity receives. Confirm that every host class has a tested login path before retiring any Conjur identity.

Kubernetes workloads reconnected

Clusters that inject secrets through the Conjur Kubernetes authenticator or sidecar need new injection paths, usually the OpenBao Helm chart for the server and an OpenBao-compatible injector for workloads. Plan the Kubernetes auth role, service account bindings and namespace boundaries before changing any deployment. Verify that pods restart cleanly and that no workload still reads from the old Conjur endpoint.

CI pipelines and cloud workloads

Pipelines and virtual machines that fetch secrets from Conjur need new credentials, often JWT or OIDC trust for CI runners and cloud identity for instances. Test each pipeline in a non-production branch first, because a single missed variable can fail a deployment. Keep a list of every job, account and runner that held a Conjur credential so none are left behind after cutover.

Applications calling the Conjur API

Applications using Conjur client libraries or direct REST calls must be changed to call OpenBao's API, which differs in paths, token handling and error responses. Inventory each service that calls Conjur, replace the client, and run regression tests on secret retrieval, rotation and failure handling. Plan a short dual-read window only if your application code supports it and your security team approves it.

The migration sequence from inventory to decommission

This sequence moves machine secrets from Conjur to OpenBao in stages, so each workload group is proven on the new system before its Conjur path is retired. Each step closes with a named artifact that the next step depends on.

Inventory secrets, hosts and consumers
Build a register that lists every Conjur variable, host, group, policy file and layer, and the workload that reads each one. Record the authentication path each host uses, such as Kubernetes service accounts, cloud identities or API keys, and note which consumers are CI pipelines, cloud functions or long-running services. Assign an owner to each row. The step is done when the register reconciles against a fresh export from your Conjur instance and the owners have signed off on it.
Translate policy and identities into OpenBao
Map each Conjur host and group to an OpenBao auth method and policy. Typical choices include the Kubernetes auth method for pods, AppRole for servers and JWT/OIDC for CI runners, with Userpass reserved for developer machines. Write the mapping as a translated policy set in version control, and list any Conjur feature with no direct equivalent so the team can decide how to handle it. Confirm each auth method and policy syntax against the current OpenBao documentation before you rely on it.
Build the OpenBao cluster on Kubernetes
Install OpenBao with the Helm chart, which requires Helm 3.6 or later, or use another supported install path that fits your platform. Decide on the storage backend, integrated Raft or PostgreSQL, and document how unseal keys or auto-unseal are held and who can use them. Run a backup and restore test on the empty cluster. The step closes with a runbook covering install, unseal, backup, upgrade and access, reviewed by the security team.
Pilot on one non-critical application
Choose one application with few secrets, a low business impact and a clear owner. Move its secrets into OpenBao, connect it through the chosen auth method, and confirm that it starts, rotates and recovers correctly. Record every surprise, including changed paths, token behavior and failure modes, and feed those findings back into the policy set. The pilot is done when the owner accepts the result in writing and the rollback steps have been rehearsed.
Run both systems in parallel
For each remaining workload group, have the application read from OpenBao while Conjur remains the source of truth for writes. Compare the values returned by both systems, and log access so that you can show which system served each read. Watch error rates and latency during this period. The step closes when a defined window passes without unexplained mismatches and the team agrees on the window length in the runbook.
Cut over by application group
Move workloads to OpenBao in groups, such as one platform team or one environment at a time, starting with the lowest-risk group. For each group, switch the read path, remove the Conjur dependency from its deployment configuration, and keep the prior configuration available as a rollback point. Confirm that no Conjur reads occur for the group before moving to the next. Each completed group should produce a dated cutover record in the migration register.
Capture audit evidence before decommissioning Conjur
Before shutting down Conjur, collect the evidence your auditors or internal reviewers will ask for: the final inventory, the translated policies, access logs from both systems covering the parallel run, the cutover records and the backup taken before retirement. Store the archive under your own retention controls. Confirm with your auditor which artifacts they accept, since DeployOpen prepares evidence but does not issue audit conclusions. Decommission Conjur only after this package is complete and approved.

How to run Conjur and OpenBao in parallel and cut over safely

Run both systems side by side and move one cutover group at a time, where a cutover group is a set of workloads that share a secret path, an authentication method and an owner. Keep Conjur serving the group until its OpenBao path has been tested end to end, then switch the consuming pipeline, Kubernetes deployment or cloud workload in a single change. Do not treat the in-place upgrade in OpenBao's migration guide as a model for this work: that guide covers a node-by-node upgrade from Vault Community 1.14.1 on Raft storage, and it does not apply to Conjur. Moving from Conjur is a separate project with its own export, policy translation and host identity mapping, so plan it, staff it and schedule it that way.

Avoid writing the same secret to two sources of truth. For each cutover group, pick one system as the writer of record and make the other read-only or unused for that path. The safe default is that Conjur stays the writer until the group is cut over, then OpenBao becomes the writer and the Conjur variable is retired after a defined hold period. Record the owner of each group, the writer of record and the cutover date in a shared register that security and platform teams both review. Also confirm that tooling which parses tokens will handle new OpenBao tokens, which use a different and shorter format than Vault tokens, before any workload is pointed at OpenBao.

Define a rollback path for each group before cutover. The usual approach is to keep the Conjur variable and its host policy intact during the hold period, so the consuming workload can be pointed back at Conjur if OpenBao authentication or secret retrieval fails. Write the rollback steps in the change record, name who can execute them, and rehearse them once in a non-production environment. Before production, test dynamic secret behavior and lease expiry in OpenBao, including how workloads renew or re-request credentials when a lease ends and how revocation behaves. Confirm these behaviors in your own environment with a test, because the exact results depend on the secret engine and configuration you choose.

How the move differs for Conjur Open Source and commercial Secrets Manager

Conjur Open Source is licensed under the GNU LGPL v3.0, so the server code is yours to run and modify, and no vendor license key gates the move itself. Your main task is extracting data and policy from a system you operate directly. The conjurctl export command produces an encrypted archive plus a separate key file, and that archive was designed for Conjur-to-Conjur recovery rather than for import into another product. Plan to read secrets through the Conjur API and re-write them into OpenBao, and to translate Conjur policy (Users, Hosts, Layers, Groups and Variables) into OpenBao policies and auth roles by hand.

Export path: Treat the encrypted archive as a backup, not as the migration source. Read each variable through the API and record its version history you intend to keep.
Policy translation: Map each Conjur host and layer to an OpenBao role and policy. Conjur's resource-level grants rarely map one to one, so review every permission.
Host identity: Replace Conjur host authentication (for example, the Kubernetes authenticator or host API keys) with the OpenBao auth method that matches each workload.
Cutover: Run both systems in parallel for each application, switch the consumer, then retire the Conjur variable once the new path is confirmed.
Operations: You take on storage backup, unseal procedures and upgrades that Conjur's own deployment tooling handled.

Confirm with your platform team which Conjur version and authenticators you run, and whether any custom Conjur extensions depend on the Conjur API.

What drives the cost and duration of the migration

This table lists the factors that raise or lower the effort of moving from Conjur to OpenBao, with the reason each one matters and how to keep it down. Read it before requesting a quote, since each driver should appear as a line item or assumption in the written scope.

Driver	Why it changes effort	How to keep it down
Host identities and policies	Each Conjur host, user and group policy must be mapped to an OpenBao auth method role and policy. Policies with many nested grants take longer to translate and test.	Inventory policies first, group hosts by workload type, and retire unused identities before translation starts.
Secret variables and rotation patterns	Conjur variables are read back out of the running system, since the export archive is not imported into OpenBao. Variables with external rotation jobs need those jobs repointed as well.	Separate static secrets from rotated ones, and migrate rotation tooling in the same wave as the secrets it manages.
Kubernetes clusters and CI systems	Each cluster needs OpenBao Kubernetes auth configured and tested, and each CI system needs its own authentication path and pipeline changes.	Standardize on one Helm-based install pattern and one authentication approach per platform, then repeat it per cluster.
Custom integrations built on the Conjur API	Applications that call the Conjur REST API directly or use custom SDK code need code changes, not only configuration changes. Their cost depends on how many services use this path.	Count integrations that call the API directly, prefer existing OpenBao clients, and schedule code changes per owning team.
Audit and evidence requirements	Assessors may ask how access decisions, policy changes and secret reads were logged before and after cutover. Each evidence source must be rebuilt for OpenBao audit devices.	Agree the evidence list with your auditor before the pilot, and capture baseline logs from Conjur before decommissioning.
HA design and storage backend choice	Integrated storage (Raft) and PostgreSQL are the officially supported HA backends in the OpenBao documentation. The choice affects backup, failover testing and operating skills. The migration guide describes an in-place upgrade path from Vault Community 1.14.1 on Raft, which is not a Conjur path.	Pick the backend with your team's existing operations skills, and confirm the migration approach with the OpenBao documentation for your starting version.
Internal skills and on-call coverage	Teams new to OpenBao need training on policies, auth methods and unseal procedures. Gaps in skills extend the pilot and the period of parallel running.	Assign named owners for each platform, run the pilot with the team that will operate production, and document runbooks during the work.
One-time work: inventory, translation, pilot, cutover	These phases front-load effort. Inventory and translation scale with identity and policy count, and the pilot and cutover scale with the number of workloads moved in each wave.	Ask the vendor to price each phase separately and to state the entry and exit criteria for each.
Recurring work: upgrades, backups, on-call	OpenBao releases, such as v2.7.1 on October 1, 2026 per the OpenBao releases page, need planned upgrades, tested backups and on-call coverage that continue after cutover.	Ask for the upgrade cadence, backup restore tests and support hours to be stated in the quote so the recurring cost is visible.

What usually goes wrong and how to prevent it

Most failed Conjur-to-OpenBao moves fail at the edges: identities, duplicated secrets, key material, client scripts and retirement timing. The cards below name each risk and the check that catches it before production traffic depends on the new system.

Unmapped host identities

Conjur policies grant access to hosts by their identity string, and each of those hosts needs an equivalent OpenBao auth method role with its own bound claims or service account. A host with no mapping fails at cutover, often on a Friday deploy nobody watches. Build a table that lists every Conjur host, its current authentication path and its target OpenBao role, then test each one in a non-production namespace before switching.

Secrets duplicated across both systems

During a phased move, the same credential can exist in Conjur and in OpenBao, and a rotation in one system silently leaves the other stale. Pick a single source of truth for each secret path, record the cutover date per workload, and remove the old copy once the workload has read from OpenBao successfully. Otherwise two systems keep answering for the same secret.

Unseal and recovery material handled poorly

Moving to OpenBao means generating new unseal and recovery material, and the keys often end up in chat, tickets or a single administrator's laptop. Store key shares under your existing split-custody process, confirm who can reconstruct the root material, and test a restore before the old Conjur archive is deleted. Ask whether you will use Shamir keys or auto-unseal with a KMS, since each choice changes who holds the recovery path.

Token format and script breakage

Scripts that parse token strings, check token length or assume specific prefixes can fail when OpenBao issues its shorter token format. Search your CI jobs, cron scripts and runbooks for hard-coded token handling, and replace them with the auth flow and client library calls. Confirm the behavior of your specific client versions in a staging pipeline before the change reaches production runners.

Plugin and secret engine gaps

Some Conjur workflows, such as particular rotators, connectors or integrations, may have no direct equivalent in OpenBao, and the migration guide notes that mounts using plugins OpenBao does not ship are skipped. Inventory every secret store and rotation job, mark each as supported, replaceable or needing custom work, and assign an owner to every gap before the first workload moves.

Lease behavior that differs from expectations

OpenBao leases dynamic credentials and revokes them automatically at expiry, which can break applications that cache a credential longer than its lease. Review each consumer's renewal logic, set lease durations deliberately, and rehearse revocation in staging so a bulk revocation does not take down a production database connection pool.

Decommissioning Conjur before audit evidence exists

Turning off Conjur removes the access logs, policy history and proof of past secret handling that auditors may ask for. Export and retain the evidence your compliance program requires, confirm the retention period with your auditor, and keep a read-only copy of Conjur until that evidence is accepted. Shutting down first makes historical questions hard to answer.

Questions teams ask before moving from Conjur to OpenBao

How much effort does moving from Conjur to OpenBao take?

The effort depends mostly on how many secrets, policies and host identities you run, and on how many systems read from Conjur today. Each Conjur policy has to be translated into OpenBao policies and an auth method per workload type, so a small estate with a few Kubernetes clusters and one CI system is far simpler than a large estate with mixed VM, container and cloud workloads. Other drivers include how much you rely on Conjur-specific features such as host-based authorization, how many applications fetch secrets through the Conjur API or sidecars, and how well your secret ownership is documented today. Ask any vendor or partner to size the work from an inventory of your workloads rather than from a count of secrets alone.

How long does a Conjur to OpenBao migration take?

The timeline is set by the inventory, the number of workloads that must be reconnected, and the change windows your teams can accept, not by the software itself. Work usually runs in phases: stand up OpenBao in a non-production environment, translate policies and identities, move one workload group at a time, then retire Conjur access once every consumer has been verified. Dependencies such as approval cycles for production changes, certificate and trust chain setup, and coordination with application owners often take longer than the technical cutover. Ask for a written schedule tied to a defined scope, and confirm which dates depend on your own change calendar.

What does the migration need from our own team?

You need named owners for each application or pipeline that reads secrets, someone who can approve changes to production identities, and platform staff who will operate the OpenBao cluster afterward. Security needs to agree the target policy model, the auth method for each workload type, and how unseal material or a KMS key will be managed. Application teams must test their secret retrieval against the new endpoints before cutover. Expect the migration to pull in these people for a defined period, and expect ongoing operation to fall on your platform team once the project closes.

Can an internal team migrate from Conjur to OpenBao without outside help?

Yes, a team with Kubernetes, secrets management and CI experience can do it, provided it has time, a test environment and clear rollback steps. The hardest parts are usually not the commands but the translation of Conjur policy logic into OpenBao policies, the design of workload authentication, and the verification that no consumer silently loses access. Teams that lack this experience often find that the first production cutover exposes gaps. A fixed-scope engagement from DeployOpen can plan, implement, document and test the migration in your own infrastructure, and a written scope sets out what is covered before work starts.

Can we import the Conjur export file directly into OpenBao?

No. The file produced by Conjur's export tooling is an encrypted archive with a separate key file, and it was designed for Conjur, not for OpenBao. The practical route is to read each secret from Conjur through its own access controls, write it into OpenBao's key/value engine under a path you designed, and translate policies by hand or with scripts you review. Keep the export archive as a documented fallback under your retention rules, and store its key file separately. Confirm the exact export format and restore behavior for your Conjur version in the Conjur documentation before you plan the run.

Can OpenBao read existing Conjur secrets during the transition?

OpenBao does not read Conjur's storage or API directly, so during transition the usual pattern is to run both systems side by side and have each workload switch to OpenBao once its secrets and identity are in place. Some teams keep a read path to Conjur for workloads that have not moved, and retire it after the last consumer is migrated. Test that retrieval works from every environment, including disaster recovery sites, before you disable Conjur access. Confirm the behavior of any Conjur client or sidecar you rely on with the Conjur project, since its support for other backends is not something this page can assume.

What happens to our Conjur or CyberArk license when we exit?

Conjur Open Source server code is licensed under the GNU LGPL v3.0, and its API clients and extensions are under Apache 2.0, so self-hosting the open-source server carries no license fee from the project itself. Commercial CyberArk Secrets Manager is a separate contract, and its terms for notice, renewal, data return and any appliance or subscription obligations are set by your agreement, not by this page. Ask CyberArk or your reseller in writing what happens to your entitlements, support and data at the end of the term, and confirm migration support terms before you give notice. Your legal or procurement team should review the agreement, because this is a question about contract terms and not technology.

How DeployOpen scopes and runs a Conjur to OpenBao migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted OpenBao inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network. For a Conjur migration, the work is usually scoped around a few concrete decisions: which Conjur deployment is the source (Conjur Open Source or a CyberArk commercial Secrets Manager product), where the OpenBao cluster will run, which storage backend it will use, how it will be unsealed, and which workloads move first. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts. A quote follows from that written scope, so the first useful step is an inventory of Conjur policies, host identities, variables and the Kubernetes, CI and cloud consumers that read them.

The written scope should state what is in and out of the migration. Typical items include translating Conjur policy branches and host identities into OpenBao policies and auth methods, choosing auth methods for each workload class (for example, Kubernetes for pods and AppRole for servers, in line with OpenBao's own guidance), reconnecting consumers, backing up the cluster, and documenting how it runs afterward. Ongoing support, upgrades and continuous testing are available as retainers, which is often the right shape when the platform must keep pace with OpenBao releases. Ask any provider, DeployOpen included, to confirm in writing who holds the unseal material and backups, what happens if the scope changes mid-project, and how acceptance is tested.

DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration records, access policies, backup and restore results and change logs. It does not issue audit reports, attestations or certifications. Those come from independent auditors or certification bodies, so your assessor should be engaged early to agree which evidence they need. Confirm with your compliance team which control frameworks apply to your secrets platform before the scope is signed, because that determines the evidence the migration must produce.

Migrate from CyberArk Conjur to OpenBao