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. The Puppet-to-Ansible path in this category is a different kind of move, driven by per-node subscription cost rather than licensing philosophy, and it is more work because it swaps an architecture rather than a binary.
Why teams move
The BSL change ended truly open-source use and introduced re-licensing risk for vendors and platforms building on Terraform, Vault, and Consul. It also carries a cost dimension: HCP Terraform prices per resource and HCP Vault prices per client, so both bills climb with scale, and several Vault capabilities sit behind paid enterprise tiers. The forks, both Linux Foundation projects, restore an OSI-style open license and a community-governed roadmap while removing the per-resource and per-client license lines. Puppet’s pressure is separate: after the Perforce acquisition folded it into a commercial bundle, per-node subscription math pushed teams to re-price their config management, with Ansible the usual landing spot.
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. Because this is a secrets store, treat the unseal-material transfer as the highest-risk step and keep recovery keys protected throughout.
Puppet → Ansible
This one is not a fork swap. You translate Puppet manifests and modules into Ansible playbooks and roles, convert Hiera data into group_vars and host_vars, and replace the agent and master model with agentless runs over SSH. Migrate node by node with idempotence checks so the two systems do not fight, and plan for a scheduler such as AWX or ansible-pull to replace the continuous drift correction Puppet’s agent gave you for free.
Validate on a throwaway workspace first
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.
Diff the plans before flipping the default
Run the fork in CI alongside the incumbent for a cycle, diffing plans, before flipping the default. Keep a state or secret snapshot until you’re confident. For the fork migrations, rollback is easy because the state and storage formats are shared: you revert clients and CI to the incumbent and there is no data to un-migrate. For Puppet to Ansible, the safety net is different, Puppet keeps managing anything you have not yet cut over, so a bad role is contained to its canary nodes rather than the fleet.
The theme across all three paths is the same: the mechanical translation is the easy part, and the real cost sits in the parts that are not compatible by default, version drift between forks, integration edge cases in a secrets store, and rebuilt enforcement in a config-management move.
Open a source→target page for the exact commands and a per-resource TCO model, and use the calculator above to weigh your specific footprint before you commit.