Infrastructure as code is the backbone of modern cloud operations. It is how platform teams provision networks, clusters, databases and identity consistently across environments, how security teams enforce guardrails, and how disaster recovery environments are rebuilt on demand. For most organizations, that backbone has been built with Terraform.
Since 2023, however, the ground has shifted. HashiCorp changed Terraform’s license, the community created the OpenTofu fork, IBM completed its acquisition of HashiCorp, and the two tools have begun to diverge in features and direction. In 2026, choosing between them is no longer a philosophical debate; it is a platform decision with implications for cost, risk, tooling and skills. This guide lays out what has changed, how the tools compare today and how to decide, and migrate if you choose to, without disrupting delivery.
How We Got Here: A Short Timeline
- August 2023: HashiCorp moved Terraform from the open-source Mozilla Public License (MPL 2.0) to the Business Source License (BSL), which restricts use in products that compete with HashiCorp.
- Late 2023 to January 2024: A community fork, initially called OpenTF and later OpenTofu, was placed under the Linux Foundation, and OpenTofu 1.6 shipped as its first stable release, compatible with Terraform 1.5 configurations.
- 2024: OpenTofu added features not available in Terraform’s open-source CLI, including native client-side state encryption in version 1.7 and early variable evaluation in 1.8.
- January 2025: OpenTofu 1.9 introduced
for_eachon provider blocks and an-excludeflag for targeted plans. - February 2025: IBM completed its roughly $6.4 billion acquisition of HashiCorp.
- April 2025: OpenTofu was accepted into the Cloud Native Computing Foundation (CNCF) sandbox.
- Mid-2025 to 2026: OpenTofu 1.10 added OCI registry support and native S3 state locking; subsequent releases through 1.13, published in September 2026, continued the cadence. Terraform, meanwhile, has invested in HCP Terraform features such as Stacks and new CLI capabilities such as
terraform query.
Licensing and Governance: What Actually Matters
For most enterprises that simply use Terraform to manage their own infrastructure, the BSL does not prohibit day-to-day use. The restriction targets organizations offering competing products, such as hosted infrastructure-as-code platforms. So why has the license change mattered so much?
The real issue is governance and long-term control. Terraform’s roadmap, licensing terms and commercial strategy are now set by a single vendor, IBM, whose priorities include its HCP Terraform and broader automation portfolio. OpenTofu is governed under the Linux Foundation and CNCF with contributions from multiple companies, and remains under MPL 2.0. Organizations that weigh vendor neutrality, licensing predictability and the ability to embed IaC in their own products tend to favor OpenTofu; organizations that value a single accountable vendor with enterprise support and a managed platform tend to favor Terraform.
For most teams, the OpenTofu versus Terraform decision is less about features and more about who you want to control the roadmap and pricing of the tool that defines your entire cloud estate.
Feature Comparison in 2026
The tools still share most of their language, provider protocol and module ecosystem, and the majority of configurations run on either with little or no change. The differences are at the edges, but some of those edges matter.
Where OpenTofu Has Moved Ahead
- State encryption. OpenTofu can encrypt state and plan files on the client side, and, as InfoQ reported for version 1.10, integrate with external key providers such as AWS KMS and HashiCorp Vault. For teams storing sensitive values in state, this is a significant security improvement over relying solely on backend encryption.
- OCI registry distribution. Version 1.10 allows providers and modules to be distributed through OCI-compatible container registries. This is valuable for air-gapped and regulated environments that already operate an internal container registry.
- Native S3 locking. State locking on Amazon S3 without a separate DynamoDB table simplifies backend setup.
- Language conveniences. Provider
for_each, early variable evaluation in module sources and backends, the-excludeflag and deprecation markers for module variables and outputs reduce boilerplate in multi-region and multi-account designs.
Where Terraform Has Moved Ahead
- Managed platform features. HCP Terraform offers Stacks for orchestrating deployments across many environments, along with policy, run management and private registry features that some enterprises prefer to buy rather than build.
- Discovery and import. According to StackGuardian’s 2026 comparison, Terraform 1.14 added
terraform queryand list blocks for native resource discovery, which OpenTofu did not yet match at the time of writing. - Vendor support and ecosystem integrations. Large enterprises with existing HashiCorp agreements benefit from a single support relationship and tight integration with other HashiCorp and IBM products.
Compatibility Considerations
Divergence is gradual but real. Features introduced in one tool, such as OpenTofu’s encryption configuration or Terraform’s newer blocks, are not understood by the other. The longer an organization uses tool-specific features, the more effort a later switch requires. That is not a reason to avoid new features, but it is a reason to make the strategic decision deliberately rather than drifting into one tool by accident.
Cost and Platform Implications
Both CLIs are free to use for managing your own infrastructure, so the cost question is really about the platform around them: remote state, run orchestration, policy enforcement, drift detection, access control and audit. You have three broad options.
- HCP Terraform or Terraform Enterprise. A managed or self-hosted platform from IBM/HashiCorp. StackGuardian reports that HCP Terraform’s legacy free tier ended in March 2026, so teams should model usage-based pricing carefully as their resource counts grow.
- Third-party IaC platforms. Several vendors offer orchestration for both Terraform and OpenTofu, often with policy-as-code, cost estimation and self-service features.
- Self-built pipelines. Many teams run plans and applies through existing CI/CD systems, with state in cloud object storage and policy enforced by open-source tools. This is the most flexible and lowest license cost option, but requires engineering effort to operate securely.
Whatever you choose, make the total cost explicit: licensing, platform operations, engineering time and the cost of switching later.
Decision Criteria: Which Tool Fits Your Organization?
Use the following questions as a structured decision framework. No single answer is decisive; look at the overall pattern.
- Do you build products or services that embed or offer IaC capabilities to others? If yes, OpenTofu’s MPL license removes a significant legal question.
- How important is vendor neutrality? If you have a policy of preferring foundation-governed open-source infrastructure tooling, OpenTofu aligns better.
- Are you heavily invested in HCP Terraform or Terraform Enterprise? If your workflows depend on Stacks, Sentinel policies or other platform features, staying with Terraform is usually the lower-risk path.
- Do you have strict security or air-gapped requirements? Client-side state encryption and OCI-based distribution make OpenTofu attractive in regulated environments.
- What does your tooling ecosystem support? Check that your CI/CD platform, policy engine, security scanners and internal developer portal support your chosen tool.
- What are your team’s skills and appetite for change? The language is shared, but a switch still requires pipeline changes, testing and communication.
A pragmatic pattern we often see is to standardize new platform work on one tool while allowing legacy stacks to remain on the other until a natural refactoring point, with a clear end date for the mixed state.
Migration Playbook: Moving from Terraform to OpenTofu
If the decision favors OpenTofu, migration is usually straightforward for configurations compatible with the Terraform versions OpenTofu tracks. Organizations including Fidelity Investments have publicly shared their migration experience on the OpenTofu blog. A disciplined approach looks like this:
Phase 1: Inventory and Assess
- List all root modules, their Terraform versions, providers, backends and the pipelines that run them.
- Identify use of Terraform-specific features introduced after the fork and any dependency on HCP Terraform workspaces, Stacks or Sentinel policies.
- Classify stacks by risk: start with low-risk, non-production infrastructure.
Phase 2: Pilot
- Install OpenTofu alongside Terraform in CI and run
tofu initandtofu planagainst pilot stacks, confirming that plans show no unexpected changes. - Back up state files before the first apply, and verify provider downloads from the OpenTofu registry or your internal mirror.
- Update pre-commit hooks, linters and security scanners to recognize OpenTofu.
Phase 3: Roll Out
- Migrate stacks in waves, prioritizing those owned by teams ready to adopt new practices.
- Replace HCP Terraform workspaces with your chosen orchestration platform or pipelines, re-implementing policies in an open policy engine where needed.
- Adopt OpenTofu-specific features, such as state encryption, only after the migration of a stack is complete and stable.
Phase 4: Govern
- Pin OpenTofu and provider versions, and define an upgrade cadence aligned with OpenTofu’s release schedule.
- Document standards for modules, state backends, encryption keys and code review.
- Retire Terraform binaries from pipelines once all stacks have moved, to prevent accidental mixed usage.
If You Stay on Terraform: Reducing Lock-In Risk
Choosing Terraform is a perfectly reasonable decision, particularly for organizations already invested in HCP Terraform or Terraform Enterprise. The goal then is not to avoid Terraform, but to keep your options open and your costs predictable. Several practices help.
First, keep modules portable. Favor language features that both tools support for shared modules, and isolate tool-specific constructs in root modules where they are easier to change later. Second, own your state: even when using a managed platform, make sure you can export state and run plans from your own pipelines in an emergency. Third, express policies in a form that is not tied to a single platform where possible, so that a future change of orchestration layer does not mean rewriting every guardrail. Fourth, track your managed platform consumption, such as the number of managed resources, against pricing tiers each quarter, so that cost increases do not arrive as a surprise at renewal.
Finally, revisit the decision on a fixed cadence, for example annually or at each contract renewal. The relative strengths of the two tools are still changing, and a choice that was right in 2026 should be confirmed with fresh evidence rather than assumed to hold indefinitely.
Worked Example: A Multi-Account AWS Landing Zone
Consider a company with around forty AWS accounts managed by Terraform in a central repository, with plans run through HCP Terraform workspaces. Its security team wants state encryption under keys it controls, and its platform team is concerned about rising platform costs and wants a vendor-neutral foundation for an internal developer platform.
The team inventories its root modules and finds that almost all use Terraform 1.5-era features, with a handful using newer syntax. It pilots OpenTofu on sandbox and logging accounts, running plans in parallel with Terraform in its existing CI system. Plans match, apart from a provider version difference that is resolved by pinning. Over two months it migrates the remaining accounts in waves, moving state to an encrypted S3 backend with native locking and enabling OpenTofu state encryption with keys in AWS KMS.
Policies previously written in Sentinel are re-implemented with an open-source policy engine in the pipeline. Provider for_each lets the team replace dozens of near-identical provider blocks for regions and accounts with a single loop, making the landing zone code significantly easier to read and review. The resulting setup costs less to operate, encrypts sensitive state end to end and gives the platform team a foundation it fully controls.
Common Pitfalls
- Treating the choice as purely technical. Legal, procurement and security stakeholders should be part of the decision.
- Mixing tools indefinitely. Running both without a plan leads to confusion over which binary manages which state and increases the risk of incompatible changes.
- Skipping state backups. Always back up state before the first apply with a different tool.
- Forgetting the ecosystem. Scanners, IDE plugins, cost estimation tools and documentation all need updating.
- Underestimating platform replacement. Moving off HCP Terraform involves replacing run orchestration, policy and access control, not just the CLI.
Outlook: Where Infrastructure as Code Is Heading
The OpenTofu project has continued shipping regularly, with releases through version 1.13 and published plans for capabilities such as built-in linting, while Terraform development under IBM is increasingly tied to its managed platform. Beyond the fork, infrastructure as code itself is evolving: AI assistants now generate and review configurations, policy-as-code is becoming mandatory in regulated industries, and internal developer platforms increasingly expose infrastructure through templates rather than raw modules. Whichever tool you choose, invest in well-tested modules, strong review practices and clear ownership, because those will outlast any single tool decision.
Conclusion
In 2026, both Terraform and OpenTofu are capable, actively developed tools that share a common language and ecosystem. Terraform offers a single accountable vendor and a rich managed platform; OpenTofu offers open governance, a permissive license and security features such as client-side state encryption and OCI distribution. Make the choice deliberately, based on governance preferences, platform dependencies, security needs and total cost, and if you migrate, do it in measured phases with parallel plans and backed-up state. The goal is not to pick a winner in the abstract, but to give your cloud infrastructure a foundation you can rely on for the next decade.
How Hanoi Technology Can Help
Hanoi Technology helps platform teams assess, standardize and migrate infrastructure-as-code estates on Terraform or OpenTofu across AWS, Azure and Google Cloud.