Migrate from AWS Secrets Manager to OpenBao

Migrate from AWS Secrets Manager to OpenBao: what the move involves

The move from AWS Secrets Manager to OpenBao is three pieces of work: export the secret values, rebuild the rotation and access paths that AWS handled for you, and cut workloads over in stages. Most readers arrive with a renewal date, a cost review, a multi-cloud workload or an air-gapped requirement, and the first task is to decide which of those drives the timeline. Export is the simplest piece. The BatchGetSecretValue API returns up to 20 secrets per call and logs a CloudTrail GetSecretValue entry for each secret, so the migration team should expect a clear audit trail of every read and should confirm with the security team that those reads are allowed under their change process. The IAM role used for export needs secretsmanager:BatchGetSecretValue and secretsmanager:GetSecretValue, plus kms:Decrypt on any customer managed key, and that role should be removed once the export is finished.

Rotation and access are where most of the effort sits. Any Lambda rotation function has to be replaced by an equivalent in OpenBao, usually the database secrets engine for dynamic credentials or a static role where an account must keep a fixed username. Workloads that authenticate with IAM roles need to move to OpenBao's AWS auth method or Kubernetes auth method, which means changing application code, sidecars or the platform's secret injection, and that work is shared between platform engineering (OpenBao servers, storage, unseal and backups), security (policies, auth configuration and audit devices) and application teams (client code and configuration). Plan a staged cutover in which each application reads from both stores during a validation window, and keep the AWS secrets in place until every consumer has been proven on OpenBao. Decommissioning needs care. AWS Secrets Manager deletes secrets after a recovery window, so the reader should confirm the configured window for each secret, avoid force-deleting anything, and only remove secrets after rollback is no longer needed. Ask a partner for a written, fixed-scope plan covering inventory, rotation rebuilds, cutover waves and evidence for auditors, and confirm the OpenBao version and upgrade path against the OpenBao releases page before any production work begins. Effort depends on secret count, the number of rotation functions and how many workloads depend on IAM-based access, so ask for those figures to be measured in your own environment rather than accepting an estimate.

Which AWS Secrets Manager capabilities map to OpenBao, and where rework is needed

This table maps each AWS Secrets Manager capability to its closest OpenBao equivalent and marks it as clean, needs rework or gap. Read the status column first, then the rework note, to size the migration work for each capability your workloads depend on.

Capability	OpenBao equivalent	Status and notes
Secret storage with versions	Key/value secrets engine with versioned secrets and metadata	Clean. Confirm version retention and metadata limits in your own environment before cutover.
IAM-based access control	Auth methods such as AWS, Kubernetes or JWT/OIDC, with policies	Needs rework. Each IAM policy must be rewritten as an OpenBao policy and bound to an auth role.
Rotation via Lambda	Database secrets engine with dynamic credentials or static roles	Needs rework. Rotation Lambdas are replaced by OpenBao configuration; services without a plugin need their own logic.
Dynamic database credentials	Database secrets engine with leases and revocation	Clean for supported SQL databases. Confirm plugin support for your engine; unsupported systems are a gap.
Encryption with KMS	Seal configuration and encryption as a service (transit engine)	Needs rework. Unsealing without cloud KMS requires a seal and unseal key plan you own and operate.
Audit logging via CloudTrail	Audit devices writing to file, syslog or socket destinations	Needs rework. Logs leave CloudTrail and must be shipped and retained in your own log platform.
Multi-Region replication	Integrated storage with high availability, or PostgreSQL backend	Gap. There is no managed cross-Region replication; design replicas and failover in your own network.
AWS-native injection (ECS, Lambda, CodeBuild)	Agents, sidecars, CSI integration or direct API calls	Needs rebuilding. Each integration must be redesigned and tested; none carry over automatically.

What to export from AWS Secrets Manager and which integrations to rebuild

Leaving AWS Secrets Manager means reading values out through an audited API and rebuilding everything that depended on AWS to deliver them. The cards below cover the export call, the permissions behind it, the audit trail it leaves, and the integrations that must be replaced rather than copied.

Read values with BatchGetSecretValue

BatchGetSecretValue returns the SecretString or SecretBinary of up to 20 secrets per call, selected by name, ARN or filter. Use it to script the export in batches of 20 or fewer, and write each value to a staging location you control with restricted access. Confirm that every secret you read is a value you intend to migrate, since unused or duplicate secrets are easy to carry over by mistake.

Scope the export role's IAM and KMS permissions

The export role needs read permission on the secrets it reads and permission to decrypt with any customer managed KMS key that encrypts them. Keep the role separate from workload roles and time-limit it for the migration. Check the key policies as well as the IAM policy, because a secret encrypted with a customer managed key can fail to decrypt even when IAM allows the read.

Plan for per-secret CloudTrail entries

Each secret returned by BatchGetSecretValue produces its own CloudTrail GetSecretValue entry, so a 20-secret batch leaves 20 records. Before the export, confirm that CloudTrail is enabled in each Region holding secrets and that logs are retained where your security team can review them. Give the security team the export window and role name so the entries can be matched to planned work.

Replace rotation Lambda functions

Rotation Lambda functions do not move with the secrets. Each one that changes a database or API credential needs a replacement, either an OpenBao database secrets engine role that issues short-lived credentials or a static role for accounts that must keep a fixed username. Inventory every rotation configuration and its Lambda before cutover, and retire the Lambda only after the replacement has run in production.

Re-point workload IAM role access

Applications running on EC2, ECS, EKS or Lambda often read secrets through IAM roles with no stored credentials. After migration, those workloads need an OpenBao auth method, such as the AWS or Kubernetes method, and policies that match the old IAM permissions. Map each role to its OpenBao policy and test the login path in a non-production environment first.

Account for KMS-encrypted references

Templates, Lambda environment variables and infrastructure code often store secret ARNs or KMS-encrypted values that point back to AWS Secrets Manager. Search your repositories and deployment definitions for these references and change each one to an OpenBao path. Confirm the decryption path separately, because a value encrypted with a KMS key is not the same as a value exported from the secret store.

The migration sequence from inventory to decommissioning

The sequence moves secrets, consumers and rotation logic from AWS Secrets Manager to OpenBao in controlled stages, so each workload is proven on the new store before the AWS copy is retired. Each step closes with a written output that gates the next one.

Inventory secrets, consumers and rotation logic
List every secret in each AWS account and Region, then map which workloads read it, through which IAM roles, and how often. Record which secrets have a rotation Lambda, which Lambda and which database or API it changes, and which values are read by CI, Kubernetes, or third-party tools. Assign an owner to each secret. The output is a single inventory sheet where every secret has a consumer list, an access path and a rotation decision (dynamic credential, static role, or retained as a stored value). The step is done when the security and platform owners sign off on the sheet.
Stand up OpenBao for the pilot
Deploy OpenBao in a non-production environment, using the OpenBao Helm chart if the target is Kubernetes, which requires Helm 3.6 or later. Configure storage, high availability and unseal key handling according to your own risk model, and confirm that the chosen storage backend and unseal method match what your operations team can support. Enable the KV and auth methods the inventory calls for. The output is a running, unsealed test cluster with documented unseal procedures and a backup restore test that has been run once.
Pilot one non-production workload
Choose a low-risk workload with a single consumer, such as a staging service. Copy its secret into OpenBao, switch the application to read it through the chosen auth method (AWS, Kubernetes or AppRole, depending on the runtime), and confirm the application starts and authenticates without an AWS credential for the secret. If the secret has a rotation Lambda, rebuild that rotation in OpenBao's database secrets engine in the pilot first. The output is a short pilot report listing auth configuration, policy scope, failure modes found and fixes made.
Run both stores in parallel
Keep AWS Secrets Manager as the source of truth while applications read from OpenBao in a controlled set of environments. Compare values during the overlap, confirm that rotated values remain consistent across both stores, and watch for drift caused by a Lambda that still rotates the AWS copy. Track which consumers still call AWS for each secret so that the cutover list is accurate. The output is a parallel-run log with zero unexplained value mismatches and a list of remaining AWS readers for each secret.
Cut over workloads in stages
Move the remaining workloads in groups, usually by environment and then by criticality, with a documented rollback for each group. For each workload, change the access path from IAM-based reads to OpenBao auth, disable the rotation Lambda only after its replacement has run successfully, and verify that audit logs in OpenBao show the expected reads. Keep the AWS secret in place until the group is stable. The output for each group is a signed change record showing the workloads moved, the rollback tested and the audit trail confirmed.
Decommission AWS secrets carefully
Confirm that no CloudTrail GetSecretValue events for a secret appear after cutover, using the per-secret logging that AWS records. Remove the IAM permissions that granted secret reads, then delete the rotation Lambdas and their roles. Schedule AWS deletion so that the recovery window for each secret is respected: AWS Secrets Manager keeps a deleted secret recoverable for a configurable period, so confirm the window in your account before deletion and keep a retained, encrypted export of the final values under your change control. The output is a closed inventory with each AWS secret marked deleted or retained, and a record of what was exported and where it is stored.

How to run both stores in parallel and cut over without downtime

The safest way to leave AWS Secrets Manager is to run both stores side by side for a fixed window, so that every workload can fall back to the AWS copy until OpenBao has proven it returns the same values. Start by writing each migrated secret into OpenBao under a KV v2 path and recording the AWS VersionId and VersionStage labels next to it. Then change each application to read from OpenBao first and fall back to Secrets Manager only on a read failure, logging which source served each request. Keep the AWS secret, its KMS key and the IAM read policies in place until the fallback counter stays at zero for the whole window. Do not delete anything during this phase, because the fallback is your rollback.

Parity needs a check that is repeatable, not a spot check by eye. For each secret, compare the decoded SecretString or SecretBinary from a fresh BatchGetSecretValue call with the OpenBao value, and compare the version lineage against the AWSPREVIOUS and AWSCURRENT stages you intend to keep. Run the comparison from a job that holds read access to both stores, and store its output as audit evidence. Confirm in your own environment how your rotation Lambdas last wrote each secret, because a rotation that fires during the window can move AWS ahead of OpenBao. Freeze rotation for migrated secrets, or repeat the comparison after every rotation event, before moving the application to OpenBao-only reads.

Replace IAM-based access as a separate step, and do it per workload. The OpenBao AWS auth method lets an EC2 instance, IAM role or Lambda function log in with its existing AWS identity, and the Kubernetes auth method does the same for pods using their service account token. Test each path against your own roles, trust policies and cluster configuration, because the claims OpenBao checks, the bound values you set and the token TTLs are environment-specific and should be confirmed with your platform team. Once a workload authenticates to OpenBao and reads every value it needs, remove its secretsmanager:GetSecretValue permission, and only then cut its fallback path. Cut over one service at a time, and keep the rollback path open until that service has run through a full release cycle.

What drives migration cost and duration, and how to keep each down

This table lists the factors that move the effort of leaving AWS Secrets Manager for OpenBao, with why each one matters and how to reduce it. Use it to scope a written quote, since most of the cost comes from inventory, consumer changes and the design of the new OpenBao cluster rather than from the software itself.

Driver	Why it moves effort	How to keep it down
Number of secrets and versions	Each secret needs an export, a target path in OpenBao and a check that the value works. Old versions usually do not need to move, but teams must decide which ones do.	Inventory first and retire unused secrets. Migrate only current versions unless an audit rule requires history. Ask the quote to state how the count was measured.
Number of consumers and integration types	Lambdas, ECS or EKS workloads, EC2 instances, CI jobs and on-premises systems each read secrets differently. Each integration needs its own change and test.	Group consumers by pattern (SDK, CLI, environment injection, sidecar). Move one pattern at a time and reuse the same auth method for each group.
Rotation Lambdas to replace	Each rotation function must be understood, then replaced by an OpenBao database secrets engine role or a static role. Custom rotation logic has no direct equivalent and needs design.	Export the rotation code and list the target database for each function. Start with the database types OpenBao supports and confirm plugin coverage for anything else.
Database count for dynamic secrets	Each database needs a connection configuration, a rotating root account, roles and a tested credential path. Applications that expect a fixed username may need changes.	Standardize on fewer database types and one role naming scheme. Ask whether static roles will be used where a fixed username is required.
IAM-based access to auth method change	Workloads currently authenticate with IAM roles. Moving them to the AWS or Kubernetes auth methods requires trust policies, role bindings and policies in OpenBao for each workload.	Map existing IAM roles to OpenBao roles in a spreadsheet. Reuse one auth method per platform and keep policies narrow and per application.
HA and storage design	Integrated storage (Raft) or PostgreSQL, the node count, load balancing and backup schedules all need to be designed, tested and monitored before production use.	Use a standard reference design from the OpenBao HA documentation. Ask the quote to list storage backend, node count, backup method and failover test scope.
KMS and unseal key handling	Moving off AWS KMS auto-unseal means choosing a Shamir or other unseal approach, storing key shares and writing a recovery procedure. Key ceremonies take coordination time.	Decide the unseal model before build. Document custodians and recovery steps, and rehearse them. Ask the quote whether a ceremony is included.
Audit logging and monitoring	CloudTrail records GetSecretValue per secret today. OpenBao audit devices and log shipping must be configured to meet the same evidence needs.	Define required audit events first. Confirm the log destination and retention with the security team before cutover.
Staff availability	Platform, security and application owners must review, test and approve each cutover. Delays in any group extend the schedule.	Name owners for each consumer group. Schedule change windows early and agree on decision points in the written scope.
Decommissioning and recovery window	AWS Secrets Manager deletes secrets after a recovery window, and both old and new values must stay valid until every consumer has moved.	Plan a dual-running period, confirm the recovery window setting for each secret, and remove AWS access only after logs show no reads.

What usually goes wrong when leaving AWS Secrets Manager

Most failed secrets migrations are not caused by the new platform. They come from the secrets nobody inventoried, the rotation logic nobody wrote down and the decommissioning step that ran before the old values were confirmed unused. The cards below cover the risks that recur and the check that prevents each one.

Missing secret consumers

A secret can be read by a Lambda, an ECS task, a CI job or a script that nobody lists as an owner. Before moving any value, pull CloudTrail GetSecretValue events for the secrets in scope over a representative period and map each calling role to a service owner. Treat any caller you cannot name as a blocker, not a leftover. Recreate each consumer's access in OpenBao only after it is named.

Undocumented rotation logic

Many secrets rotate through a Lambda function that changes the password in the database and then updates the secret in two stages. That logic often lives only in the function code and its IAM role. List every secret with rotation enabled, record what each rotation function changes and in what order, and decide whether OpenBao's database secrets engine replaces it or a static role keeps the existing account name.

Values exported without version history

BatchGetSecretValue returns the current value of each secret, not the history of previous versions. An export that copies only the current value loses the prior versions that a rollback or an in-flight deployment may still need. Capture the current version identifiers and staging labels for each secret, and confirm with application owners whether any previous version must remain available during cutover.

Hard-coded ARNs in applications

Applications and infrastructure templates often reference a secret by its full ARN, including the random suffix AWS appends. Changing the store breaks those references silently until a restart or deploy. Search IaC repositories, container environment definitions and application configuration for ARNs and secret names, then replace them with a stable OpenBao path that the application reads through its own auth method.

Unseal key loss

A self-hosted OpenBao cluster that uses Shamir unseal cannot be read after its unseal keys are lost, and the AWS-managed service has no equivalent step for the customer to hold. Before go-live, record where each key share is held, who can reach it, and how the cluster is unsealed after a node restart. Rehearse that procedure in a non-production environment before any production secret is stored.

Decommissioning before the recovery window

AWS Secrets Manager does not delete a secret immediately when it is scheduled for deletion, and the scheduled window gives time to restore it. Teams that delete secrets as soon as OpenBao works lose that safety net. Keep the original secrets and their rotation disabled until every consumer has run on OpenBao for an agreed period, then schedule deletion and confirm the recovery window setting for each secret.

How the migration differs by estate size and starting point

A small estate with a handful of secrets inside one AWS account usually has the simplest path. The main work is replacing IAM-based reads with an auth method that fits the workloads, and the export scope is narrow enough to review secret by secret. A single OpenBao node on integrated storage can be enough for a non-critical workload, but a production instance needs a deliberate high availability design and tested unseal procedures.

Auth methods: EC2 or IAM-based workloads can move to OpenBao's AWS auth method, while container workloads on EKS can use the Kubernetes auth method.
Storage backend: Integrated storage (Raft) keeps the deployment to OpenBao alone, while PostgreSQL is an option if the team already runs and backs up a database cluster.
HA design: A single node is simpler, but any production use needs a documented plan for restore and unseal.
Export scope: Reading every secret with BatchGetSecretValue is manageable, and the team can check each value against its owner.
Rotation: Few Lambda rotation functions usually means fewer database secrets engine roles to build first.

Before you start, confirm with your team how many secrets, consumers and rotation functions exist, because that list sets the scope of the work.",

Questions buyers ask before moving off AWS Secrets Manager

How much effort does moving from AWS Secrets Manager to OpenBao take?

The effort depends mostly on how many secrets you hold, how many workloads read them, and how many rotation Lambdas you must replace. Export is the simple part: BatchGetSecretValue reads up to 20 secrets per call, so the bulk of the work sits in the workloads. Each application that reads through the AWS SDK needs a change to authenticate to OpenBao, and each rotated database credential needs a decision on whether a dynamic database role or a static role fits better. Teams with many small services and few shared patterns should expect more effort than teams with a few large workloads. Ask any provider to split the estimate into export, workload changes, rotation redesign, platform build and cutover testing so you can see where the cost sits.

How long does a migration to OpenBao typically run?

No fixed duration applies, because the timeline is set by your environment rather than by the tool. The main drivers are the number of applications and environments to move, the number of secrets that need a rotation redesign, how many teams must sign off on changes, and the change windows in your production estimate. Platform setup, including the OpenBao server design, high availability backend and unseal approach, is usually scoped separately from the workload cutover. Run a pilot on one non-production workload first, then move in waves. Ask for the schedule as dated milestones in a written scope before work starts.

What does the migration require from our own team?

Your team supplies the knowledge that no outside party has. You need owners for each application that reads secrets, someone who can approve IAM and Kubernetes role changes, the database administrators who will grant the OpenBao database engine its privileges, and a security lead who approves the unseal and key custody model. Your cloud team must also confirm which AWS accounts, Regions and KMS keys hold secrets today. Expect the application owners to test their own services after each change, because only they know the expected behavior. Agreeing these responsibilities in the written scope prevents delays at cutover.

Can our own engineers migrate off AWS Secrets Manager without a partner?

Yes, a capable internal team can do it, and the OpenBao documentation covers installation, auth methods and the database secrets engine. The questions to answer honestly are whether you have people who can run a Raft or PostgreSQL backed cluster, manage unseal keys and backups, patch the servers and respond to incidents at night. The migration itself is less demanding than the ongoing operation. Many teams split the work: they keep application changes in house and bring in outside help for the platform design, hardening and cutover rehearsal. DeployOpen plans, implements and documents this work in your own infrastructure under a fixed scope agreed in writing, and ongoing support is available as a retainer.

What happens to the AWS Secrets Manager recovery window when we decommission?

Deleting a secret in AWS Secrets Manager does not remove it immediately. It is scheduled for deletion after a recovery window, and during that window the secret can be restored. Before you schedule any deletion, confirm that every workload has stopped reading the value, that OpenBao serves the same credentials, and that rollback is still possible. Keep the AWS copy until the new path has run through at least one full business cycle. Confirm the current recovery window length in the AWS documentation for your account and Region, because it is a setting you control and should be checked against your rollback plan rather than assumed.

How do we export secret values safely from AWS Secrets Manager?

Export uses the BatchGetSecretValue API, which returns the SecretString or SecretBinary of up to 20 secrets per call, selected by name, ARN or filter. The calling principal needs read permission on each secret and decrypt permission on its KMS key. Every value read produces a CloudTrail GetSecretValue entry, so the export is itself auditable. Run it from a locked-down host, write output directly into a controlled location, and avoid copying values into chat or tickets. Record the export in your change log and remove any temporary files after import. Confirm with your security team how long exported material may exist.

How do we move from IAM-based access to OpenBao auth methods?

Workloads that authenticate with IAM roles today can move to the OpenBao AWS auth method, while Kubernetes workloads can use the Kubernetes auth method and servers can use AppRole. OpenBao documents AppRole as its recommended choice for servers, so teams often map each IAM role to a policy and an auth role, then remove the broad secret read permissions once each service is confirmed working. Keep the old IAM access in place until cutover is verified. Check the exact configuration for your chosen method in the OpenBao auth documentation, since the required settings depend on your identity setup.

How DeployOpen scopes and runs a move from AWS Secrets Manager

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted OpenBao inside your own infrastructure, so the migration is scoped as a set of deliverables before any secret is read. A typical written scope covers the OpenBao deployment topology, the storage backend and high availability design, unseal key custody, the auth methods that replace IAM-based access for each workload class, the dynamic or static roles that replace rotation Lambdas, the secret export and import runbook, the cutover plan and the decommissioning steps for AWS Secrets Manager. Engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before work starts. A quote follows from that written scope, so the variables you should expect to see are the number of secret families, the number of workloads and clusters that need new auth paths, the rotation logic to rebuild, and the environments (development, staging, production, and any isolated network) that must be covered. When you review a proposed scope, check who holds each responsibility after handover. Ask whether the agreement names who stores the unseal keys and recovery material, who receives the OpenBao audit device output, who owns the CloudTrail review for the GetSecretValue entries that the export produces, and when AWS Secrets Manager is set to a recovery window that you will not shorten until every consumer has moved. Ask for the rollback steps in writing as well, because a migration is only reversible while the AWS copies still exist. DeployOpen prepares systems, configuration, access records and evidence for compliance assessments, such as the logs, change records and control descriptions an auditor will ask for. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies perform those assessments. Ongoing support, upgrades and continuous testing are available as a retainer, which is useful once OpenBao upgrades such as the release line changes in the OpenBao releases page need to be planned against your change windows.

Migrate from AWS Secrets Manager to OpenBao