HashiCorp’s switch to the BSL license pushed many teams to evaluate the open forks. The good news: OpenTofu (Terraform fork) and OpenBao (Vault fork) are designed as drop-in replacements with compatible state and API formats, so these are among the lowest-risk migrations in the catalog — if you validate carefully.
Why teams move
The BSL change ended truly open-source use and introduced re-licensing risk for vendors and platforms building on Terraform/Vault/Consul. HCP usage pricing also climbs with scale. The forks restore an OSI-style open license and a community-governed roadmap.
Terraform → OpenTofu
State is format-compatible, so the core move is: pin the OpenTofu CLI, tofu init against the existing working directory and backend, and confirm tofu plan is a no-op versus Terraform. Then switch CI/CD to tofu, pin provider mirrors and the OpenTofu version, and cut over. Watch for provider/version edge cases and any Terraform-version-specific syntax.
Vault → OpenBao
OpenBao forks Vault’s API and storage. Stand it up against the same storage backend type (or restore a Vault snapshot), transfer unseal keys, and repoint clients/agents (VAULT_ADDR). Validate every auth method and secrets engine before cutover — this is where compatibility edge cases surface.
Flow & validation
Back up state and secrets, inventory modules/providers and auth methods, and validate on a non-production workspace first (no-op plan, secret read/write, each auth method, CI dry-runs). Roll out workspace-by-workspace; rollback is reverting clients/CI to the incumbent since state stays compatible.
De-risking
Run the fork in CI alongside the incumbent for a cycle, diffing plans, before flipping the default. Keep a state/secret snapshot until you’re confident.
Open a source→target page for the exact tofu/bao commands and a per-resource TCO model.