Terraform vs OpenTofu in 2026: the fork has diverged, so which do you standardize on?

Summary. Terraform and OpenTofu started as the same code and are now two different tools. HashiCorp relicensed Terraform from the open-source MPL 2.0 to the Business Source License (BUSL 1.1) on 10 August 2023; IBM then bought HashiCorp for $6.4 billion, closing the deal on 27 February 2025. OpenTofu, the MPL 2.0 fork taken from Terraform 1.5.6, joined the Cloud Native Computing Foundation (CNCF) as a sandbox project on 23 April 2025 and sits under the Linux Foundation. By August 2026 the fork has real feature gaps: OpenTofu ships client-side state encryption (since v1.7), ephemeral values (v1.11, December 2025) and dynamic prevent_destroy (v1.12.0, 14 May 2026) that Terraform does not have. HCP Terraform bills per managed resource, at $0.10 (Essentials), $0.47 (Standard) and $0.99 (Premium) per resource each month as of July 2026, with self-hosted Terraform Enterprise from about $15,000 a year; the OpenTofu CLI is free. Fidelity Investments moved 2,000+ applications and 50,000+ state files onto OpenTofu. This guide compares license, features, cost and migration effort so you can pick one to standardize on.

For two years "Terraform vs OpenTofu" was a licensing argument with almost no practical difference in the tool. That has changed. The two codebases now ship different features on different release cadences under different owners, and the choice you make in 2026 sets your infrastructure-as-code (IaC) direction for years. This is a working guide for platform engineers, DevOps leads and CTOs who have to standardize a team on one of them.

How one tool became two

Terraform was open source under the Mozilla Public License 2.0 (MPL 2.0) from its first release until August 2023. On 10 August 2023 HashiCorp moved Terraform, Vault, Consul and Nomad to the Business Source License 1.1 (BUSL 1.1), a source-available licence that restricts using the code to build a product that competes with HashiCorp. Within days a group of contributors and vendors announced a fork, first called OpenTF and then OpenTofu, and placed it under the Linux Foundation to keep it on the MPL 2.0.

Ownership then changed on the Terraform side. IBM announced its intent to acquire HashiCorp for $6.4 billion on 24 April 2024, and the deal closed on 27 February 2025 after clearance from the UK Competition and Markets Authority and the US regulators. OpenTofu went the other way, into neutral foundation governance: the CNCF accepted it as a sandbox project on 23 April 2025. So in 2026 you are choosing between an IaC tool owned by IBM under a source-available licence, and a fork governed by the Linux Foundation under an OSI-approved open-source licence. The application modernization and platform decisions that depend on IaC now inherit that split.

One nuance gets lost in most write-ups. BUSL is source-available, not closed: teams that simply run Terraform to manage their own infrastructure are not the target of the licence, and can keep using the community binary at no cost. The restriction bites vendors who embed Terraform in a competing commercial product. The real questions for an end-user team are different: where is each tool going, what does each cost at scale, and what does it take to move.

Where the fork actually diverged in 2026

OpenTofu forked from Terraform 1.5.6, so through most of 2024 the two behaved almost identically. From 2025 onward OpenTofu started shipping capabilities with no Terraform equivalent. Client-side state encryption arrived in OpenTofu 1.7, letting teams encrypt the state file with key providers including PBKDF2, AWS KMS, GCP KMS and OpenBao before it touches a backend. Ephemeral values, which keep secrets out of the state file entirely, landed in OpenTofu 1.11 in December 2025. OpenTofu 1.12.0, released on 14 May 2026, added dynamic prevent_destroy, described by InfoQ as the feature Terraform never shipped, because destroy protection can finally be driven by a variable rather than hard-coded.

The table below maps the practical differences as of August 2026. Terraform still leads in one area that matters at large scale: managed orchestration through Terraform Stacks, which reached general availability and has no native OpenTofu equivalent.

The pattern is clear. OpenTofu leads on in-tool engineering features that a team controls directly (encryption, ephemeral secrets, evaluation flexibility). Terraform, through HCP Terraform, leads on the managed platform around the tool (Stacks, policy, a private registry and run management). Which side matters more depends on whether you want capability in the CLI or capability in a paid control plane.

What Terraform still does well

Terraform is the incumbent, and incumbency is worth real money in tooling. The provider and module ecosystem grew up around Terraform, most tutorials and Stack Overflow answers assume it, and every managed IaC platform supports it. Terraform Stacks is a genuine differentiator for large estates: it groups related configurations, manages cross-stack dependencies with Linked Stacks, and handles module lifecycle management as a first-class feature, all inside HCP Terraform. If your requirement is a vendor-run control plane with policy-as-code, private module registry, drift detection and run governance out of the box, HCP Terraform is a more complete product today than assembling the same around OpenTofu.

OpenTofu answers this by being deliberately unopinionated about the platform. Because it is a free CLI, you pair it with whichever backend you prefer, whether self-managed remote state or a third-party control plane such as Spacelift, env0 or Scalr. That is more assembly, but it avoids per-resource platform fees and single-vendor lock-in. The trade is real: convenience and an integrated product on one side, control and open governance on the other.

The real cost comparison

The tools themselves are both free to run. Cost shows up in the control plane. HCP Terraform prices on Resources Under Management (RUM): it counts managed resources such as instances, Kubernetes clusters, security groups, IAM roles and policies, while excluding null_resource and terraform_data, and it bills hourly on peak usage. The Free tier covers up to 500 managed resources with unlimited users; the older Free (Legacy) plan ended on 31 March 2026 and those organizations moved to the current Free tier.

RUM pricing is easy to underestimate. At $0.47 per resource on the Standard plan, a 5,000-resource estate costs about $2,350 a month, roughly ₹2 lakh, before any add-ons. The same estate on OpenTofu with a self-managed backend has no per-resource fee, though you carry the operational cost of running that backend. This is a straightforward cloud cost optimization decision: pay a vendor for a finished control plane, or run your own and keep the per-resource line at zero. For teams already tracking cloud cost across AWS, Azure and GCP, IaC platform fees belong in the same FinOps model as compute and storage.

Migration cost: what actually breaks

Switching the binary is trivial. Everything around the binary is the work. OpenTofu is a drop-in replacement for the versions it forked from: OpenTofu 1.6.2 is compatible with Terraform 1.5.x and lower, and largely compatible with Terraform 1.6.x. The recommended path is to move to OpenTofu 1.6.2 first, confirm parity, then upgrade to the current line. Back up state before you touch anything.

            # 1. back up state first (local or remote backend)
cp terraform.tfstate terraform.tfstate.backup

# 2. swap the binary on Terraform 1.5.x / 1.6.x code
tofu init          # re-initialises providers and the backend
tofu plan          # expect: no changes

# 3. let OpenTofu take ownership of state
tofu apply

# 4. upgrade to the current OpenTofu line once parity is confirmed
tofu version
          

The catch is version drift. If a team has moved onto Terraform releases published after the BUSL switch (1.6 and later), there is no guarantee of state-format or language compatibility with OpenTofu, so the migration becomes a configuration exercise, not just a CLI swap. That is why the cost lives in the surrounding ecosystem, not the code.

Fidelity Investments is the clearest large-scale example. In a KubeCon lightning talk on the migration, David Jackson, Vice President of Automation Tooling at Fidelity, described moving more than 2,000 applications, over 50,000 state files and north of four million cloud resources onto OpenTofu, with upwards of 4,000 state-file updates on a busy day, and flipping the default CLI to OpenTofu. His summary of the effort: "The code itself isn't the hard part. Changing the CLI in a pipeline is trivial. The complexity lives in the surrounding ecosystem, versioning, CI/CD, governance, artifact management." The lesson for anyone planning a migration is to budget for the pipeline, policy and module-registry work, and to treat the CLI swap as the smallest line item. This is the same discipline a Kubernetes 1.35 upgrade demands: the version bump is easy, the surrounding fleet work is the project.

A decision framework: which to standardize on

There is no single winner. Standardize on the tool whose direction matches your constraints, and write that decision down so the whole organization moves together.

A useful default in 2026: greenfield teams and cost-sensitive estates start on OpenTofu, because the licence risk is zero and the feature velocity is higher; teams already deep in HCP Terraform with Stacks and policy workflows stay, because the migration rarely pays for itself against a control plane they actively use. The real cost is usually the migration, not the code, so the burden of proof sits on the switch, not on staying put.

India-specific considerations

Two factors matter for Indian teams. First, cost. IaC platform fees are dollar-denominated and scale with resource count, so a growing estate can see its control-plane bill rise faster than its cloud bill. Folding IaC into a broader plan to cut cloud spend for Indian teams keeps that line visible rather than buried in a SaaS renewal.

Second, data protection. Under the Digital Personal Data Protection (DPDP) Act 2023, organizations are accountable for how personal data is stored and secured. Terraform and OpenTofu state files routinely contain resource metadata, and can contain sensitive values if modules are written carelessly. OpenTofu's native client-side state encryption gives an in-tool control to protect that state at rest, which is useful for banking, financial services and healthcare teams that must show data is encrypted wherever it lives. Neither tool makes an organization DPDP compliant on its own; encryption of state is one control within a wider data-handling design.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based, ISO 27001:2022-certified engineering organization that helps teams standardize their infrastructure-as-code toolchain and, where it makes sense, migrate from Terraform to OpenTofu without breaking pipelines. Our senior engineering teams handle the parts that carry the real cost: CI/CD rewiring, state backup and validation, policy-as-code, module-registry setup and DPDP-aligned state encryption. If you are weighing the switch or want a clean IaC standard across a growing cloud estate, talk to us via our contact page or read how we run a managed cloud FinOps service.

References

1. IBM completes HashiCorp acquisition (RedMonk)

1. Terraform, IBM and the BUSL licence (The New Stack)

1. OpenTofu joins the CNCF (The New Stack)

1. OpenTofu project page (CNCF)

1. OpenTofu 1.7.0: state encryption and provider-defined functions (OpenTofu)

1. OpenTofu 1.12: the feature Terraform never shipped (InfoQ)

1. Migrating to OpenTofu from Terraform 1.6.x (OpenTofu docs)

1. Fidelity Investments shares its Terraform-to-OpenTofu migration story (OpenTofu)

1. Migrating from Terraform to OpenTofu at scale, David Jackson (KubeCon, YouTube)

1. Terraform Stacks general availability (HashiCorp Developer)

1. HCP Terraform pricing explained (Scalr)

1. HCP Terraform Free tier changes (Scalr)

1. What is OpenTofu, features and adoption (Scalr)

_Last updated: 1 August 2026._