In my earlier piece on Terraform multi-cloud module design I said both tools remain viable. That's still true. But the question comes up in almost every platform review, so here is the checklist I use to answer it for a specific organisation rather than in general.
Where things stand
- Licence. Terraform has shipped under HashiCorp's Business Source License since version 1.6; OpenTofu remains under MPL 2.0 with Linux Foundation governance21.
- Ownership. IBM's acquisition of HashiCorp completed in February 2025. Commentary notes it didn't change the licence but raised questions about long-term direction1.
- Features. OpenTofu added client-side state and plan encryption in 2024, and has since added capabilities such as provider iteration and early variable evaluation that Terraform lacks12. Terraform has its own additions, so configurations increasingly depend on which tool they target.
Most commentary agrees on one point: for teams running Terraform against their own infrastructure, the licence matters less than it does for vendors building competing products13. Several of these sources come from vendors that support both tools, so weigh their framing accordingly.
The checklist
- Do you sell infrastructure tooling or a hosted platform? If so, have counsel review the BSL. This is the case where the licence matters most.
- Is open-source licensing a policy requirement? Some public sector and regulated organisations require OSI-approved licences. That points to OpenTofu.
- Do you need a specific feature? Native state encryption is a common reason to choose OpenTofu where state contains secrets. Check whether a Terraform-only feature you rely on would block a move.
- What does your tooling support? CI pipelines, policy engines, cost tools and your managed platform. Most support both, but verify.
- How large and old is the estate? Small, well-tested estates migrate easily. Large estates with many modules need a staged plan.
- What do your providers and modules require? Check provider and registry compatibility for everything you depend on.
- Who will own the decision? Record it as an architecture decision record, with the conditions that would change it.
The worst outcome is drift by accident: half the estate on each tool because different teams chose differently. Pick one per organisation, write it down, and enforce it in CI.
If you migrate
- Pin versions of the tool and providers before starting.
- Start with a low-risk workspace and confirm that plans show no changes after switching.
- Back up state before any operation, and test restore.
- Adopt new features only after the whole estate is on one tool, so nothing depends on features the other lacks mid-migration.
- Update CI, policy checks and documentation in the same change, so new work doesn't keep targeting the old tool.
Commentators describe the technical migration as straightforward for many teams, with most effort going into organisation and tooling4. That matches the shape of the work: the commands are easy; the coordination is not.
How I can help
I review infrastructure-as-code estates as part of technical due diligence and platform work, and plan tool decisions and migrations that don't disrupt delivery. As a fractional CTO I can own that roadmap. Or analyse your challenge and bring the result to a call.
- 1OpenTofu vs Terraform in 2026: the fork finally divergedjorijn.com · 2026
- 2
- 3OpenTofu vs TerraformStackGuardian · 21 Aug 2026
- 4