The Terraform fork happened in 2023: HashiCorp switched the license to BSL, and the community answered with the OpenTF manifesto. Back then the question sounded anxious — is it even safe to bet on a fork? By 2026 it is outdated. OpenTofu lives under the Linux Foundation, stays a drop-in replacement with the same HCL and the same providers, runs 1.11 in production, and counts Allianz and Fidelity among its adopters. The question turned pragmatic: not whether you can, but when the fork is already the better choice.
From "risky" to "the default choice"
OpenTofu is not a catch-up clone. It is a separate engine with the same syntax but its own trajectory. Drop-in here is literal: the same HCL, the same providers from the registry, the .terraform.lock.hcl file is not renamed, the terraform {} block is accepted as is. The CLI is tofu, governance is community-driven under the Linux Foundation rather than a single vendor. For a new project the barrier to entry is zero, and the MPL 2.0 (OSI) license clears the BSL question with your lawyers right away, with no caveats.
Where the fork pulled ahead of upstream
The headline of the past two years: OpenTofu does not merely hold parity — in places it leads the original.
Native state and plan encryption (since 1.7) — an encryption {} block with AWS/GCP KMS or OpenBao, no external sops or GPG. Terraform has nothing native here. Early evaluation (1.8) allows variables inside the backend {} block and in module.source — dynamic backend configs that are impossible in upstream. for_each on providers (1.9) collapses multi-region into a single block instead of hand-written aliases. Native S3 locking (use_lockfile, no DynamoDB) landed in OpenTofu 1.10 — a release ahead of Terraform 1.11. This is no longer a free replacement but an engine that solves problems the original cannot.
Lock-in is asymmetric: staying is also a bet
A common myth: migration is a risk and the status quo is safety. In reality compatibility is one-way. Terraform → OpenTofu goes smoothly: migration tooling, a plan with zero changes. The way back is painful — if you have used the unique features, encrypted state and dynamic backends are simply incompatible with the original. So doing nothing is also a choice with consequences: the longer a team sits on a BSL engine and accretes HCP-specific pieces (Stacks, Sentinel), the more expensive the eventual untangling.
Migration is cheaper than the fear of it
A real case: 8 thousand lines, 12 modules, three environments, an S3 + DynamoDB backend, GitHub Actions — the move took about four hours, and most of that time went into rewriting CI rather than code. The outline: first apply all pending changes and back up the state — you migrate from a clean state. Then in a coordinated way delete .terraform.lock.hcl across the whole team at once, otherwise a colleague holding a Terraform lock file hits hash conflicts. Next, tofu init and tofu plan, which must show zero changes — that is the go/no-go gate: a diff means you do not migrate, you investigate. The last step is swapping setup-terraform for setup-opentofu in the pipeline. And never mix binaries on one state: after tofu apply all engineers and CI move to tofu, or silent drift creeps in.
Where Terraform still wins
An honest counterpoint: the fork is not a universal answer. Staying on Terraform is rational if you have a deep investment in HCP Terraform and Sentinel, where the policy and orchestration ecosystem is tied to the vendor; if you need Stacks to orchestrate many workspaces, and OpenTofu has no equivalent yet; if you need the official MCP integration for AI agents — Terraform has it, the fork does not officially yet, and that matters when you build agentic pipelines; if you need enterprise support from IBM and your legal team is fine with BSL. That is a rational choice, not conservatism.
The 2026 decision rule
For a greenfield project the default is OpenTofu: zero barrier to entry, an OSI license, features that lead in places, no BSL exposure. The fork is already worth it when you have no HCP lock-in and you value native state encryption, dynamic backends, and the absence of vendor dependence. Staying on Terraform makes sense only with a deep commitment to HCP Stacks, Sentinel, or MCP — or a hard requirement for vendor support. The era of a single IaC standard is over and the era of choice has begun; and in 2026, for most new projects, the deliberate choice shifts toward the fork.