How to export your data from Akeyless

How to export your data from Akeyless before the contract ends

Static secret values and their version history can be read out of Akeyless through its documented paths, while rotated and dynamic secret targets, gateway configuration, auth setup and PKI hierarchies must be rebuilt in the target platform. Akeyless's migration tooling is designed for importing secrets into Akeyless, so leaving requires a separate export job that you plan, run and verify yourself. Start by asking Akeyless in writing which CLI commands and API endpoints return secret values, metadata and versions for your account type, and which item types, if any, are excluded from those reads. Confirm this before you commit to a cutover date.

Build an inventory before you export anything. List every item by type, path, owner and consuming application, and mark each one as static, rotated, dynamic or certificate. Only static values can be read out in bulk, so the inventory tells you what remains to be recreated. Export with a role that has read-only rights, log every export run in your own SIEM, and store the output encrypted with restricted access. Decide early whether historical versions must move at all. Most consumers need only the current value, but auditors and your retention policy may require more, and that decision changes how much data you handle. Securely delete plaintext exports once the target platform has been verified.

Rotated and dynamic targets are rebuilt, not copied. A rotated database or cloud credential needs its target configured in the new platform, and the owning team must agree on the rotation sequence so applications are not left with a stale credential. Dynamic credentials are generated on demand, so you recreate the roles that issue them. For certificates, plan a new PKI hierarchy and check whether Akeyless supports exporting private keys before assuming any key material can move. Run both platforms in parallel for a window agreed in writing, compare reads from each side, then move clients and retire gateways. Also confirm the data return, retention and deletion terms in your Akeyless agreement, since they determine what you can keep after exit.

Which Akeyless data types can be retrieved, and how

This table lists each Akeyless data type you may need to take out, the export method to confirm for it, the likely output format, and the caveats to check before you rely on it. Items marked as to confirm are not clearly supported by the public documentation we reviewed, so verify them with Akeyless or your account team before planning the cutover. The main takeaway is that static values are the easiest to retrieve, while rotated, dynamic and gateway-bound items need to be re-created in the target platform.

Data type	Export method (CLI or API)	Output format	Limits or caveats
Static secret values	Read each item by path through the Akeyless CLI or REST API, using a token with read rights on that item	Plain text or JSON from the CLI or API response, to confirm for your version	Item-by-item retrieval; confirm any bulk or pagination options and rate limits with Akeyless
Secret versions and metadata	Check whether the CLI or API returns prior values and creation, update and tag metadata for each item	To confirm; may differ between static and versioned items	Historical values may not be retrievable; confirm before assuming full version history can move
Folder and path structure	List items under each path with the CLI or API listing call, then record the hierarchy in a manifest	Listing output to be confirmed; you will likely build the mapping yourself	Plan target paths and naming before copying so that clients can be pointed at them later
Certificate inventory	List certificate items and issued certificates through the CLI or API, and record issuer, subject and expiry	To confirm; private keys may be restricted or not exportable	Private key export is an item to confirm; plan to reissue certificates from the new PKI if keys cannot leave
Rotated and dynamic secret targets	Export the target definitions and rotation settings from the console or API, not the generated credentials	Configuration only, to confirm for your items	Re-create these as OpenBao engines or Infisical rotation and dynamic settings in the new platform
Auth methods and access policies	Document roles, auth methods and access rules from the console or API before retiring them	Manual inventory or exported configuration, to confirm	Access rules do not map one-to-one, so rebuild them against the target auth methods
Gateway-bound items	Confirm which items depend on a gateway and which network targets it reaches	Inventory only	Gateway-dependent targets must be re-reached from the new platform network before cutover

Retrieving static secrets and versions through the CLI or API

Start by scripting a complete read of every static item and its available versions through the Akeyless CLI or API, because the vendor's migration tooling is built to move secrets into Akeyless rather than out of it. Confirm with Akeyless which commands and endpoints return version history for static items in your tenant and which return only the current value, since a cutover that carries only current values loses rollback history. Run the export under a dedicated, read-only export identity created for this task only, with access limited to listing and reading the items in scope. Do not reuse a production administrator or a workload identity, so that the export can be revoked on its own and its actions can be traced to a single principal in the Akeyless audit records.

Record the path hierarchy as you export, not as an afterthought. For every item, capture its full path, its item type, the version identifiers, and the owning team or workload that reads it. Map each top-level folder to a candidate OpenBao KV mount and path prefix, or to an Infisical project with environments such as development, staging and production, and note any item that does not fit that pattern. Write the output only to encrypted storage with access restricted to the named migration staff, never to a shared drive, a ticket attachment or a chat channel. Treat the export file as a second copy of your most sensitive material, which means access logging on the storage location, a defined retention period agreed with your security team, and a documented deletion step with a witness or log entry once the secrets are imported and verified.

What does not export and the workaround for each

Static secret values can usually be read back through the CLI or API, but much of what makes an Akeyless deployment work sits in configuration, key custody and client bindings. Each card below names one of these items, the workaround for it on an OpenBao or Infisical target, and the points to confirm with Akeyless before you decommission anything.

Rotated secret targets and rotation logic

A rotated secret is more than its current value. The rotation schedule, the target account it changes, and the logic that writes the new password back all live in Akeyless configuration. Export the current value as a static secret, then re-create the rotation as an OpenBao database or other engine role, or as an Infisical rotation, and test that the target accepts the new credential. Confirm with Akeyless which rotation targets and custom rotation scripts you have, and whether any of them depend on a gateway you are retiring.

Dynamic secret role definitions

Dynamic secret producers store the database connection details, the privileges granted to each generated credential, and the time-to-live rules. None of these come out as a secret value. Write equivalent roles in OpenBao or Infisical, using statements you have reviewed against the database's own privilege model. Ask Akeyless for each producer's connection target and creation statements, and confirm that consumers never relied on the Akeyless-generated usernames, because those names will change at cutover.

Issued certificates and private keys in Akeyless custody

Certificates and keys managed by Akeyless may be generated inside its key custody and cannot be assumed to be exportable. Plan to issue a new PKI hierarchy in OpenBao or Infisical rather than expecting the old private keys to move. Map every service that trusts or presents a current certificate, schedule reissue before the old chain expires, and keep the old trust anchors in place until the cutover window closes. Ask Akeyless whether private key export is supported for each key type and whether any export is documented.

Gateway configuration and access rules

Gateways hold the network paths, listener settings and access rules that connect Akeyless to your internal systems. These settings are tied to the Akeyless control plane and do not transfer to OpenBao or Infisical. Document each gateway's targets, the networks it reaches and the rules that decide who can use them, then rebuild equivalent network paths and policies in the new platform. Confirm with Akeyless whether gateway configuration can be exported at all, and what it depends on before you stop the gateways.

Auth method bindings to clients

Each client authenticates to Akeyless through a specific auth method and access role, so the binding between a workload and its permissions is defined in Akeyless, not in the secret. Rebind every client to an OpenBao auth method such as AppRole for servers or Kubernetes, or to an Infisical machine identity, and grant only the paths it needs. Do this in a staging environment first. Inventory every client through Akeyless logs or your configuration repositories, because a client you miss will fail at cutover, not during planning.

The export sequence, from inventory to verified copy

This sequence turns an Akeyless estate into a verified, encrypted copy of its static secrets and versions, with a written list of everything that has to be rebuilt by hand. Each step closes with a check you can repeat before the copy is trusted.

Inventory every item and path in Akeyless
Start by listing every static secret, rotated secret, dynamic secret target, key and certificate, along with its path, type, owning team and the clients that read it. Use the Akeyless CLI or console to enumerate items, and record counts per path in a spreadsheet or version-controlled file. Pull the list of authentication methods and gateways too, because each one maps to a client change later. The step is done when every item has one row and an owner. Verify by checking that the inventory total matches what the console reports for each folder.
Define the export identity and its scope
Create a dedicated Akeyless auth method for the export, with read access limited to the paths in the inventory and no write, delete or rotation rights. Confirm the exact permissions with Akeyless documentation or your account team, since role and capability names vary by product configuration. Store the credentials in your existing secure location and set a named owner for the identity. Verify by attempting a read on a path outside the scope and confirming it is denied, then reading an in-scope path successfully.
Run a dry-run retrieval on a non-critical path
Pick one low-risk static secret with several versions and retrieve it through the CLI or API into a temporary location that only the export operator can read. Compare the retrieved value and version metadata against what the console shows, and confirm that the retrieval itself is recorded in Akeyless audit logs. Delete the temporary file once the comparison is complete. The dry run is finished when the value, version number and timestamp all match. Verify by checking the audit log entry for the retrieval, which should name the export identity.
Export static values and versions to encrypted storage
Retrieve each in-scope static secret and its version history, writing output into an encrypted archive or a secrets-handling store with restricted access. Keep the item path, version number, creation time and value together so the copy can be traced back to its source. Run the export from a controlled host, not a laptop, and log the operator and date for each batch. The step produces one encrypted export set per batch. Verify that the archive opens only with the intended key and that its file list matches the batch manifest.
Reconcile counts and checksums against the inventory
Compare the number of exported items, versions and paths with the inventory from the first step, and compute a checksum for each exported value so you can match it against a later re-read. Investigate any gap before continuing, including items that failed, were skipped by permission or were modified during export. Record the reconciliation result in the migration log. The step is complete when every inventory row is either matched by checksum or listed as an exception with a reason. Verify by recomputing a sample of checksums from the archive and confirming they match the recorded values.
Record items that must be re-created by hand
Some items do not export as plain values. Rotated secret definitions, dynamic secret targets, the PKI hierarchy, key material that Akeyless does not release, and gateway-backed access rules need to be documented and rebuilt in OpenBao or Infisical. For each one, write the source configuration, the target engine or type, the owning team and the client that depends on it. Confirm with Akeyless and the target platform documentation which items can be exported at all. The step is done when every non-exported item has a row in the re-creation register. Verify by checking that no inventory item is missing from both the export set and the register.
Set retention and secure deletion for the exported copy
Decide how long the exported archive may be kept, who may access it, and how it will be destroyed after the cutover is verified. Put the retention date and deletion owner in the migration record, and restrict the archive to the migration team until then. Confirm the requirement with your records, legal and security teams, since retention periods depend on your policies and regulations. Deletion should cover all copies, including backups and temporary files from the dry run. Verify by producing a deletion record that lists each location and the operator who removed it, then confirming the archive can no longer be opened.

Re-creating rotated, dynamic and certificate workloads elsewhere

Rotated and dynamic credentials cannot be exported, so each one must be rebuilt as a target on the new platform. Start by listing every Akeyless rotated secret, dynamic secret and certificate issuer, and record what each one points at: which database, which Kubernetes cluster, which cloud account and which clients read it. Then map each item to a replacement. On the OpenBao side, dynamic secrets are available for systems such as Kubernetes and SQL databases, with leasing, automatic revocation and bulk revocation. On the Infisical side, secret rotation and dynamic secrets are documented for databases such as PostgreSQL and MySQL. If a target type has no equivalent on either platform, that item becomes a decision for the migration plan: keep a scripted rotation job, change the consuming application, or accept a manual process for that system. Confirm the database engine versions and plugin support for your own targets in the vendor documentation before you commit to a design.

Build each replacement in a staging environment that mirrors production topology, including the same database roles, network paths and client identities. Verify that a credential is issued, that its lease or rotation schedule behaves as expected, that revocation removes access, and that a client can reconnect after a rotation without a restart. Only then move clients, one workload group at a time, and keep the Akeyless item readable until the old and new paths have both been observed working. Record the cutover order and the rollback step for each group, because a dynamic credential that stops renewing can fail silently until its lease expires.

Certificates need the most careful planning because a new PKI hierarchy creates new trust anchors. Every client, browser, proxy and service that validates certificates from the old chain must trust the new root or intermediate before it receives a new leaf certificate, so distribute the new CA bundle first and confirm it in staging. Infisical includes a private PKI for X.509 certificates with ACME and EST enrollment, which suits automated renewal for supported clients. For OpenBao, confirm the PKI secrets engine capabilities, the supported issuance and revocation features, and the behavior of your exact version against your requirements before you design the hierarchy. Plan the overlap period, when both chains are trusted, and decide how revocation of the old issuers will be communicated.

Where each Akeyless data type lands in OpenBao or Infisical

OpenBao stores static secrets in key/value mounts, where each secret sits at a path that your policies and clients reference. Dynamic credentials for databases and Kubernetes are produced by secrets engines, so you enable the matching engine and define its connection and roles again instead of copying anything out of Akeyless. Certificates are reissued from a PKI secrets engine that you build as a new hierarchy, which means new CA trust must be distributed to clients. Servers typically authenticate with AppRole, and developer machines with Userpass, as the OpenBao auth methods documentation recommends.

Static secrets: Map each Akeyless path to a KV v2 path and keep the version history you export.
Dynamic and rotated targets: Recreate each database or Kubernetes target as an engine role, then test lease issuance before cutting over.
Certificates: Issue a new root or intermediate in a PKI mount and reissue leaf certificates to services.
Client authentication: Use AppRole for servers and Userpass for developer machines, and set policies per path.
Self-hosting points: Confirm the storage backend (integrated Raft or PostgreSQL), the unseal approach, and the HA design with your platform team.

Confirm which Akeyless plugins your target systems depend on, since any engine or plugin you do not run in OpenBao must be replaced with a different mechanism.

Infisical organizes static secrets into projects, each with environments and folders, so the Akeyless path structure usually becomes a project per application with environments such as development, staging and production. Secret versioning carries over as a new baseline, and secret syncs or the Kubernetes operator deliver values to workloads. Dynamic secrets for PostgreSQL and MySQL are configured per project, and rotation is set up in the dashboard or through configuration. Certificates are handled by the private PKI, which supports ACME and EST enrollment, so many certificate consumers can re-enroll automatically.

Static secrets: Create a project per application, then import values into the matching environment and folder.
Dynamic and rotated targets: Reconfigure database dynamic secrets and rotation schedules inside the project.
Certificates: Set up a private PKI and enroll clients with ACME or EST where your tooling supports them.
Client authentication: Use Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth for machine identities, governed by RBAC.
Licensing points: Infisical's self-hosting documentation says SSO and gateways require enterprise licensing, so confirm which features your design needs before choosing this path.

Confirm the license terms for any ee directory content you deploy, because the repository licenses it separately from the MIT Expat core.

What to plan before the Akeyless contract ends

The contract side of an exit runs on its own clock, so the notice period, data return terms and gateway shutdown need to be settled before the technical export starts. The cards below connect those commercial decisions to the export work, so that no secret, log or deletion confirmation is left behind when access ends.

Confirm terms in writing

Before you give notice, ask Akeyless to confirm in writing the notice period, the format of any data export, what data is returned, and the deletion terms that apply after termination. Verbal assurances from a sales or account contact rarely bind the vendor. Ask whether the export is a file, an API dump or a set of CLI commands, and whether it covers static secret values, versions, metadata and audit history. Your procurement or legal team should review these answers against the signed agreement.

Run a parallel period

Keep Akeyless and OpenBao or Infisical holding the same static secrets for a defined overlap period. During that time, write every new or rotated value to both systems, or script a nightly comparison of secret versions. The overlap gives you a rollback path if a client fails to read from the new store. Record which applications still depend on Akeyless so you can tell when the overlap can end.

Sequence gateway shutdown

Gateways sit inside your network and often serve Kubernetes clusters, CI runners and legacy hosts that read secrets through them. Shut down each gateway only after every client that uses it has moved to its new auth method and secret path, and after you have confirmed no traffic reaches it in your network logs. Keep the gateway configuration and host images until the final cutover check has passed, since they hold the record of which paths were served.

Obtain deletion confirmation

Once the export is verified, request written confirmation from Akeyless that tenant data has been deleted, including backups and any copies held by subprocessors, and the date on which that happened. Ask what the vendor retains for its own legal or billing obligations. Keep this letter with your exit records, since auditors and your own data protection team may ask for proof that copies of your secrets no longer exist outside your environment.

Capture logs before access ends

Export the audit and access logs you will need as compliance evidence before your Akeyless administrator and API access is removed. Identify which records cover secret reads, authentication events, policy changes and gateway activity, and which date range your assessors will expect. Confirm the export format and retention with Akeyless in advance, because logs may be unavailable once the tenant is closed. Store the archive in your own evidence repository with access controls.

Budget internal cutover time

Cutover consumes staff time that is easy to underestimate: platform engineers rebuild rotated and dynamic targets, application teams change auth and secret paths, security reviews new policies, and compliance staff collect evidence. Ask your team to inventory the clients, owners and change windows before the notice date, and agree who approves each cutover. Treat the effort as a project with named owners rather than background work, and confirm the schedule with the people who run the affected services.

Questions teams ask before exporting from Akeyless

How much effort does exporting from Akeyless usually take?

The effort depends mainly on how much is in the account, not on the export tooling itself. The main drivers are the number of paths holding static secrets, the count of rotated and dynamic secret targets that must be rebuilt in the new platform, the number of certificates and issuing hierarchies, the number of gateways to retire, and the number of client applications that must switch to new authentication. Retrieving static values through the CLI or API is usually the quickest part. Rebuilding rotation jobs, dynamic credential paths and certificate chains takes more care, and each client change needs testing. Ask for an inventory of each category before estimating, because a clear inventory is what makes any timeline credible.

Can our team export Akeyless secrets without outside help?

A capable internal team can often handle the static secret export, provided it has someone comfortable with secrets administration and scripting against the Akeyless CLI or API. Rebuilding rotated and dynamic targets, issuing a new PKI hierarchy and changing Kubernetes or CI integrations also require knowledge of the target platform's engines, auth methods and certificate handling. Check whether your team has those skills in-house, who holds access to the Akeyless tenant and gateways, and who will run the target platform afterward. Many teams split the work: they export and inventory internally and bring in an implementation partner for the rebuild and cutover. DeployOpen plans and implements these tasks in clients' own infrastructure, under a written, fixed scope.

What does the business need to provide for an export?

The export needs decisions and time from people outside the platform team. Plan for named application owners who can confirm which secrets their services use, approve the change windows in which clients switch, and test their applications after each move. Someone with authority must sign off on cutover, including the rollback point if a client fails. Compliance or security leads should agree in advance what evidence of the migration they need to keep. If Akeyless is tied to contracts or renewal dates, confirm those dates with procurement so the old platform can stay available as a fallback until the new one is verified.

How can we verify that exported secrets are complete?

Verification should compare what was exported with what the inventory says exists, rather than relying on a successful script exit. Record the number of paths and versions you expect, export them, and then count and match the results by path. Check that every client reads its secret from the new location in a test environment before production cutover. Keep the export output encrypted and access-controlled, and remove it from working directories once the import is confirmed. For rotated and dynamic targets, verification means a live test: confirm that the new engine can rotate or issue credentials and that the database or service accepts them. Ask your implementation partner which checks they will run and how the results are recorded.

What should a quote for an Akeyless export include?

A useful quote states the scope in writing before work starts. It should list the inventory tasks, the secret, certificate and rotation categories covered, and the number of client applications in scope. Deliverables should be named, such as an export report, rebuilt engines or PKI hierarchy, updated client configurations, and a runbook. It should separate Akeyless-side tasks, such as retrieving values, reviewing access and retiring gateways, from target-side work, and say which of them your staff must perform. Cutover support, test windows, handover and any post-cutover support should be stated separately. DeployOpen agrees scope, deliverables and timelines in writing before work begins and provides a quote from that scope, without a published price list.

When should we bring in a partner for a fixed-scope export?

Bring in a partner when the inventory shows rotated or dynamic targets, a certificate hierarchy to rebuild, many gateways or client applications, or when your team lacks the time or skills for a parallel run. A partner is also useful when a renewal or residency deadline leaves little room for trial and error. A fixed-scope engagement works best once the inventory is complete, because the scope and deliverables can then be agreed in writing. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, and offers ongoing support as a retainer if you need it after cutover.

How DeployOpen scopes and delivers an Akeyless exit

DeployOpen plans and implements the exit from Akeyless as a fixed-scope engagement, starting with an inventory of what must be retrieved and re-created. The work runs inside your own infrastructure, and the written scope sets the deliverables, testing and handover before any migration step begins.

How we scope

Inventory static secrets, versions, rotated targets, dynamic secret roles and certificates currently issued through Akeyless.
Map each consumer to its current Akeyless auth method and its replacement authentication path.
Agree in writing which items move, which are re-created and which are retired, with the cutover window defined.

How we build

Script retrieval of static secrets and versions through the Akeyless CLI or API, with checksums and access logging.
Re-create rotation and dynamic secret targets as self-hosted OpenBao engines, sized to your database and Kubernetes estate.
Test each migrated consumer against the new endpoints and document rollback steps before switching traffic.

How we hand over

Deliver runbooks for secret retrieval, engine configuration, client onboarding and gateway decommissioning.
Document the PKI hierarchy and certificate issuance procedures so your teams can operate them without us.
Provide evidence of migration steps and access records that your internal or external auditors can review.

How we support

Ongoing upgrades, backups and hardening of the new platform can be covered by a retainer.
Continuous security testing of the new secrets platform is available as a separate retainer.
Confirm with DeployOpen during scoping which post-cutover support model fits your operating team.

How to export your data from Akeyless