Since HashiCorp’s switch to the BSL license, a lot of teams are shopping for alternatives by comparing feature lists: providers supported, secrets engines, policy-as-code, state locking. That comparison misses the one thing that decides how hard the move is, whether a genuine drop-in fork exists for your tool, or whether the alternative asks you to re-architect. Two paths in this category share a state or API format with the incumbent and are among the lowest-risk migrations you will find. Others swap an entire architecture and are a real project. Treat those as the same kind of decision and you will either overspend effort on an easy swap or underestimate a hard one. The better approach is to fix the factors that actually change the answer and score your situation against them first.
Inventory the tooling before you shortlist
Before you shortlist anything, write down four things: which HashiCorp tools you actually run and how exposed each is to the BSL change, what your state and secret backends are today, whether your config management is agent-based or you want agentless, and how much your existing team tooling and CI assume the incumbent’s binaries and syntax. That inventory tells you immediately whether you are looking at a binary swap with a compatible backend or a translation of manifests and workflows. Be honest about which incumbent capabilities you truly depend on rather than merely have enabled.
Drop-in fork or real re-architecture
The distinction that decides effort: is a compatible fork available, or are you re-implementing? OpenTofu forks Terraform with a compatible state format, and OpenBao forks Vault’s API and storage, so for those two the mechanical move is a pinned binary and a validated no-op or parity check, not a rebuild. That makes them the lowest-risk paths in the catalog when you validate carefully. Ansible replacing Puppet or Chef is the opposite: you translate manifests and data into playbooks and roles and swap an agent-and-master model for agentless runs over SSH. Pulumi replacing Terraform is also a re-architecture, moving from HCL to a general-purpose language and re-importing resources into new state. Knowing which bucket your move sits in is the single most useful thing you can establish before comparing anything else.
The factors that separate a swap from a project
- Fork compatibility. Is there a drop-in fork that shares your state or API format, or does the alternative re-implement the tool? This separates a low-risk swap from a project.
- State and secret backend compatibility. For the fork paths, confirm your specific backend, auth methods, and secrets engines are supported, because that is where the compatibility edge cases hide.
- Agent versus agentless model. For config management, an agentless tool removes the master and agent infrastructure but also removes the continuous drift correction the agent gave you for free. Decide whether you need a scheduler to replace it.
- Existing team tooling and syntax. A tool your CI, modules, and staff already assume is cheaper to adopt than one that is technically elegant but foreign, even before licensing enters the math.
- BSL exposure. Score how much re-licensing risk you actually carry: heavy redistribution or embedding raises the stakes, internal-only use lowers them, and that changes how urgent the move is.
- Managed convenience you are giving up. Hosted control planes and enterprise tiers bundle policy, run history, and support. Decide whether you self-host those or budget for a paid tier on the open project.
Which target fits which tool
Score your situation against those criteria, then use these as starting points. A team on Terraform that wants the lowest-risk exit from the BSL change, with existing HCL, modules, and state intact, looks first at OpenTofu. A Vault estate that needs API and storage compatibility so clients and agents keep working leans to OpenBao. A team already invested in Terraform’s ecosystem but wanting a general-purpose language and willing to re-architect considers Pulumi. Shops re-pricing Puppet or Chef after per-node subscription changes usually land on Ansible for its agentless model, accepting the manifest translation as the cost of admission. The right answer falls out of whether a compatible fork exists for your tool, not out of any project’s momentum.
Common ways this goes wrong
The most common error is assuming every alternative in this category is a drop-in because two of them are, then discovering mid-project that a Pulumi or Ansible move is a re-architecture. Close behind is skipping backend and auth-method validation on the fork paths, where an unsupported engine or a version edge case surfaces at cutover instead of in testing. Teams moving off agent-based config management often forget that they are also giving up continuous drift correction, and only notice when configuration drifts back. And many never pull the incumbent’s real renewal or usage bill, so the savings case rests on a guess.
Prove it on a throwaway workspace
Turn your top candidate into a validation on a non-production workspace with written acceptance criteria. For the fork paths, confirm a no-op plan or an API parity check, exercise every auth method and secrets engine you rely on, and run CI in dry-run mode. For a re-architecture, convert a representative slice of manifests or resources and prove idempotence before you touch the fleet. Keep a state or secret snapshot until you are confident, since for the forks rollback is simply reverting clients and CI to the incumbent. Pull the incumbent’s real renewal or usage number in parallel and model the per-resource comparison at /calculator/, treating the figures as illustrative until they reflect your footprint. Choose on validated compatibility and honest effort, not on which project has the most attention.