Export data from CyberArk Conjur without assuming the archive moves
If a renewal, licensing change or residency requirement is pushing you toward OpenBao, the first question is whether the export you can run today will carry your secrets into it. conjurctl export produces an encrypted archive and a separate key file, and both are designed for Conjur's own restore path. The archive is a backup you can reload into Conjur. OpenBao does not read it. Plan the move on that basis: secret values are read out through the Conjur API or CLI and written into OpenBao, and Conjur policy is translated by hand into OpenBao policies and auth roles. Before you commit, check the archive contents against the version of Conjur you run, including whether policy, host identities and audit history are included, and whether the key file is required to decrypt it.
The open-source path and the commercial path differ, so confirm each one separately. Conjur Open Source is documented in its Conjur GitHub repository, and that is where you check the export behavior for your release. For CyberArk's commercial Secrets Manager, Self-Hosted, CyberArk documents a migration guide, but the export tooling, formats, supported versions and any contractual limits on extraction must come from CyberArk in writing. Expect some items to need separate handling in either case: secret values, host and workload identities that are tied to Kubernetes service accounts, cloud roles or certificates in your environment, and the policy statements themselves. Ask the vendor which of these the archive includes and which it does not, and do not assume the archive is a complete inventory of what your workloads depend on.
Before you schedule a cutover, run a test export against a non-production Conjur instance and restore it into a scratch environment to confirm the key file works. Then build an inventory that maps each secret to the pipeline, pod or cloud workload that reads it. OpenBao's migration guide describes an in-place upgrade from Vault Community 1.14.1 on Raft storage, so it does not cover Conjur data, and you should treat the Conjur re-reading as a separate project. Record the decisions that follow from the inventory: which OpenBao auth method replaces each Conjur host identity (OpenBao recommends AppRole for servers), who holds the key file, and how long encrypted archives are retained. Store the key file apart from the archive so that neither is useful on its own.
Which data types can be exported and by which documented path
This table lists the main data types held by a Conjur deployment and the export path documented for each. Read the export column as what conjurctl export produces for Conjur Open Source, and the last column as what to verify before planning a move to OpenBao. The main takeaway: the archive is encrypted and depends on a separate key file, so decryption and re-reading secrets are planning steps, not a simple import.
| Data type | Documented export path | Format | Limits and what to confirm |
|---|---|---|---|
| Variables and secret values | conjurctl export for Conjur Open Source | Encrypted archive plus a separate key file | Confirm the archive can be decrypted in your environment and test it before decommissioning Conjur |
| Policy definitions | Included in the export only if your Conjur version confirms it | Conjur policy files | Confirm with CyberArk whether policy is inside the archive; plan to translate it to OpenBao policies by hand |
| Host and group identities | Not confirmed as a direct export to OpenBao | Conjur resource definitions | Confirm whether identities transfer; in OpenBao, workloads need auth method roles instead |
| Roles and memberships | Not confirmed as a direct export to OpenBao | Conjur role graph | Confirm the export format with CyberArk; map each role to an OpenBao policy and auth binding |
| Audit records | Not part of the archive as documented here | Conjur audit logs in your logging stack | Confirm retention with CyberArk and keep logs from the Conjur period; OpenBao audit devices start fresh |
| Commercial Secrets Manager | Confirm the export path with CyberArk for each row | Confirm with CyberArk | Do not assume the Open Source archive format applies to CyberArk's commercial product |
What does not carry over and how to rebuild it
The export archive holds secret values and a key file, but the logic around those values lives elsewhere. Policy, host identity, audit history and auth configuration each need a separate rebuild step on the OpenBao side, and each one carries its own risk if it is skipped.
Conjur policy language
Conjur expresses access as YAML policy with roles, resources and permissions, and the export does not convert that policy into OpenBao. OpenBao expresses access as HCL policies attached to tokens and identities, so the two models do not map one to one. Inventory every Conjur policy branch, list which hosts can read which variables, and write the equivalent OpenBao policies by hand. Test each one with a non-production token before cutover, because an over-broad policy is easy to write and hard to notice.
Host identities and authenticators
Conjur hosts authenticate with their own identities and authenticators, such as Kubernetes service accounts or cloud identities, and those bindings are not in the archive. In OpenBao, each workload needs an auth method and a role that trusts its identity. Map each Conjur host to a target method, for example AppRole for servers, Kubernetes for pods or JWT/OIDC for CI pipelines, and confirm the trust settings with the team that owns each workload. Do not reuse Conjur credentials as OpenBao credentials.
Conjur audit trail
Conjur audit records describe who read or changed which secret and when, and that history is not part of the encrypted archive. OpenBao writes its own audit devices to the destinations you configure, so history from before cutover stays in the Conjur system. Decide how long you must keep the old audit records, where they will be stored and who can read them. Confirm the retention requirement with your compliance owner before the Conjur environment is decommissioned.
Auth configuration and plugins
Authenticator settings, such as trusted CA certificates, token audiences and allowed namespaces, are configured per Conjur installation and are not carried into OpenBao. The OpenBao migration guide also states that mounts using plugins OpenBao does not ship are skipped during an in-place upgrade from Vault. Make an inventory of every authenticator and plugin in use, mark those with no OpenBao equivalent, and plan a replacement or retirement for each one.
Dynamic secrets and rotation jobs
Conjur stores static values, and any rotation scripts or external jobs that update them live outside the archive. OpenBao can issue dynamic secrets for databases and Kubernetes with leases and revocation, but that requires new engine configuration and new consumers. Identify each rotation job and decide whether it moves to an OpenBao engine or continues as a script that writes to KV. Confirm which consumers need code changes, since they will read from different paths and use different token formats.
Export sequence and verification for a complete handover
This sequence produces a verified inventory of Conjur policies, secret values and consumers that can be loaded into OpenBao. The conjurctl export archive is one input to the handover, not the handover itself. Each step closes with a check and a named owner, so the team can show what moved, what was tested and what remains in Conjur.
Inventory secrets, policies and host identities
The Conjur administrator and the policy owners list every variable, policy, group, layer and host identity in the instance, and record which application, pipeline or cloud workload reads each variable. Keep the list in version control or a controlled document, not in a chat thread. The step is complete when every variable has a named owner and a named consumer, and the policy files in your repository match what the instance actually contains. Gaps found here are cheaper to resolve before the export starts.
Run the documented export and separate outputs
The Conjur administrator runs conjurctl export as described in the CyberArk documentation for your Conjur version. The command produces an encrypted archive and a separate key file. Store the archive and the key file in different locations, with different access groups, and log every access to either one. The step is complete when both files exist, the archive is not empty, and the key file is confirmed to sit outside the archive's storage location.
Test restore in a non-production Conjur
A Conjur administrator with a second engineer restores the archive and key file into a separate, non-production Conjur instance. This confirms that the backup is usable and that the pair works together. Compare the restored policies, host identities and variable count with the inventory from the first step. Restore success does not mean the data can be read directly by OpenBao, because the archive is a Conjur backup format, not an OpenBao import format. The step is complete when the restored counts match the inventory.
Extract secret values through the Conjur API
Use a dedicated, authorized identity with read access to the variables in scope to retrieve each value through the Conjur API. Write the output to an encrypted destination with restricted access, never to tickets, chat or shared drives. Record each retrieval in the migration log, including failures and permission errors. The step is complete when every variable in the inventory has either an extracted value or a logged reason it was not extracted, and the identity is removed or its access is revoked afterward.
Record counts and checksums per path
The migration engineer records, for each secret path, the number of values extracted and a cryptographic hash of each value, such as SHA-256. Store the hashes and counts in the migration record, never the values themselves. The totals must match the inventory from the first step, and each path must show the same count of values. The hashes are used later to confirm that the values loaded into OpenBao match the values exported from Conjur. The step is complete when the totals reconcile without unexplained differences.
Verify each secret against its consumer
After values are loaded into OpenBao and each consumer is pointed at the new path, the consumer owner confirms in a test environment that the workload authenticates and reads the expected secret. Recompute the hashes on the OpenBao side and compare them with the recorded values. Each consumer owner signs off on a checklist entry. Secrets without sign-off stay in Conjur until the gap is closed, and the Conjur decommissioning decision waits until every entry is signed off and the retention requirement for the archive is confirmed.
Why a move to OpenBao means re-reading secrets and translating policy
The key point for this section is that a conjurctl export archive cannot be loaded into OpenBao. OpenBao is a fork of HashiCorp Vault, and it has its own key/value engine, policy language and auth methods. Conjur stores variables, policies and host identities in its own model, so the output of the export is an encrypted archive with a separate key file, designed for restoring a Conjur server rather than feeding another secrets manager. Plan the move as a re-read of each secret from the running Conjur system, written into OpenBao through its API or CLI, not as a file transfer. Confirm with CyberArk which export format and key handling your Conjur version uses before you rely on the archive for anything beyond a backup.
Policy and identity need the most translation effort. Conjur host identities are defined in policy and authenticate workloads through mechanisms such as Kubernetes service accounts or application identities, while OpenBao expresses access through auth methods, roles and ACL policies. Each Conjur host therefore has to be mapped to an OpenBao auth method, such as Kubernetes or AppRole, and to a policy that grants only the paths that host used. Inventory every host and the variables it reads before writing any OpenBao policy, because a path that works in Conjur may need a different name or mount in OpenBao.
OpenBao's migration guide describes an in-place, node-by-node upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, and it was tested only against that version. That path does not apply to Conjur, which is a different product with a different data model, so do not read the guide as a Conjur procedure. For the full sequence of exporting variables, translating policies and reconnecting Kubernetes, CI and cloud workloads, use the sibling topic on migrating from CyberArk Conjur to OpenBao.
What to plan before the Conjur contract ends
Export is the easy part to start and the hardest to finish on time. Each item below sets a constraint on the others: how long you can reach a working Conjur instance, who holds the key file, and which workloads still depend on the secrets. Settle them in writing with CyberArk before the renewal or termination date, not after.
Export window and live access
Confirm in writing how long you keep access to a working Conjur instance after the contract ends, and whether that access is read-only. The export runs against the live server, so a deprovisioned tenant or an expired license can block it. Schedule the conjurctl export run with a rehearsal first, and keep the instance reachable until the archive has been verified.
Custody of the key file
The export produces an encrypted archive and a separate key file. Without the key, the archive is unreadable, so the two must be stored apart and both must survive the handover. Name the people who hold each file, record where they are kept, and test a decryption on a separate machine before the source system is decommissioned.
Inventory of consuming workloads
List every Kubernetes deployment, CI pipeline and cloud workload that reads secrets from Conjur, including the host identity and authentication method each one uses. Most of the migration effort sits in reconnecting these consumers to OpenBao auth methods, so an incomplete list becomes an outage after cutover. Record the owner of each consumer, not just the team.
Parallel-run period
Plan a window in which Conjur and OpenBao both serve secrets, so each consumer can be moved and verified one at a time. Agree with application owners how a rollback works if a consumer fails after switching. Keep the parallel run short enough that secrets are not maintained in two places for longer than your change process allows.
Policy translation review
Conjur policies do not import into OpenBao. Someone must read each policy, decide which permissions still apply, and write the equivalent OpenBao policies and roles. Assign a reviewer who understands both models and compare the resulting access for each identity against the original, so that no workload gains or loses access by accident.
Licence terms and completion date
Ask CyberArk to confirm in writing the licence end date, the data retention period after termination, and what happens to stored secrets and audit logs. Then set a completion date for the export and verification, working back from the contract end. Treat that date as a decision point for whether the migration proceeds or the contract is extended.
Questions buyers ask before they export from Conjur
How much effort does a Conjur export take to plan and run?
The effort depends on three things: how many secrets you hold, how many workloads read them, and how complex the policy tree is. Running the export itself is a single command on the Conjur server, so most of the work sits downstream: translating policies and host identities into OpenBao policies and auth methods, then reconnecting each consumer. Ask for an inventory of secret count, host and layer count, policies with nested group or host relationships, and the pipelines and clusters that fetch secrets. A quote should tie each of those counts to a line item in the written scope, so you can see which part of the effort your environment drives.
Can our own team run the export and migration without outside help?
Yes, if you have Conjur administrators who understand the policy tree, application owners who can test their own workloads, and time to rehearse the move in a non-production environment. Teams that attempt it alone usually underestimate the consumer side: CI jobs, Kubernetes deployments and cloud workloads each need their authentication changed and tested. An outside partner is most useful for the parts that are easy to get wrong, such as translating policy semantics and proving that every consumer still reads the right secret. DeployOpen plans and implements self-hosted platforms in your own infrastructure, and a fixed-scope engagement can cover only the pieces your team wants to hand over.
What access and change windows does the export require from us?
The export needs administrative access to the Conjur server and the ability to run the command under an account your security team has approved. You also need named owners for each application or pipeline, because they must confirm which secrets they read and approve cutover. Plan change windows for each consuming system, since switching a workload from Conjur to OpenBao usually means a configuration change and a restart or redeploy. Ask for a written list of required accounts, approvers, and freeze periods before work starts. Good scoping keeps owners from being surprised during the window and keeps the cutover order visible.
Can the conjurctl export archive be imported directly into OpenBao?
Not as a direct restore. The conjurctl export produces an encrypted archive plus a separate key file, which is designed around Conjur's own data model. OpenBao's published migration guide covers an in-place upgrade from Vault Community 1.14.1 on Raft storage, not a Conjur archive format. In practice, secrets are read through the Conjur API and written into OpenBao key/value paths, and policies are rewritten by hand. Confirm this path with OpenBao and CyberArk for your exact versions before you plan the work, and treat any tool claiming a direct import as something to test in isolation first.
What should we confirm with CyberArk for the commercial Secrets Manager?
Start with whether your edition includes the export tooling you plan to use, and whether CyberArk's migration guide to Secrets Manager, Self-Hosted applies to your deployment. Confirm the licensing terms that allow you to export and retain data during a move, and whether support covers the archive format and key file handling. Ask how long the commercial subscription must run during a parallel period, and what CyberArk supports if a migration stalls. The open-source Conjur code and its documentation are public in the Conjur GitHub repository, which helps your team check behavior before you talk to CyberArk.
How do we verify that the export and re-entry are complete?
Verify completeness by reconciliation, not by trusting the export. Build a list of every variable path per policy in Conjur, then confirm that each one exists in OpenBao with the same value and a documented owner. Read each secret back, and test every consumer's authentication path against OpenBao in a staging environment. Compare audit logs on both sides for the expected read pattern after cutover, and confirm that Conjur access is revoked only after the last consumer is switched. Keep the reconciliation report as part of your change record, so the evidence for each secret is available to auditors and to the owners who sign off.
Who should hold the archive and key file during the move?
Store the encrypted archive and the separate key file in different custody, with access limited to named people for the duration of the migration. Do not place both on the same workstation, shared drive or CI runner. Record who generated the export, who received it, and when each copy was destroyed. Set a retention rule that deletes the archive and key once reconciliation passes and the Conjur source is decommissioned, and add that deletion to the change log. Ask your security team to approve the handling procedure before the export runs, since the archive contains secret material.
Does DeployOpen scope and run the export and re-entry work?
DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own infrastructure, and the migration of secrets into OpenBao falls within that work. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that written scope, and the inventory questions above are what shape it. Ongoing support, upgrades and continuous testing are available as retainers after cutover. A useful first step is a written scope that lists the inventory, the consumers in scope, and the verification method.
How DeployOpen scopes and delivers a Conjur exit
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, including the work of moving Conjur secrets and policy into OpenBao. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- We inventory which Conjur variables, policies, hosts and layers your teams use, and which sit in Conjur Open Source or the commercial product.
- The written scope names each workload, pipeline and cluster that must reconnect to OpenBao, and what stays out of the work.
- We ask you to confirm how the export key file is stored, who holds it, and where decrypted values may appear during the project.
How we build
- We run conjurctl export against a copy in a controlled environment and verify the archive can be read before any cutover planning.
- We re-read each secret through its Conjur API path and write it into OpenBao mounts, instead of importing the encrypted archive.
- We translate Conjur policy statements into OpenBao policies and map host identities to auth methods such as AppRole, Kubernetes or JWT/OIDC.
How we hand over
- Handover includes a secret inventory mapping each source variable to its OpenBao path, owner and consuming workload.
- We document the policy translation, auth method configuration and any Conjur features with no direct OpenBao equivalent, for your review.
- We test reconnection of Kubernetes, CI pipelines and cloud workloads, and record results and remaining decommissioning steps for Conjur.
How we support
- Ongoing support, upgrades and continuous testing of the OpenBao deployment are available as a retainer after handover.
- Retainers can cover OpenBao version upgrades, such as the releases tracked on the OpenBao releases page, with testing before rollout.
- Backup, unseal and high availability procedures are documented in your environment, so your team can run them after the project closes.
