Why an OpenBao storage migration needs a plan before the first command
The move uses bao operator migrate and requires an offline window, so the cluster stops serving requests while its data is copied to the new backend. Teams usually start this work because the cluster runs on the file backend, which cannot provide high availability, and the decision is to move to integrated storage (Raft), PostgreSQL or PebbleDB. The command itself is short. The effort lies in everything around it: the window, the dependencies, the rollback path and the people who must agree to all three.
Effort depends on three things: the size of the cluster and its stored data, the backend you choose, and how many systems depend on the cluster. Each application, pipeline, Kubernetes workload, database secrets engine and certificate consumer authenticates against OpenBao and expects it to be reachable at the same address after the window closes. Build an inventory of every client, the auth method it uses and the secrets paths it reads before you pick a date. That inventory determines how long the window must be and who has to be told when it opens and closes.
Before any command runs, confirm the versions in use on both sides. Read the OpenBao migration guide and the release notes for the OpenBao version you are targeting, and check whether the cluster was bootstrapped on an older Vault line, since that can change what must be done first. Review the server configuration for settings that no longer apply in the target release. Confirm with your platform team which backend version and high availability design you will run afterward, because the backend choice changes how the cluster is operated once the move is complete.
Plan the rollback before you plan the cutover. Take a full backup of the source storage, restore it into a scratch environment and confirm that the cluster starts and that a test secret can be read. Locate the unseal keys and recovery material and confirm that the people who hold them are available during the window. Write down the conditions under which you will stop and return to the original backend, and name the person who makes that call. A migration without a tested restore path is a bet on the first attempt going right.
What carries over in an OpenBao storage migration and what needs rework
This table compares the source cluster with the target storage setup for Raft, PostgreSQL or PebbleDB. Read the target column as what the new cluster needs, and the notes column as what your team must verify before cutover. The main takeaway is that storage and HA configuration must be rewritten, while secrets, policies and client endpoints still need explicit checks in your version.
| Item | Target equivalent | Migration notes |
|---|---|---|
| Secrets and encrypted data | Secrets encrypted before write to the new backend | Secrets are re-read from the new backend after the move. Confirm which items your version carries across. |
| Auth methods | Same method types and mount paths on the target | Confirm which auth method configuration migrates. Test AppRole, Kubernetes and any LDAP or OIDC logins before cutover. |
| Policies and namespaces | Policies and namespace paths on the target cluster | Check policy text and namespace structure after the move. Namespaces remain available for multi-tenant isolation. |
| Leases and tokens | Lease state handled by the new backend | Confirm lease and token handling in your version. Plan for clients to re-authenticate if tokens do not carry over. |
| Storage and HA stanzas | New storage stanza for Raft, PostgreSQL or PebbleDB, with matching HA settings | These settings change and must be rewritten. Raft and PostgreSQL are the officially supported HA backends. |
| disable_mlock | Setting removed from configuration | OpenBao stopped using mlock in 2.0.0. Remove disable_mlock from configuration as the migration guide directs. |
| TLS and listener settings | Listener and certificate paths reviewed on each node | Confirm which TLS settings carry over unchanged. Keep certificate files in place on every node before the move. |
| Client endpoints and URLs | Same API address and URLs after cutover | The migration guide keeps endpoints and URLs unchanged for in-place replacement. Verify load balancer and DNS targets. |
How bao operator migrate moves data between storage backends
The core of a storage backend migration is an offline copy. The team stops all writes to the OpenBao cluster, uses bao operator migrate to copy the contents of the source backend into the target backend, verifies the result, and then starts the nodes with a storage configuration that points at the new backend. Each step depends on the one before it. If writes continue while data is copied, the target will be missing changes made after the copy began, so the sequence has to be planned as one window rather than as a series of independent tasks. Before the work starts, confirm in the current OpenBao documentation for your version exactly how the command expects the cluster to be stopped, sealed or otherwise quiesced, because the supplied facts do not describe the flags or the length of the offline window.
Preparing the target comes first and usually takes the most planning. For integrated storage (Raft), the team must define the node layout, peer discovery and TLS between peers before the cutover. For PostgreSQL, the team needs a database, a dedicated role with the privileges OpenBao requires, and a network path from every OpenBao node. The OpenBao storage documentation describes PostgreSQL as an easier backend to operate safely than Raft, which is a useful input when the choice is still open. PebbleDB stores data locally on each node, so it suits a different topology and should be assessed against your high availability needs. Whichever target is chosen, check that the database version is still supported. PostgreSQL 14 is supported until November 12, 2026, so a new deployment should normally target a newer major version.
The move off the file backend needs its own plan. OpenBao's HA documentation names integrated storage and PostgreSQL as the officially supported HA backends, so a cluster on the file backend is usually moving to one of them for resilience as well as for a new storage location. That makes the cutover a change of cluster shape, not only a change of storage path. Rehearse the full sequence on a copy of the data, keep a verified backup of the file store together with the unseal material, and write down the rollback path before the window opens. Ask the implementation partner and your own operators to confirm whether the file backend is supported as a source for the version you run, and whether any node-specific files need to be handled separately.
Verification happens before the nodes are returned to service. After the copy completes, start one node against the new storage configuration, unseal it, and check that a known set of secrets, auth methods, policies, audit devices and leases is present and readable. Only then start the remaining nodes so they join the new backend. If the cluster was bootstrapped in Vault, also confirm the migration guide's requirements for that path, including removing disable_mlock from configuration, which the guide says must be done because OpenBao stopped using mlock in 2.0.0. Record the measured offline window from the rehearsal, and use that measurement, not an assumed figure, when you agree the change window and the written scope with your partner.
Documented storage backends and the tools around each one
Each OpenBao storage option has different high availability behavior, operating tools and failure modes. The documented migration path is bao operator migrate, and the storage documentation sets the limits you must confirm before choosing a target.
Integrated storage (Raft)
Integrated storage keeps OpenBao data in a Raft cluster run by the OpenBao nodes themselves, so no separate database is required. The HA documentation lists Raft as one of two officially supported HA backends, and since OpenBao 2.5.0, Raft standbys can serve read-only operations. For this migration, plan the node count, the snapshot and restore procedure for Raft data, and disk and network sizing for each node. Confirm the Raft-specific limits in the storage documentation before you commit.
PostgreSQL
PostgreSQL stores OpenBao data in a database that your team may already operate. The storage documentation describes it as easier to operate safely than Raft, and it is one of the two officially supported HA backends. v2.7.0 extended read-only standby serving to PostgreSQL. Your PostgreSQL tooling becomes part of the OpenBao recovery design: continuous archiving with point-in-time recovery, connection pooling through PgBouncer, and an external failover tool, because PostgreSQL does not detect a primary failure on its own.
PebbleDB
PebbleDB is a documented storage backend for OpenBao, and it is a candidate target when your design does not need the PostgreSQL or Raft operating model. Confirm its high availability model in the storage documentation before you select it for a production cluster. Ask the team to define how PebbleDB data directories are backed up, restored and verified after the copy, and how the cutover and rollback work if the target fails after the offline window ends.
In-memory backend
The in-memory backend keeps OpenBao data only in process memory, so stored secrets do not survive a restart. The storage documentation lists it as a documented option, which makes it suitable for development and test environments, not for production secrets moved from another backend. Use it only for rehearsal runs of the migration, and confirm how the documentation describes data loss and unseal behavior before any run that touches data you care about.
bao operator migrate
bao operator migrate is the documented path for copying existing OpenBao storage from one backend to another. The command reads a configuration that defines the source and destination storage, and the cluster must be offline for the copy, so the offline window must be planned with the business owners. Rehearse the command on a copy of the data, verify key counts and sample reads after the run, and keep the original backend untouched until the cutover is accepted.
Backend limits to confirm
This migration page does not replace the storage documentation. Limits such as supported versions, HA behavior, locking, data size guidance and recovery steps differ by backend and can change between OpenBao releases. Ask the team to confirm each limit for the exact OpenBao version you run, such as v2.7.1 if that is your target, and for the exact PostgreSQL major version if you choose that path. Record the confirmed values in the design before the offline window is scheduled.
Choosing PostgreSQL or Raft for the OpenBao cluster
Choose the storage backend by deciding who will run it for the life of the cluster. Both integrated storage (Raft) and PostgreSQL are officially supported high availability backends for OpenBao, so neither is the unsupported option. The OpenBao storage documentation describes PostgreSQL as easier to operate safely than Raft, which is why many teams lean toward it. Raft keeps replication inside the OpenBao nodes, so there is no separate database to patch, back up or monitor. PostgreSQL moves that work to a database team. Before you migrate, name the group that will own the database and confirm it can meet the recovery expectations for your secrets service.
Next, compare your existing PostgreSQL skills and backup practice with what the cluster will need. If your organization already runs PostgreSQL with tested backups and point-in-time recovery, OpenBao data can inherit those controls with little new process. Ask the database team to restore a recent backup into a scratch environment and time the result. If that practice does not exist, the database becomes a new single point of failure for secrets. Raft also needs its own snapshot and restore procedure, so the team must learn and rehearse a backup method in either case. Whichever you choose, confirm that backups and recovery material are protected separately, because a database dump alone does not replace your unseal and recovery keys.
Plan failover explicitly, because PostgreSQL does not detect a failed primary and promote a standby on its own. The PostgreSQL failover documentation states that external tools are needed for automatic failover. You must select, deploy, test and operate that tooling, and a misconfigured failover tool can cause split brain, which is harder to recover from than a simple outage. Raft handles leader election among OpenBao nodes without a separate failover product, which reduces the number of moving parts. If you choose PostgreSQL, decide whether a connection pooler such as PgBouncer sits between OpenBao and the database, then test how that pooler behaves during a primary change before cutover.
Finally, check PostgreSQL version support and read scaling before you pick a major version. PostgreSQL supports each major version for five years after its initial release. The supported versions include 14, which is supported until November 12, 2026, and 18, which is supported until November 14, 2030. Confirm the current dates against the PostgreSQL versioning policy, since a version that is near its end of support will need an upgrade soon after cutover. For read scaling, OpenBao 2.5.0 let Raft standbys serve read-only operations, and OpenBao 2.7.0 extended that to PostgreSQL standbys. Confirm the OpenBao version you will run and test read behavior with your clients before you rely on it.
What drives the cost and duration of an OpenBao storage migration
This table lists the factors that change how much planning, rehearsal, cutover and post-migration work a storage move needs, who is paid for each part, and what to ask for in a quote. Read each row against your own cluster inventory, because several drivers compound when they appear together. The main takeaway is that the offline window and the number of dependent auth integrations usually matter more to effort than raw data volume.
| Driver | Effect on effort and who is paid | What to ask for in a quote |
|---|---|---|
| Cluster and node count | Each cluster and node adds rehearsal runs, leader and standby checks and post-cutover validation. Planning and rehearsal are usually the largest paid blocks for DeployOpen; the client's platform team supplies access and change approvals. | Per-cluster and per-node assumptions, and whether rehearsals run once per cluster or once per environment. |
| Data volume and key count | Larger stores lengthen the copy and verification phase and the cutover window. Effort is driven more by object count and secret path sprawl than by bytes alone, so inventory both. | Assumed data size and object count from a bao operator migrate dry run, and the verification method the quote includes. |
| Dependent systems and auth integrations | Each application, pipeline, Kubernetes integration, LDAP or OIDC method and PKI consumer must be checked after the move. This is usually the largest source of post-migration work, and integrations are often the hidden cost. | A named list of integrations in scope, and who tests each one (client owners, DeployOpen or both). |
| Target backend choice | Raft keeps storage inside the OpenBao cluster and needs peer-level operations skills. PostgreSQL adds a database to operate and back up, but the OpenBao docs describe it as easier to operate safely. Choosing a backend early avoids a second migration. | The backend recommendation with its reasons, and whether the quote covers the database build or assumes an existing PostgreSQL service. |
| Offline window availability | Moving off the file backend requires a window in which the cluster is not serving requests. Without an agreed window, rehearsal and cutover effort grows because teams must design a workable plan around business hours. | The window length the plan assumes, the approval process for it, and a rollback plan priced separately if the window is exceeded. |
| State of existing backups | A current, restore-tested backup reduces risk and rehearsal scope. Missing or unverified backups add a backup-and-restore task before any migration step begins. | Whether a backup restore test is included, and who produces the pre-migration snapshot. |
| PostgreSQL operations maturity | If the client already runs PostgreSQL with tested backups, monitoring and failover, effort falls. If not, the quote needs time for database hardening, connection handling and point-in-time recovery design before OpenBao can use it. | Whether database build, high availability and recovery testing are in scope or assumed to exist. |
| Change control and approvals | Formal change boards, security sign-off and evidence requirements add planning and documentation effort. These steps are usually paid as planning time and are often under-scoped in first estimates. | Documents the quote will produce, such as the change plan, rollback steps and cutover record, and how many approval cycles it assumes. |
| Number of environments | Staging, pre-production and production each need their own rehearsal and verification. Running the same procedure in a lower environment first is what makes the production window predictable. | Which environments the rehearsal covers, and whether production work is priced as a separate phase. |
| Recurring costs after cutover | Ongoing costs include database or Raft node operations, backup testing, OpenBao upgrades and monitoring. These recur on your own staff time or on a support retainer, and they are separate from the one-time migration fee. | A separate line for post-migration support, its scope and whether it is a retainer or a per-incident arrangement. |
The sequence for a storage move with a rehearsal, cutover and decommission
This sequence moves OpenBao from its current storage backend to Raft, PostgreSQL or PebbleDB with a verified backup at each stage. The rehearsal and the cutover runbook carry most of the risk reduction, so most of the preparation goes into them. The team confirms which parallel-run options fit its topology before committing to a path.
Inventory the current configuration and data
The platform team records the storage stanza, listeners, HA settings, seal configuration, auth methods, secrets engines, namespaces, audit devices and plugins from every node. They confirm which backend holds the data today, including whether the cluster still runs on the file backend, which requires a move. They take a backup and confirm they can read it. The output is a written inventory that the security owner signs off, along with a backup the team has restored at least once.
Check versions and remove disable_mlock
The team confirms the current server version and the target OpenBao release, then reads the migration guide against both. They check whether the cluster was bootstrapped before Vault 1.3, since that may require a rekey before the move. They remove disable_mlock from every node's configuration, because OpenBao stopped using mlock in 2.0.0. The output is a reviewed configuration diff for each node and a recorded version check.
Build and size the target backend
The team chooses Raft or PostgreSQL based on the operating skills they hold and the HA model they want. The OpenBao storage documentation describes PostgreSQL as easier to operate safely than Raft, which weighs toward it for teams without Raft experience. Sizing starts from the data volume in the inventory and the number of HA nodes. The team checks the supported PostgreSQL major versions before choosing one. The output is a healthy empty target with TLS, monitoring and a tested restore.
Rehearse the move on a copy of the data
The team restores a copy of the production backup into an isolated environment that matches the target backend. They run bao operator migrate with the cutover runbook, so each command and its expected output are tested before production. They then check that secrets decrypt, auth methods log in, policies apply, leases and audit devices work, and HA elects a leader. Every deviation from the runbook is recorded and fixed. The output is a rehearsal log and a revised runbook.
Run a parallel or validation period where possible
Where the architecture allows, the team runs the new backend alongside the existing cluster for a validation period, using a copy of the data kept in sync or refreshed from backups. Not every topology supports this, so the team confirms which parallel-run options apply to its nodes, load balancers and HA design with the platform owner before planning around them. If no parallel run is possible, the rehearsal results become the main evidence. The output is a recorded decision on the validation approach.
Execute the production cutover in the offline window
During the agreed offline window, the team stops client traffic, takes a final backup and seals the cluster according to the runbook. They run the migration with the tested commands, then start nodes against the new backend and unseal them using the documented procedure. A go or no-go checkpoint sits before traffic returns, with a named owner and a rollback path. The output is a cluster serving requests from the new backend and a signed cutover record.
Verify health and confirm backups after cutover
The team checks node health, confirms that one active node holds the lock and that standbys respond as the topology expects, and runs read and write tests against the new backend. They confirm dynamic credentials issue and revoke, audit logs write, and client applications authenticate. They then confirm the new backup job runs and restore it into a test environment. The output is a verification checklist with results and a confirmed backup for the new backend.
Decommission old storage and retain recovery material
After the agreed observation period, the team retires the old storage and removes its configuration. Before deletion, they keep an encrypted copy of the final pre-cutover snapshot, the unseal and recovery material, and the last backup of the old backend. Access to these items is restricted and recorded under the organization's retention policy. The output is a decommission record that lists each retained item, its location, its owner and its access controls.
Planning the offline window and the rollback path
The offline window is the period when the OpenBao cluster cannot serve requests while its data moves from the current storage backend to the new one. Before anyone schedules it, list every client that depends on OpenBao and note how each behaves when the service is unavailable. Applications that read dynamic database credentials may fail or stall once their cached credentials expire. Kubernetes workloads that authenticate through the Kubernetes auth method or a secrets injector may restart or retry. CI pipelines and automation jobs may fail mid-run. For each client, record how it caches secrets, how often it renews leases, and whether it retries on its own. That inventory decides the notification list, the freeze on deployments, and which teams must be online during the cutover. The exact length of the window is something you confirm in a rehearsal on a copy of your data, using the same hardware class and storage sizes as production. Do not take a duration from this page or from a colleague's previous project. Time each stage separately: stopping the nodes, running the migration, starting the new backend, unsealing, and running health checks. Repeat the rehearsal with a realistic data volume, because copy time grows with the amount of stored data. The rehearsal also shows which client checks fail first, which gives you a list of things to test again in production. Decide the rollback criteria before the cutover starts, not during it. Write down the conditions that trigger a return to the original storage, such as a failed data verification, a health endpoint that stays unhealthy past an agreed point, or application failures that the rehearsal did not predict. Name the person who makes that call and the people who carry out the steps. Agree in advance how long the team will wait before choosing rollback, so the decision is not made under pressure at the end of a long window. Rollback needs three things kept intact. First, leave the original storage untouched. Do not delete, overwrite, or reformat the file or source data until the new backend has run in production for an agreed period. Second, take a snapshot or backup of the source immediately before the migration and test that it can be restored. Third, keep the prior server configuration, including the storage stanza, listener settings and seal configuration, in version control. Keep a record of who holds the unseal or recovery material and where the procedure to use it is stored. Confirm with the migration documentation which parts of the source data the tool changes, so you know what the original backend will still contain. Rollback becomes harder once clients write to the new backend. From that moment, new secrets, leases, tokens, certificates and audit entries exist only in the new storage. Returning to the original backend then discards those changes or requires a careful reconciliation. Set a clear checkpoint after which you commit to the new backend, and decide whether to freeze writes until that checkpoint passes. Ask your implementation team to show you, in the rehearsal, exactly how a reversal would be performed and what data would be lost or need replay.
What usually goes wrong in a storage backend move and how to prevent it
Most failed storage moves trace back to a short list of causes: an unproven backup, configuration the new server rejects, clients that still reach old nodes, a lock that never settles, PostgreSQL operations nobody owns, and a first attempt made in production. Each card names the prevention step and the check that shows it worked. Run these checks before the offline window opens and again before you accept the move.
Stale or unverified backup
The backup is the rollback point, so it must be current and restorable. Take a fresh backup immediately before the offline window, record its identifier and checksum, and restore it into a separate environment. Confirm the restored data matches the source by comparing key counts and a sample of known secret paths, and confirm the unseal material works against the restored copy before you accept it as the rollback point.
Configuration left in an old format
Configuration carried over from a Vault deployment can stop a node from starting. The clearest case is disable_mlock: OpenBao stopped using mlock in 2.0.0, so the setting must be removed from every node before it starts. Review each node's file against the target storage stanza and the migration guide, and check whether the cluster needs a rekey first, which applies to clusters bootstrapped before Vault 1.3. Confirm all nodes start cleanly in a staging run.
Clients still pointing at old endpoints
The migration guide keeps endpoints and URLs unchanged, but clients often address specific hosts through load balancers, DNS records, agent templates or pinned addresses. Where the move adds or replaces nodes, those references can keep sending traffic to stopped or outdated nodes. Inventory every consumer, confirm each one resolves to the active cluster address, and verify that a test login and a secret read succeed from each client group after cutover.
HA lock or leader problems after cutover
In an HA setup, one active node holds a lock in the data store and standby nodes forward or redirect requests. A lock left over from the old backend, or nodes that disagree about the leader, can leave the cluster sealed, unavailable or split. Confirm the new backend holds the lock, that exactly one node reports active, and that standbys redirect correctly. Then run a controlled leader step-down test before you close the window.
PostgreSQL operations and failover gaps
The OpenBao docs describe PostgreSQL as easier to operate safely than Raft, but it still requires ownership of backups, point-in-time recovery, minor and major upgrades, connection pooling and replication. PostgreSQL does not detect a failed primary or promote a standby on its own, so automatic failover needs external tooling that you select, deploy and test. Confirm who runs the database day to day and that the failover tool has been rehearsed before you choose this backend.
Missing rehearsal and unassigned roles
A first run of bao operator migrate against production data leaves no room to learn the sequence. Rehearse the full move on a copy of the source storage with the same node count, configuration and client set, timing each step and recording the exact commands. Name one owner for the cutover decision, one for storage and one for client changes, and agree in advance who can stop the window and start a rollback. Check that the runbook was followed and that the rollback was exercised.
Questions teams ask before moving OpenBao storage
How much does an OpenBao storage migration cost?
DeployOpen does not publish a price list, so cost follows from the written scope. The main drivers are the number of clusters and nodes, the storage backend you choose, whether the target database already exists and is run by your team, the volume of data to move, and how many environments need the move (test, staging and production). Labor is usually the largest component: planning, a rehearsal on a non-production copy, the production window, validation and handover documentation. Ask for a quote that separates one-time migration work from any recurring support or retainer, and that lists what your team provides, such as access, approvals and change windows.
How long does moving OpenBao storage take?
The duration depends on the scope, so no standard figure applies. The main drivers are the backend choice, the amount of data in storage, the number of clusters and environments, the approvals and change windows your organization requires, and whether a non-production rehearsal is included. Preparation goes faster when a tested backup and a documented rollback path already exist. Ask the provider for a schedule tied to milestones (assessment, rehearsal, cutover and validation), and confirm which steps sit inside the fixed scope and which depend on your change calendar. Confirm the expected migration steps for your OpenBao version in the vendor documentation before agreeing on dates.
What does our internal team need to provide for the migration?
Your team provides access, decisions and operating knowledge. The work moves faster when these are ready before the engagement starts. Typical needs include:
- Access to the current cluster, configuration files and the storage backend.
- A named owner who approves the change and a production change window.
- A backup and restore capability your team has tested.
- Someone who can answer questions about identity, networking, DNS, certificates and load balancers.
- Application owners who can validate their secret paths and integrations after cutover.
Agree on who is on call during the window and who makes the go or no-go decision before the work begins.
Can our own team migrate OpenBao storage without an outside partner?
Yes, if the team has the skills and time, and it plans the work carefully. The work needs working knowledge of OpenBao configuration and high availability, the target backend, Linux service management, TLS, and backup and restore. Check three gaps before deciding: whether the team has rehearsed the procedure outside production, whether anyone has carried out a storage cutover on this platform before, and who will be available during the window. An outside partner typically adds the most value in planning, rehearsal and independent validation. Confirm your team's skills against the migration steps in the OpenBao documentation for your version.
Should we choose PostgreSQL or Raft for OpenBao storage?
Decide based on the operating skills and databases your team already runs. The OpenBao storage documentation describes PostgreSQL as easier to operate safely than Raft, which matters if your team has little experience with Raft clusters. Integrated storage (Raft) keeps data inside the OpenBao nodes, so you run no separate database. PostgreSQL places storage in a database your team must back up, patch, monitor and make highly available. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL. For PostgreSQL, check that your server version is still supported. Version 14 is supported until November 12, 2026, and version 18 is supported until November 14, 2030.
How is the offline window for an OpenBao storage move set?
The offline window should come from a timed rehearsal on a copy of your data, not from an estimate. It covers the steps that must run while OpenBao is stopped, the time to copy and verify the data, the restart and the validation of dependent applications. Drivers include data volume, the number of nodes, the backend, the verification depth and the time needed to roll back if validation fails. Services that depend on OpenBao, such as applications, agents and CI jobs, will be affected, so plan their behavior during the window. Confirm with the vendor documentation whether OpenBao must be stopped for your version and which steps are required.
What happens if the storage cutover fails partway through?
The result depends on the rollback plan agreed before the window, so confirm that plan in writing first. A sound plan takes a verified backup before the window opens, keeps the original storage intact until validation passes, and defines the steps to restart the original configuration. Ask who makes the rollback decision, how long rollback may take, and what happens to any data written during a partial move. Test the rollback during the rehearsal. DeployOpen cannot promise a clean outcome for any cutover. It delivers the plan, runbook, validation steps and documentation that your team can review and approve before the window.
How DeployOpen scopes, runs and supports an OpenBao storage migration
DeployOpen treats an OpenBao storage move as a planned change to a live secrets service. We confirm the current backend, the target backend and the offline window with your team before any node changes, then rehearse bao operator migrate in a non-production copy. Each stage ends with documented evidence your team can review and keep.
How we scope
- The written scope names the source backend, target backend (Raft, PostgreSQL or PebbleDB) and the reason for the move.
- It records whether the cluster is leaving the file backend, which forces the move, and its current OpenBao version.
- It sets the offline window, the rollback point, and the sign-off each side needs before the change starts.
How we build
- We rehearse bao operator migrate on a copy of the data in a non-production environment, using the same OpenBao version.
- We check the new backend's storage, sealing, HA and access settings, including PostgreSQL role permissions or Raft peer layout.
- We review configuration against the OpenBao migration guide, including disable_mlock, before the target nodes start.
How we hand over
- Handover includes the migration runbook, the exact commands used, and the timings and checks recorded during the rehearsal.
- Your team receives a rollback procedure for each backend, tested as part of the rehearsal before the production window.
- Documentation covers the chosen backend, its backup and restore approach, and the operating notes your engineers need.
How we support
- Post-migration checks confirm seal status, storage health, and that secrets and leases are readable after the cutover.
- Ongoing support for the backend, upgrades and later changes can run as a retainer after the migration closes.
- Later PostgreSQL or Raft upgrades are scoped separately, since each has its own version and upgrade path.
