Three years ago the question was whether OpenTofu would survive. That question has been answered. OpenTofu joined the CNCF as a sandbox project in April 2025, Fidelity Investments migrated 50,000+ state files to it, and GitLab deprecated its Terraform CI/CD templates in May 2025 over licensing concerns. The better question in 2026: not whether to consider OpenTofu, but when the governance and licensing difference actually matters for your team.
For most EU-based organizations, it matters more than the feature comparison.
TL;DR
- OpenTofu (MPL-2.0, Linux Foundation/CNCF) and Terraform (BSL, IBM/HashiCorp) have diverged technically and governmentally since the August 2023 fork.
- The governance difference is the bigger decision factor. BSL restricts competitive use and is not OSI-approved; MPL-2.0 carries no such restrictions. EU procurement strategies increasingly favor OSI-approved licenses.
- OpenTofu leads on security features: native state encryption, ephemeral values, OCI registry support. Terraform leads on enterprise platform integration: Stacks, Sentinel, HCP Terraform, Project Infragraph.
- Migration is straightforward technically (Fidelity proved this at scale with 50,000+ state files). The organizational change management is the real work.
- If you run an IBM-aligned stack (Red Hat, watsonx, Ansible), Terraform's roadmap converges with yours. If you don't, OpenTofu gives you equivalent HCL with stronger sovereignty guarantees.
Table of contents
- A three-year timeline in 60 seconds
- The governance gap: BSL, IBM, and what it means for EU teams
- Where the code diverged
- Adoption signals: who moved, who stayed
- Migration in practice
- When Terraform still makes sense
- Key takeaways
A three-year timeline in 60 seconds
August 2023: HashiCorp switched Terraform's license from MPL-2.0 to the Business Source License (BSL). Five days later the OpenTF manifesto appeared on GitHub, signed by over 120 companies. By September the Linux Foundation had adopted the project as OpenTofu. OpenTofu 1.6 shipped as the first stable release in January 2024, maintaining full backward compatibility with Terraform 1.5.x.
April 2024 brought HashiCorp's cease-and-desist letter over alleged code copying in OpenTofu's removed block implementation. OpenTofu responded publicly that the code predated the BSL relicensing. No further legal action followed.
That same month, IBM announced its $6.4 billion acquisition of HashiCorp, closing in February 2025. By April 2025, OpenTofu had entered the CNCF at sandbox level, with a special exception to keep its MPL-2.0 license rather than the CNCF-standard Apache 2.0.
As of April 2026: OpenTofu is at version 1.11.6 with 1.12.0-beta1 available. Terraform is at 1.14.8. Both are actively developed. But they are no longer the same tool.
The governance gap: BSL, IBM, and what it means for EU teams
This is the core of the comparison. Features come and go; governance structures determine whether you can rely on a tool five years from now.
What BSL actually restricts
Terraform's Business Source License prohibits building "a competitive offering" using the software. The definition: a product sold to third parties that "significantly overlaps" HashiCorp's commercial products. Internal use is permitted. Running terraform in your own CI/CD pipelines is permitted. But the vagueness of "significantly overlaps" created real legal exposure for platform vendors.
GitLab's legal team concluded they were exposed. That assessment led directly to the deprecation of Terraform CI/CD templates in GitLab 18.0 (May 2025) and a platform-level migration to OpenTofu. For organizations running GitLab, the toolchain itself made the choice.
IBM changed the owner, not the license
IBM completed the HashiCorp acquisition in February 2025. The license did not change. IBM's strategic direction is the opposite of a return to open source: Project Infragraph, previewed at HashiConf in September 2025, ties Terraform into IBM watsonx, Red Hat Ansible, OpenShift, and IBM's mainframe portfolio. The trajectory is toward a more tightly integrated, more commercial product.
That is not necessarily bad. If your infrastructure runs on IBM and Red Hat, the integration depth is genuinely valuable. But it means Terraform's roadmap is set by IBM's commercial priorities, not by community consensus. Ned Bellavance's analysis post-acquisition notes increased development velocity on Terraform, which confirms IBM is investing. The investment just flows through a corporate lens.
The EU angle: where governance becomes procurement policy
OpenTofu's MPL-2.0 is OSI-approved. Terraform's BSL is not. That distinction is increasingly operational in European procurement.
The European Commission's open source strategy positions open-source software as a pillar of digital sovereignty. The EuroStack position paper on EU procurement (March 2025) recommends open source as the default procurement choice, with proprietary software requiring documented justification. A BSL-licensed tool would need that justification. OpenTofu would not.
The Cyber Resilience Act (CRA), taking full effect in December 2027, creates another asymmetry. OpenTofu qualifies as an "open-source software steward" under the CRA: lighter obligations, no administrative fines. Terraform, as a commercial IBM product, faces full CRA manufacturer requirements including conformity assessments and 24-hour vulnerability disclosure to ENISA.
For organizations subject to NIS2, the governance model also feeds into supply-chain risk assessments. A tool under single-vendor corporate control is a documented third-party dependency. A tool under multi-vendor, foundation-governed stewardship distributes that risk. Germany's Sovereign Cloud Compass already evaluates cloud providers on IaC tooling support and treats Terraform and OpenTofu as functionally equivalent, which tells you something about where the European IaC conversation is heading.
None of this means BSL-licensed software is banned in Europe. It means the compliance and procurement overhead is higher. For teams that need to justify tooling choices to a legal or procurement department, OpenTofu removes an entire category of questions.
Where the code diverged
Both tools started from the Terraform 1.5.x codebase. Three years later, the core HCL syntax is still largely compatible, but the feature sets have split in telling directions.
OpenTofu's lead: security and developer ergonomics
Native state encryption (since 1.7) encrypts state files client-side before they reach any backend. AWS KMS, GCP KMS, and PBKDF2 key providers are supported. Terraform has no equivalent; it relies entirely on backend-level encryption.
Ephemeral values (since 1.11) exist only in memory during a single run. Never written to state or plan files. For time-limited credentials like STS tokens or temporary SSH tunnels, this eliminates a class of secret-exposure risks that state-file encryption alone cannot address.
Early variable evaluation (since 1.8) allows variables in backend configuration blocks. No more -backend-config workarounds for multi-environment setups.
OCI registry support (since 1.10) distributes providers and modules through any OCI-compatible container registry. This matters for air-gapped or sovereignty-conscious environments where public registry access is restricted.
S3 state locking without DynamoDB (since 1.10) uses native S3 conditional writes. One fewer AWS resource to manage and pay for.
Terraform's lead: enterprise platform integration
Terraform Stacks (GA since September 2025) orchestrate multiple infrastructure components as a single lifecycle unit. Available only through HCP Terraform, not the CLI. If you manage complex multi-component deployments through Terraform Cloud, Stacks solve a real coordination problem.
Sentinel provides policy-as-code for HCP Terraform and Terraform Enterprise. No OpenTofu equivalent exists; teams that need equivalent policy enforcement must use OPA, Checkov, or similar tools.
Project Infragraph (private beta since December 2025) connects Terraform state to IBM watsonx, Ansible, OpenShift, and IBM's observability stack. For IBM-ecosystem shops, this is a genuine differentiator.
The compatibility picture
Providers work with both tools. The OpenTofu registry lists 3,900+ providers, all independently licensed (typically MPL-2.0 or Apache 2.0). State files are binary-compatible between Terraform 1.5.x and OpenTofu in both directions, with one exception: enabling OpenTofu's state encryption makes those files unreadable to Terraform. That makes encryption a committed, one-way choice.
HCL syntax remains compatible for most configurations, but divergence is growing. OpenTofu-only syntax (variables in backend blocks) fails on Terraform. Terraform-only syntax (.tfstack.hcl files) fails on OpenTofu. For now the overlap is large. It will shrink.
Adoption signals: who moved, who stayed
Fidelity Investments migrated 50,000+ state files across 2,000+ applications managing 4 million+ cloud resources, reaching 70% adoption in two quarters. David Jackson, VP of Automation Tooling at Fidelity, framed it precisely: "The code itself isn't the hard part. Changing the CLI in a pipeline is trivial. The complexity lives in the surrounding ecosystem."
GitLab made the call at the platform level. The deprecation of Terraform CI/CD templates and migration to OpenTofu was driven by legal risk assessment, not feature preference. For the many European organizations running GitLab, the CI/CD platform they depend on has already moved.
Spacelift reports 50% of deployments on their platform now use OpenTofu. Spacelift is a founding OpenTofu TSC member, so treat this as directionally accurate rather than independently audited. The direction is clear, though.
On OpenTofu's side: ~28,000 GitHub stars, 160+ contributors, and CNCF institutional backing. On Terraform's side: a larger install base, active IBM investment, and enterprise customers deeply integrated with HCP Terraform who are not migrating.
The pattern emerging across the industry: Terraform for legacy environments with established Terraform Cloud workflows. OpenTofu for greenfield work where governance flexibility matters.
Migration in practice
The technical migration is well-documented and consists of four steps: install the OpenTofu CLI, run tofu init in your existing working directory (it reads the existing state without modification), verify with tofu plan, update CI/CD pipelines.
Hard blockers to know about:
- Terraform Cloud workspaces. OpenTofu cannot connect to HCP. Migrate state to S3, GCS, or Azure Blob first.
- Sentinel policies. No OpenTofu equivalent. Rewrite in OPA or Checkov.
- One-way features. Enabling OpenTofu state encryption or early variable evaluation creates configurations that Terraform cannot parse. Once you use them, switching back means unwinding those features.
Fidelity's migration confirmed what the documentation promises: the terraform to tofu CLI swap is trivial. The real effort is organizational: updating module catalogs, retraining teams, aligning CI/CD governance, and communicating the change to stakeholders. Budget time for that, not for the technical cut-over.
When Terraform still makes sense
This is not a "Terraform is dead" article. There are specific contexts where Terraform remains the better choice:
- Deep IBM ecosystem integration. If you run Red Hat OpenShift, use IBM watsonx for AI workloads, and manage hybrid cloud infrastructure through IBM's portfolio, Terraform's roadmap is converging with your stack. Project Infragraph aims to make that integration seamless. OpenTofu offers nothing comparable.
- Mature HCP Terraform investment. If your organization has remote state, Sentinel policies, and collaborative workflows running through Terraform Cloud, the migration cost is real. Evaluate whether the governance benefits outweigh your specific switching costs.
- Terraform Stacks for multi-component orchestration. If Stacks solves a coordination problem you currently work around manually, that value is concrete and only available on HCP Terraform.
The honest assessment: for teams outside the IBM ecosystem who are not locked into HCP Terraform, the governance and feature advantages tilt toward OpenTofu. The license is unambiguous. The governance is transparent. The security features are ahead. The EU regulatory posture is simpler.
But "tilt toward" is not "must switch tomorrow." If your Terraform setup works and you face no procurement or compliance pressure, the urgency is low. Prioritize OpenTofu for new projects. Evaluate migration for existing ones on your own timeline.
Key takeaways
- The fork is no longer an experiment. CNCF backing, Fidelity's 50,000+ state-file migration, and GitLab's platform switch confirm OpenTofu as production-grade IaC.
- Governance is the primary decision factor for EU teams. BSL vs. MPL-2.0 determines your procurement overhead, compliance posture under CRA and NIS2, and long-term vendor independence. The technical feature gap is real but secondary.
- OpenTofu leads on security and developer ergonomics: state encryption, ephemeral values, early variable evaluation, OCI registry support. Terraform leads on enterprise platform integration: Stacks, Sentinel, Project Infragraph.
- Migration is technically straightforward; Fidelity proved this at enterprise scale. The organizational work (module catalogs, team alignment, CI/CD governance) is where the effort lives.
- For IBM-aligned stacks, Terraform's roadmap adds genuine value. For everyone else, OpenTofu delivers the same HCL with stronger sovereignty and governance guarantees.