In August 2023 HashiCorp relicensed Terraform under the Business Source License; six weeks later the community forked it into OpenTofu, now a Linux Foundation project. Two years on, the two tools are near-parity drop-in compatible — but they have diverged on licensing, on state encryption, on the registry, and on who is shipping what. This guide is the neutral, current, decisive breakdown: what changed, where each stands, what migration actually costs, and how to choose.
To choose between the two tools you have to understand why there are two tools. The split is not technical in origin — it is a licensing event, and the technical divergence followed from it.
On 10 August 2023, HashiCorp announced that its products — Terraform, Vault, Consul, Nomad, Packer, Boundary, and others — would move from the Mozilla Public License 2.0 (MPL 2.0), an OSI-approved open-source license, to the Business Source License 1.1 (BSL). The change applied to all future versions; Terraform 1.5.x and earlier remained MPL, but everything from the 1.6 line forward shipped under BSL.
The BSL is not an open-source license. It is "source-available": you can read the code, you can use it, you can modify it — with one carve-out. The BSL prohibits using the software to build a product that competes with HashiCorp's commercial offerings. HashiCorp's additional use grant defined the prohibited field narrowly, aimed squarely at companies offering hosted Terraform-as-a-service in competition with Terraform Cloud (now HCP Terraform). Each BSL release also carries a four-year clock: four years after a given version ships, that version automatically converts to the open MPL 2.0.
For the ordinary end user — a startup running `terraform apply` against their own AWS account — the BSL changed nothing practical. You could still download Terraform, still run it, still manage your own infrastructure. The license targets vendors, not operators. But the community reaction was not really about the practical end-user impact; it was about the precedent. A tool that had been genuinely open source for nearly a decade, that had a vast ecosystem of community-contributed providers and modules built on the assumption of openness, had been relicensed unilaterally with no community governance and no path to reversal.
The response was fast. Within days a group of companies and individuals published the "OpenTF Manifesto," asking HashiCorp to revert to an open-source license. When that did not happen, the group forked the last MPL-licensed Terraform (1.5.x) and created OpenTF, almost immediately renamed OpenTofu to avoid trademark conflict with the Terraform name. In September 2023 OpenTofu was accepted into the Linux Foundation, giving it neutral, foundation-level governance rather than single-vendor control. The first stable release, OpenTofu 1.6, landed in January 2024.
That is the whole origin in one paragraph: HashiCorp closed the license to protect its hosted business; the community forked the last open version into a foundation-governed project; the two have been shipping in parallel ever since. Everything below — the feature comparison, the migration cost, the choice framework — flows from that single event.
The single most-misstated fact in this debate: BSL Terraform is not "closed source" — the code is public on GitHub and you can use it freely for your own infrastructure. It is also not open source by the OSI definition, because the license restricts a competitive field of use. OpenTofu under MPL 2.0 is OSI-approved open source. If your procurement, legal, or compliance posture requires OSI-approved licensing, that distinction is the entire decision.
Because OpenTofu forked from Terraform 1.5 and deliberately preserved compatibility, the two tools share a common foundation that has not been broken on purpose. Understanding exactly what is shared — and what is not — is the core of the practical decision.
OpenTofu reads the same HashiCorp Configuration Language (HCL). Your `.tf` files do not change. Resource blocks, data sources, variables, outputs, modules, `for_each`, dynamic blocks, expressions, functions — all of it is the same language. OpenTofu speaks the same provider plugin protocol, so the same AWS, Google, Azure, Kubernetes, and thousands of other providers work without modification. It uses the same state file format, so an existing `terraform.tfstate` is read and written by OpenTofu without conversion. The CLI surface is intentionally familiar: `tofu init`, `tofu plan`, `tofu apply`, `tofu destroy`, `tofu state ...` mirror the Terraform commands one-to-one.
This is why the honest one-line summary of the comparison is: for most teams, on most days, they are the same tool. A typical Terraform configuration managing AWS infrastructure will run under OpenTofu and produce an identical plan. The divergence is real but it lives at the edges — in licensing, in a handful of features one project shipped and the other did not, in registry sourcing, and in the timing of when very new language features land in each.
Where compatibility is not guaranteed is at the bleeding edge of the language. The two projects develop independently now, so a brand-new HCL function or syntax feature introduced in Terraform 1.x might not exist in the contemporaneous OpenTofu release, and vice versa. In practice both projects track each other closely and the gap on core language features is small and short-lived — but if your configuration depends on a specific just-released function, you check that the function exists in your target tool before you migrate. This is the single most common source of "it worked on Terraform but not OpenTofu" surprises, and it is almost always a one-line fix or a version bump.
The language: HCL syntax, modules, expressions, the type system, and the overwhelming majority of built-in functions.
Providers: the plugin protocol is shared, so every provider (AWS included) runs on either tool unchanged.
State: the state file format is the same; you can point either tool at the same backend and the same state.
Backends: S3, GCS, Azure Blob, Consul, HTTP, local, and the rest are supported by both.
Workflow: init → plan → apply → destroy, plus state surgery commands (`state mv`, `state rm`, `import`), behave the same way.
The license: MPL 2.0 (OpenTofu) vs BSL 1.1 (Terraform) — the foundational difference.
Net-new features: OpenTofu has shipped capabilities Terraform lacks (state encryption, early variable/provider-iteration work); Terraform ships features at HashiCorp's cadence under HCP integration. The set on each side shifts release to release.
The registry: different default registries with different terms of use for providers and modules.
Brand-new HCL features: may land in one tool a release or two before the other.
Commercial platform: HCP Terraform / Terraform Cloud features (no-code provisioning, run tasks, Sentinel/HCP policy, the private registry) are HashiCorp products; OpenTofu has no first-party SaaS, and pairs instead with third-party platforms.
If there is one feature that gives OpenTofu a concrete, frequently-cited technical edge in 2026, it is client-side state encryption — shipped in OpenTofu 1.7 and still without a native equivalent in Terraform.
Terraform/OpenTofu state files are a well-known security liability. The state captures the full resource graph and, critically, it can contain secrets in plaintext: database passwords, generated credentials, private keys, API tokens — anything a resource or data source surfaces as an attribute. The conventional mitigation is to keep state in an encrypted-at-rest backend (S3 with SSE-KMS, for example) and lock down access. That protects the bytes on the backend but the state is still plaintext the moment it is read, downloaded, or cached locally or in CI.
OpenTofu's state and plan encryption encrypts the state client-side, before it leaves the machine, and decrypts it only in memory when the tool needs it. You configure a key provider — AWS KMS, GCP KMS, Azure Key Vault, OpenBao/Vault, or a PBKDF2 passphrase — and an encryption method, and from then on the `.tfstate` and `.tfplan` artifacts are ciphertext at rest everywhere: in the backend, in CI artifacts, on a laptop. Even an attacker who exfiltrates the state file gets nothing usable without the key.
Terraform does not offer a native, built-in equivalent. The HashiCorp guidance remains backend-level encryption plus access control, plus discipline around keeping secrets out of state in the first place (using write-only arguments, ephemeral values, and external secret managers). Those are legitimate practices — and a team that follows them rigorously narrows the gap — but they are not the same as transparent client-side encryption of the entire state artifact. For organizations in regulated industries, or any team that treats the state file as a crown-jewel secret store, this is a genuine reason teams cite for moving to OpenTofu.
It is worth being precise about scope: state encryption protects the state and plan files. It is not a substitute for keeping secrets out of state where you can, and it does not encrypt the values inside your provider API calls. But as a defense-in-depth control on the single most sensitive artifact in an IaC workflow, it is a meaningful capability that exists on one side of this comparison and not the other.
Providers and modules are where Terraform's decade-long network effect lives, and the registry is the most legally and operationally consequential place the two projects diverge.
When HashiCorp relicensed Terraform it also updated the terms of the HashiCorp Terraform Registry, restricting bulk access and reuse of the registry by competing tools. OpenTofu therefore stood up its own registry. The OpenTofu registry is a community-run, open index of providers and modules; it resolves the same providers (the AWS provider, the Kubernetes provider, and so on) because those providers are themselves open source and published independently of either registry. In day-to-day use you typically do not notice which registry you are pulling from — you declare `hashicorp/aws` in `required_providers` and it resolves.
The nuance that matters: the providers themselves are largely unaffected because most are MPL/Apache-licensed open-source projects maintained in their own repositories. The AWS provider is the canonical example — it is open source, it is published to both registries, and it is the same provider regardless of which tool pulls it. So the "ecosystem" in the sense of "can I get a provider for X" is effectively shared. Where you feel the split is in registry-level features (signing, namespacing, private module hosting) and in the long tail of older or niche community modules whose availability in the OpenTofu registry depends on community mirroring.
Terraform retains the deeper integration story through HCP Terraform: a first-party private registry, no-code modules, run tasks, drift detection, and policy-as-code via Sentinel and HCP policy enforcement. OpenTofu by design has no first-party SaaS; it leans on the third-party platform layer — tools like Spacelift, env0, Terrateam, Scalr, Atlantis, and others — for collaboration, policy, drift detection, and state management. For a lot of teams that platform layer is where they actually live day-to-day, and most of those platforms now support OpenTofu and Terraform interchangeably, which neutralizes much of the practical difference.
A fork lives or dies on momentum: is it maintained, is it shipping, is it being adopted, and is its governance durable? On all four, OpenTofu has cleared the bar that kills most forks.
OpenTofu did not stall after the initial wave of attention. It has shipped a steady release cadence under the Linux Foundation — 1.6 (the first stable fork), 1.7 (state encryption, removed-block, provider-defined functions), 1.8 (early provider/backend iteration and provider-mirror improvements), and subsequent releases — demonstrating that it is a living project with a roadmap, not a frozen snapshot of 2023 Terraform. Foundation governance matters here: the project is not controlled by any single company, contributors come from multiple vendors and the community, and the roadmap is public. That structure is precisely what the original manifesto was asking for, and it is what makes the fork credible as a long-term bet rather than a protest gesture.
On the Terraform side, HashiCorp has continued to invest heavily — arguably more visibly than before the fork, partly to demonstrate that the BSL product keeps moving. Terraform has shipped meaningful language and workflow improvements (test framework maturation, stacks, write-only/ephemeral handling for secrets, ongoing HCP integration) and the broader HashiCorp portfolio has continued under its commercial strategy. The 2024 acquisition of HashiCorp by IBM further changed the corporate backdrop: Terraform now sits inside a large enterprise vendor, which reassures some buyers (stability, support, procurement familiarity) and concerns others (the original reason many distrusted single-vendor control of the tool).
Adoption-wise, the realistic 2026 picture is a coexistence, not a rout in either direction. Terraform remains the incumbent with the larger installed base, the deeper enterprise relationships, and the brand recognition — most existing infrastructure in the world is still managed by Terraform. OpenTofu has captured the segment that cares about open-source licensing as a principle or a compliance requirement, plus cost-sensitive teams and the open-source-leaning end of the platform-engineering community. Major platforms, CI providers, and several Linux distributions and package managers ship OpenTofu, which lowers adoption friction considerably. The trajectory is that OpenTofu is the safe default for new green-field projects that want OSI-approved tooling, while Terraform remains entrenched where HCP investment or enterprise procurement already anchors it.
The migration is famous for being anticlimactic. Because OpenTofu reads the same config, the same state, and the same providers, the base case is genuinely a binary swap. The work is in the surrounding tooling, not the IaC itself.
The canonical single-state migration is: install the `tofu` binary, run `tofu init` in the working directory (it picks up the existing backend and providers), then run `tofu plan`. If the plan comes back as a no-op — no changes — you are migrated. From that point you run `tofu apply` instead of `terraform apply`. OpenTofu reads your existing `terraform.tfstate` directly, so there is no state conversion step and no risk of a forced re-create. The whole exercise for one isolated state is typically well under a day, often under an hour for a small configuration.
OpenTofu also ships migration affordances for the awkward parts. It understands the `terraform` block and the `.terraform.lock.hcl` dependency lock file. It can read both `.tf` and `.tofu` files (the latter lets a config opt into OpenTofu-specific syntax without breaking Terraform), and supports `_override` files in both extensions, so you can introduce OpenTofu-only features incrementally. For teams that want a managed cutover, OpenTofu documents a migration path and there are community tooling and platform features that automate the binary swap across many workspaces.
The real effort is everywhere the IaC touches your delivery system. CI/CD pipelines that hardcode `terraform` need the command swapped (or aliased). Pre-commit hooks, `tflint`/`tfsec`/Checkov integrations, Atlantis or Terrateam configuration, IDE extensions, and internal wrapper scripts all reference the Terraform binary by name. None of this is hard — it is find-and-replace plus a test run — but across a large estate with dozens of pipelines it is where the hours actually go. Budget for the pipeline change, not the IaC change.
The genuinely hard migrations are the ones tied to HashiCorp-specific platform features. If you are deeply invested in HCP Terraform / Terraform Cloud — using Sentinel policies, no-code modules, run tasks, the HCP private registry, or the HCP-hosted state and run environment — those do not have one-to-one OpenTofu equivalents, and migrating means also re-platforming onto a third-party tool (Spacelift, env0, Scalr, etc.) or self-hosted alternatives. That is a real project with real cost, and it is the dividing line between "trivial migration" and "this needs planning." A final caution worth stating plainly: migrating Terraform → OpenTofu is well-trodden and reversible-ish, but going back from OpenTofu to Terraform after adopting OpenTofu-only features (state encryption, `.tofu` syntax) is not guaranteed clean — so pick a direction deliberately.
1. Install tofu alongside (not over) Terraform. 2. In a working dir, run tofu init against the existing backend. 3. Run tofu plan and confirm a no-op (zero changes) — this is the safety gate. 4. Swap terraform → tofu in CI, hooks, and wrapper scripts. 5. Run tofu apply from the pipeline once and verify. For one state this is under a day; the multiplier is the number of pipelines, not the amount of HCL.
There is no universal winner — there is a right answer for your situation. The decision turns almost entirely on licensing posture and on how much you have invested in HashiCorp's commercial platform.
Strip away the noise and the choice reduces to two questions. First: does an OSI-approved open-source license matter to you — as a compliance requirement, a procurement constraint, or a principle? If yes, that points to OpenTofu, full stop, because Terraform under BSL cannot satisfy an OSI-open-source requirement. Second: are you deeply invested in HCP Terraform / Terraform Cloud features (Sentinel, no-code modules, run tasks, the HCP private registry)? If yes, staying on Terraform avoids a re-platforming project that is far larger than the IaC migration itself. Most organizations have a clear answer to one of those two questions, and that answer decides it.
A pattern worth naming: a large share of teams are not choosing one tool forever — they are choosing per project. New services start on OpenTofu; legacy estates stay on Terraform until there is a reason to move. Because the config is shared, this dual-track approach is low-friction, and the platform layer (which increasingly supports both) makes it operationally seamless. The "vs" framing is real on licensing and on a few features, but in the trenches many organizations run both without drama.
You need OSI-approved open-source tooling for compliance, government, or procurement reasons — BSL does not qualify.
You want native client-side state encryption as a defense-in-depth control on secrets in state.
You are starting green-field and want a foundation-governed tool with no single-vendor license risk and no commercial-use ambiguity.
You are cost-sensitive and you pair IaC with a third-party platform (Spacelift, env0, Scalr, Atlantis) rather than HCP Terraform.
You are philosophically uncomfortable with single-vendor control of your core infrastructure tooling after the BSL precedent.
You are heavily invested in HCP Terraform / Terraform Cloud — Sentinel policy, no-code provisioning, run tasks, the HCP private registry, hosted state and runs.
You want a single enterprise vendor with formal support, SLAs, and procurement familiarity (now under IBM).
Your team and tooling are standardized on Terraform and the BSL field-of-use restriction simply does not touch what you do (it only restricts building a competing hosted product).
You depend on a brand-new Terraform-specific language feature that has not yet landed in OpenTofu.
Organizational inertia is real and the migration's marginal benefit does not clear the bar for your team right now — "it works, BSL does not affect us" is a legitimate position.
A reasonable worry for AWS-centric teams: does picking OpenTofu cost me anything on AWS? The short answer is no — the AWS provider is the same open-source provider on both tools, and AWS does not privilege one over the other.
The Terraform AWS provider (`hashicorp/aws`) is an open-source project. It is published to both the HashiCorp and OpenTofu registries, and it is the identical provider regardless of which tool resolves it. Every AWS resource and data source — EC2, VPC, IAM, S3, RDS, EKS, Lambda, CloudFront, the entire surface — is available on OpenTofu exactly as it is on Terraform, at the same version, with the same behavior. There is no "AWS support gap" between the two tools. Authentication, assume-role, AWS SSO, the S3+DynamoDB (or S3 native locking) backend, and provider configuration all work the same way.
On the backend side, AWS-hosted state is identical: both tools use the S3 backend, both support state locking (the S3 backend now supports native S3-based locking in addition to the long-standing DynamoDB lock table), and both encrypt at rest via SSE-KMS on the bucket. OpenTofu layers its client-side state encryption on top of that if you want it — which, on AWS, you wire to AWS KMS as the key provider, keeping key custody inside your own account. That is a strict superset of the AWS state-security posture available on Terraform.
AWS's own ecosystem is tool-neutral in practice. AWS funding programs, Well-Architected reviews, and partner-led engagements are about your architecture and outcomes on AWS, not about whether the HCL is executed by `terraform` or `tofu`. AWS partners deliver infrastructure-as-code work in both, and a migration between the two does not change anything about how your AWS account, billing, credits, or support relationship works. In other words: choose the tool on licensing and platform grounds; the AWS story is the same either way.
The honest comparison: identical where it matters most (language, providers, state, workflow), divergent on the four things that actually drive the decision — licensing, state encryption, registry/platform, and governance.
| Dimension | Terraform | OpenTofu |
|---|---|---|
| License | BSL 1.1 (source-available; not OSI open source; 4-yr conversion to MPL) | MPL 2.0 (OSI-approved open source) |
| Governance | Single vendor — HashiCorp (now IBM) | Linux Foundation (multi-vendor, community) |
| Config language | HCL | HCL — same files, drop-in |
| Providers (incl. AWS) | Shared open-source providers | Same providers, same versions |
| State format | Same — fully interchangeable | Same — reads/writes existing tfstate |
| Client-side state encryption | No native equivalent (backend + discipline) | Yes — native, since 1.7 (KMS/Vault/passphrase) |
| Default registry | HashiCorp registry (restricted terms) | Community OpenTofu registry |
| First-party SaaS | HCP Terraform / Terraform Cloud | None — pairs with Spacelift/env0/Scalr/Atlantis |
| Policy as code | Sentinel + HCP policy (native) | OPA/Conftest, Checkov, platform-native |
| Cost | CLI free; HCP paid above free tier | Free; platform costs are external/optional |
| Best fit | HCP-invested + enterprise-vendor buyers | OSI-license needs, green-field, cost-sensitive |
Situation: A pending enterprise deal required attestable OSI-approved open-source tooling and demonstrable encryption of any artifact that could contain secrets. The team was on Terraform 1.7 (BSL) and storing state in S3 with SSE-KMS, but plaintext secrets were landing in CI artifacts during plan. No in-house IaC specialist; the lead engineer was 80% on product.
What CloudRoute did: Routed within a day to an AWS partner with Terraform/OpenTofu and SOC 2 experience. The partner ran the no-op `tofu plan` gate across all 6 workspaces (all clean), swapped the binary in the GitHub Actions pipelines, and enabled OpenTofu client-side state + plan encryption wired to AWS KMS — keeping key custody in the customer's own account. CI artifacts went from plaintext to ciphertext at rest.
Outcome: Full cutover in 4 working days; zero infrastructure changes (every plan stayed a no-op). The OSI-open-source + state-encryption requirements were met and documented for the enterprise security review. Engagement was structured under AWS partner funding — the customer paid $0; CloudRoute's commission was paid by the partner.
workspaces migrated: 6 · infra changes: 0 · founder time: ~5 hours · cost to customer: $0
CloudRoute routes you to a vetted AWS partner who scopes the right tool, runs the migration cleanly (no-op plan gate, CI swap, state encryption), and structures it under AWS partner funding. Customer pays $0. No procurement theater.