OpenTofu vs Terraform in 2026: The Fork Has Matured

The short answer

Choose OpenTofu when you need an OSI-approved open-source core, engine-level state encryption, or neutral governance for a new platform. Choose Terraform when you are invested in HCP Terraform or Terraform Enterprise, or depend on HashiCorp support and Terraform-specific features. An existing Terraform estate with no licensing concerns usually stays where it is, and many teams run both engines during a staged migration — the HCL language and module format remain compatible.

New to infrastructure as code? Start with the fork story to understand why two competing tools now share the same language. If you already know the history, skip to the feature comparison or dual-engine strategy.

Terraform and OpenTofu still share a common foundation, but they are no longer merely two names for the same tool. They now differ in licensing, governance, state protection, language features, and commercial ecosystem.

As of this update, OpenTofu 1.12.0 is the most recently documented release, while HashiCorp distributes Terraform 1.15.6. (OpenTofu)

The practical answer

Choose Terraform when HCP Terraform, Terraform Enterprise, HashiCorp support, or Terraform-specific functionality is already central to your operating model.

Choose OpenTofu when an OSI-compatible open-source license, foundation stewardship, or its OpenTofu-specific features are important requirements.

Avoid running both indefinitely without a clear reason. During a migration, supporting both can reduce risk. As a permanent arrangement, it creates an additional burden of compatibility and support.

Why are there two tools?

HashiCorp changed Terraform’s license from MPL 2.0 to Business Source License 1.1 in August 2023. The new license permits many ordinary uses but restricts certain uses involving competitive commercial offerings. HashiCorp maintains a detailed FAQ defining its interpretation of those restrictions. (HashiCorp | An IBM Company)

In response, OpenTF—later renamed OpenTofu—was created from the MPL-licensed Terraform codebase. The Linux Foundation announced OpenTofu as a foundation-hosted project on 20 September 2023. OpenTofu continues under MPL 2.0. (Linux Foundation)

This creates the central difference:

• Terraform is source-available under the BSL and developed commercially by HashiCorp, now part of IBM.
• OpenTofu is open source under MPL 2.0 and developed under a foundation-based governance model.

IBM completed its acquisition of HashiCorp on 27 February 2025. (IBM Newsroom)

How mature is OpenTofu?

OpenTofu is no longer an experimental fork in the ordinary sense. It has regular releases, a public registry, and documented production use. Its official site currently reports more than 3,900 providers and 23,600 modules. (OpenTofu)

One publicly described migration comes from Fidelity Investments. In an OpenTofu-hosted interview, Fidelity reported an estate spanning more than 2,000 applications, 50,000 state files, and 4 million cloud resources across Terraform and OpenTofu. Fidelity described using a proof of concept, production testing, centralized pipelines, and staged organizational adoption. (OpenTofu)

OpenTofu was accepted into CNCF on 23 April 2025 at the Sandbox level. This provides access to CNCF infrastructure and establishes legal and governance requirements, but Sandbox status should not be confused with CNCF Incubating or Graduated status. CNCF characterizes Sandbox projects as early-stage and potentially still evolving. (CNCF)

Important technical differences

Here is the side-by-side view. Each dimension is expanded in the sections below.

Licensing and governance

OpenTofu uses MPL 2.0, an OSI-approved open-source license. Terraform releases after the license change use BSL 1.1. For many internal users, the BSL does not prevent ordinary use of Terraform. Still, software vendors, hosted service providers, and organizations embedding Terraform into commercial products should review the exact license terms. (HashiCorp | An IBM Company)

Licensing may therefore be decisive even when the technical differences are small.

State and plan encryption

Both tools require careful state protection because the state can contain identifiers, credentials, and other sensitive values.

OpenTofu provides client-side encryption for state and plan files. Encryption can be configured with passphrases or external key management systems, allowing data to be encrypted before it is written to local or remote storage.

Terraform does not provide the same general client-side whole-state encryption mechanism in the standard CLI. Instead, encryption normally depends on the backend. HCP Terraform encrypts state at rest, while cloud backends such as S3 and GCS can also provide encryption. Terraform additionally supports ephemeral values and provider write-only arguments for supported resources, reducing the amount of secret material written to state.

OpenTofu’s approach is especially useful when an organization wants consistent encryption independent of the storage backend. It also introduces key management responsibilities: losing the encryption key can render the state unusable.

Dynamic provider configurations

OpenTofu introduced for_each for provider configurations, which can reduce repeated provider blocks in multi-account and multi-region configurations.

Traditional Terraform configurations still require explicit provider configurations for many comparable designs. Terraform Stacks, however, supports dynamic provider configurations using for_each, so the difference depends partly on whether the organization uses the conventional Terraform workflow or Terraform Stacks.

Registry and provider compatibility

OpenTofu has its own public registry. Many existing providers work with both engines because Terraform and OpenTofu support compatible provider protocols. OpenTofu also supports provider registries, filesystem mirrors, network mirrors, and OCI registry distribution.

Compatibility at the protocol level does not guarantee that every provider, publisher, test, or support every release of both engines. Production teams should test the exact provider versions they use and should commit their dependency lock file.

Hosted collaboration and commercial support

Terraform’s strongest differentiator is not merely its CLI. HCP Terraform provides remote execution, managed state, access controls, a private registry, policy workflows, and integrations with common version-control systems. Terraform Enterprise provides similar capabilities for organizations requiring a self-managed commercial platform.

OpenTofu itself is primarily the IaC engine. Teams generally combine it with their own CI/CD system or a compatible automation and collaboration platform. This can provide greater choice but requires a separate platform decision.

Are Terraform and OpenTofu interchangeable?

They remain highly compatible, especially for configurations originating from Terraform versions near the original fork. The HCL syntax, module conventions, and provider protocol continue to overlap substantially.

They are not guaranteed to remain interchangeable forever. Each project now adds independent features. A configuration that uses an OpenTofu-only feature will not necessarily run under Terraform, and vice versa. State-format downgrades are not guaranteed.

For shared modules, test explicitly against every supported engine and version. Do not rely solely on the fact that the files end in. .tf.

Which tool should you choose?

The decision should be made for the complete operating model—not just the CLI. Include state storage, policy enforcement, identity, CI/CD, module distribution, support, auditing, ng and disaster recovery.

A safer Terraform-to-OpenTofu migration procedure

1. Inventory the current estate

Record:

• Terraform CLI versions;
• provider and module versions;
• backend types;
• HCP Terraform or Terraform Enterprise dependencies;
• wrapper tools and CI actions;
• policy checks;
• external state consumers;
• scripts that parse Terraform output;
• configurations connected through terraform_remote_state.

Check required_version constraints and identify any Terraform-specific features before attempting a migration.

2. Freeze infrastructure changes

Choose a migration window to prevent Terraform and OpenTofu from concurrently writing to the same state. A backend lock protects individual operations, but it does not establish which engine is authorized to own the state.

3. Back up code and state

Commit the current configuration, modules, and lock file to version control.

For a state that can be accessed through the CLI, create a point-in-time copy:

mkdir -p migration-backup

terraform version > migration-backup/terraform-version.txt
terraform providers > migration-backup/providers.txt
terraform state pull > migration-backup/terraform.tfstate
cp .terraform.lock.hcl migration-backup/terraform.lock.hcl

Also use the backend’s native recovery mechanism, such as S3 versioning, object snapshots, or HCP Terraform state history. OpenTofu’s official migration guidance recommends backing up both state and configuration before proceeding.

4. Test in a clean working copy

Do not begin by replacing the production binary. Use a fresh clone or separate working directory so that cached plugins and .terraform metadata do not obscure differences.

Install and pin an approved OpenTofu version:

tofu version
tofu init
tofu validate

tofu version
tofu init
tofu validate

Review any changes to .terraform.lock.hcl. OpenTofu 1.12 may add provider checksums during initialization; these additions should be reviewed and deliberate. committed

5. Compare plans

Create plans with both engines against the same unchanged configuration and state, but do not run the commands concurrently:

terraform plan -out=terraform.plan
terraform show -json terraform.plan > terraform-plan.json

tofu plan -out=opentofu.plan
tofu show -json opentofu.plan > opentofu-plan.json

terraform plan -out=terraform.plan
terraform show -json terraform.plan > terraform-plan.json

tofu plan -out=opentofu.plan
tofu show -json opentofu.plan > opentofu-plan.json

Compare the proposed resource actions, replacements, provider selections, and output changes. Raw JSON may contain harmless formatting or metadata differences, so concentrate on operational consequences.

Do not apply an OpenTofu plan that contains unexplained changes.

6. Test the complete delivery path

A successful local plan is insufficient. Test:

• pull-request validation;
• remote execution;
• credentials and workload identity;
• policy-as-code checks;
• cost estimation;
• plan parsers and approval bots;
• state locking;
• private provider and module access;
• drift detection;
• audit logging;
• disaster recovery.

A GitHub setup action may be easy to replace, but HCP Terraform remote execution is not replaced merely by renaming terraform to tofu.

7. Apply a low-risk change

Choose a non-critical workspace or a small reversible change, such as a harmless tag update:

tofu plan -out=migration-test.plan
tofu apply migration-test.plan

tofu plan -out=migration-test.plan
tofu apply migration-test.plan

After the application, run another plan and confirm that it reports no unexplained drift.

8. Roll out progressively

Migrate by application group or state boundary. Track failures, provider incompatibilities, and required module changes. Keep the ability to pause the rollout.

Once a state has been migrated, ensure that old Terraform pipelines can no longer write to it.

9. Delay OpenTofu-only features

Initially run OpenTofu in a compatibility-focused mode. Do not immediately introduce state encryption, provider iteration, or other OpenTofu-specific syntax.

Keeping the first migration technically conservative makes rollback and diagnosis easier. Adopt new features only after the base migration is stable.

10. Define rollback before migration

A rollback should specify:

1. the condition that triggers rollback;
2. Who can authorize it;
3. which state backup will be restored;
4. how concurrent writes will be prevented;
5. which Terraform version will be used;
6. How the restored state will be verified.

OpenTofu’s documentation advises stopping OpenTofu operations, restoring state when necessary, reinitializing Terraform, and confirming that Terraform produces no unexpected changes.

Conclusion

Terraform and OpenTofu are both credible infrastructure-as-code engines in 2026, but they optimize for different priorities.

Terraform offers a tightly integrated commercial platform, first-party support, and continued development under HashiCorp and IBM. OpenTofu offers an MPL-licensed core, foundation stewardship, and differentiated features, including client-side state encryption.

The best default is usually one engine per platform, selected based on licensing, workflow, support, and security requirements. Running both is useful during migration or where there is a deliberate architectural boundary—not as an automatic compromise.

Have you migrated from Terraform to OpenTofu? I would love to hear about your experience — what worked, what didn’t, and whether you are running both. Drop a comment below or find me on LinkedIn.

Frequently asked questions

Is OpenTofu a drop-in replacement for Terraform?

Mostly, for configurations originating from Terraform versions near the original fork. The HCL syntax, module conventions and provider protocol overlap substantially, and for many estates the migration is a binary swap. Both projects now add independent features, so test your exact configurations and provider versions before committing.

Is Terraform still free to use?

For many ordinary internal uses, yes. The Business Source License 1.1 permits most everyday usage but restricts certain uses involving competitive commercial offerings. Software vendors, hosted service providers and organizations embedding Terraform in commercial products should review the license terms.

Which tool is better for state encryption?

OpenTofu provides client-side encryption for state and plan files that works independently of the storage backend, configured with passphrases or external key management. Terraform relies on backend-provided encryption, such as HCP Terraform or encrypted S3 and GCS buckets.

Can I switch back from OpenTofu to Terraform later?

It is not guaranteed. State-format downgrades are unsupported, and a configuration that uses an OpenTofu-only feature will not necessarily run under Terraform. Define your rollback plan before migrating, not after.

Do existing Terraform modules work with OpenTofu?

Largely yes, because both engines share HCL and a compatible provider protocol. For shared modules, test explicitly against every engine and version you support rather than relying on the fact that the files end in .tf.

Related reading

• Terraform: The Essential Automation Tool
• How to Structure Your Terraform Code: Step-by-Step Guide
• Top 3 Terraform Best Practices