For most of the last decade, the infrastructure as code decision was simple: you used Terraform. It was the default, the industry standard, the thing everyone already knew.

That changed in August 2023 when HashiCorp switched Terraform’s license from an open source one to the Business Source License. Overnight, teams that had built their entire infrastructure workflow around Terraform found themselves weighing whether the tool they depended on could change the rules on them again.

OpenTofu emerged from that moment as the community’s response — a fork of the last open source version of Terraform, governed by the Linux Foundation and developed by a coalition of companies and engineers who wanted the tool to stay truly open.

Two and a half years later, both tools are actively maintained, both are used in production by teams of all sizes, and they have diverged enough that this comparison is worth doing properly. Here is an honest look at where they stand today.

 Why This Comparison Matters More in 2026

When OpenTofu first launched, the realistic question was: can it actually replace Terraform? Is it stable enough, complete enough, supported enough to bet your infrastructure on?

By 2026, that question has been answered. OpenTofu is production-ready. It is used by enterprises including Boeing, Capital One, and AMD. It joined the Cloud Native Computing Foundation (CNCF), giving it governance weight and long-term institutional backing. And it has now shipped features that Terraform does not have.

At the same time, Terraform has continued development under HashiCorp, which was acquired by IBM for $6.4 billion in December 2024. HCP Terraform ended its free tier in March 2026. The commercial platform is where HashiCorp is investing, and the open source CLI, while still maintained, is not where the new features are appearing.

For teams making decisions about which tool to standardise on, this landscape is meaningfully different from two years ago. 

Licensing: BSL vs MPL — What It Actually Means

This is where the split started, and it still matters.

OpenTofu uses the Mozilla Public License 2.0. It is an OSI-approved open source license that has no commercial restrictions. You can use OpenTofu for anything — internal platforms, SaaS products, managed services, consulting work — without any legal ambiguity and without a commercial agreement.

Terraform, since version 1.6, uses the Business Source License 1.1. The BSL is not open source. It allows you to read and use the code, but it restricts commercial use in ways that can be interpreted broadly. In practice, most internal engineering teams are unaffected. But organisations that offer services built on top of Terraform, embed it in their own platforms, or have legal teams that take a conservative view of licensing risk will find the BSL more complicated to work with than the MPL.

The BSL also contains a four-year conversion clause: after four years, the code converts to a more permissive license. For teams making infrastructure decisions that will last five or ten years, that is too slow a timeline to rely on.

For most individual engineers and internal platform teams, the day-to-day reality is that neither license gets in the way of getting work done. But for organisations where licensing certainty matters — especially in regulated industries or where procurement teams are involved — OpenTofu’s MPL 2.0 is a straightforward choice and Terraform’s BSL introduces questions that need legal review.

Feature Comparison: Where the Two Tools Have Diverged

OpenTofu and Terraform started from the same codebase in 2023. Since then, both have continued developing, and the differences are no longer just about licensing. There are now features in OpenTofu that Terraform does not have, and vice versa.

State Compatibility: Can You Move Between Them?

One of the most common practical concerns when evaluating OpenTofu is whether switching would require migrating or recreating existing state. The short answer is no, at least in the direction most teams would go.

OpenTofu maintains full compatibility with Terraform’s state file format. State stored in S3, Azure Blob, GCS, or any other supported backend works with both tools. In most cases, switching from Terraform to OpenTofu means updating your CI/CD pipeline to call tofu instead of terraform, running tofu init, and continuing exactly as before.

The exceptions are worth knowing about. If you use Terraform Cloud as your remote state backend, you will need to move that state to a different backend before switching, since OpenTofu cannot authenticate to HCP Terraform. If you have been using OpenTofu-specific features like native state encryption and want to switch back to Terraform, you would need to decrypt the state first. Both of these are manageable, but they are not zero-effort.

For the vast majority of teams, state compatibility is a non-issue in the Terraform-to-OpenTofu direction. Moving the other way requires more planning.

Provider Ecosystem: Does Everything Still Work?

This is usually the first practical question teams ask, and the answer is reassuring. The provider ecosystem is largely shared between the two tools. Most providers are published under the MPL and work identically on both OpenTofu and Terraform. The AWS, Azure, Google Cloud, Kubernetes, Datadog, GitHub, and most other major providers are unaffected by which engine you use.

OpenTofu maintains its own registry at registry.opentofu.org, which mirrors the providers available on the Terraform Registry. For most teams, the day-to-day experience is identical: you run init, the provider gets downloaded, and it works.

Where you might notice differences is in very new provider features that rely on Terraform-specific functionality, or in providers that have explicitly chosen to only publish to one registry. These cases are rare in practice, but worth checking if you rely on niche or custom providers.

If your team builds or maintains internal providers, both tools use the same provider protocol, and a single binary typically serves both engines.

OpenTofu vs Terraform for Platform Engineering

For platform engineering teams, the licensing and governance questions matter more than they do for individual contributors. Platform teams are often responsible for the tools their entire organisation uses, which means licensing decisions have a wider blast radius, and governance questions — like whether a vendor can change the rules unilaterally — have real consequences.

Several themes come up consistently when platform teams evaluate the two tools:

•        Vendor lock-in risk. Terraform’s future direction is now controlled by IBM, following the December 2024 acquisition. Some platform teams are comfortable with that. Others prefer the multi-vendor governance model that the Linux Foundation provides for OpenTofu.

•        Security and compliance. Native state encryption in OpenTofu is a meaningful advantage for teams in regulated industries. State files have historically been a source of plaintext secrets, and building encryption into the tool itself is cleaner than relying on backend-level controls.

•        Open policy enforcement. Both tools work well with Open Policy Agent. Terraform’s Sentinel policy engine is only available on HCP Terraform. Teams that want policy-as-code on the open source CLI will find OpenTofu the more natural fit when combined with OPA.

•        TACOS platform support. All the major Terraform automation, collaboration, operations, and security (TACOS) platforms — env zero, Spacelift, Scalr, and Harness — support both tools. The choice of engine does not determine which managed platform you can use.

Migration Path: Terraform to OpenTofu

If you are running Terraform today and want to evaluate OpenTofu, the migration process for most teams is genuinely straightforward. The reason is that OpenTofu was designed from the start to be a drop-in replacement — not a rewrite.

The Basic Steps

1.     Install OpenTofu alongside your existing Terraform setup

2.     Run tofu init in your existing configuration directory

3.     Run tofu plan and compare the output to a terraform plan

4.     Update your CI/CD pipelines to call tofu instead of terraform

5.     Update any Terraform-specific provider registry references if needed

For most configurations, that is the entire migration. Teams that have successfully migrated report that the overwhelming majority of modules and configurations work without any changes.

The cases that require more work are:

•        Terraform Cloud remote state. If you use HCP Terraform as your remote backend, you will need to migrate state to S3, Azure Blob, GCS, or another backend before switching engines.

•        Sentinel policies. Terraform’s Sentinel policy engine is commercial and proprietary. If you use it on HCP Terraform, you will need to rewrite those policies in OPA or Kyverno before moving to an open source workflow.

•        Terraform-specific functions or blocks. If your configurations use features introduced in Terraform 1.6 or later that OpenTofu has not implemented, you may need to refactor those sections. These cases are uncommon but worth auditing before a migration.

Which Should You Choose?

The honest answer is that both tools are solid choices in 2026. The decision depends less on technical capability — they are genuinely similar at the workflow level — and more on your team’s priorities, existing investments, and how much weight you give to governance and licensing questions.

Managing OpenTofu and Terraform Together with env zero

One of the practical realities for larger organisations is that you often cannot make a clean, organisation-wide switch from one tool to another overnight. Teams operate at different levels of maturity, different squads have different migration timelines, and some infrastructure is simply too stable to touch.

env zero supports both OpenTofu and Terraform from the same platform, without any separation between them. You can run OpenTofu environments alongside Terraform environments in the same project. Both go through the same plan-and-apply workflow, the same approval gates, the same cost estimation, and the same drift detection. Your HCL stays exactly as it is.

For organisations that are mid-migration, or that want to adopt OpenTofu for new projects while leaving existing Terraform infrastructure where it is, this makes the transition easier to manage without a hard cutover date.

Summary

OpenTofu and Terraform are more similar than they are different in 2026. The same HCL configuration language, the same provider ecosystem, the same core workflow. For most day-to-day infrastructure work, the choice between them is nearly invisible.

Where the distinction becomes meaningful is in licensing, governance, and a small but growing set of features where OpenTofu has moved ahead: native state encryption, ephemeral values, provider iteration, and dynamic lifecycle controls.

For teams starting new projects, OpenTofu is the straightforward default. For teams with existing Terraform infrastructure, migration is low-risk and worth planning when the time is right. For teams that need both, the good news is that every major managed platform supports both engines, and you do not need to choose just one.

‍