OpenTofu vs Terraform 2026: Time to Switch?

By Ankush Madaan, SquareOps · Published May 28, 2026 · Last updated May 28, 2026

In this article

• Why did Terraform's license change?
• What is OpenTofu and who's behind it?
• Are OpenTofu and Terraform compatible?
• OpenTofu features Terraform doesn't have
• OpenTofu vs Terraform comparison table
• When should you switch to OpenTofu in 2026?
• When should you stay on Terraform?
• OpenTofu migration guide: how to move in an afternoon
• FAQ

Two and a half years into the fork, the OpenTofu vs Terraform 2026 debate has moved past politics. The technical gap has widened, the registry mirrors the Terraform provider ecosystem, and Spacelift reports that roughly half of its IaC deployments now run on OpenTofu. This is the practical decision framework we use with clients on our Terraform consulting services engagements — when the switch makes sense, when it doesn't, and how to actually do it.

Why did Terraform's license change?

On August 10, 2023, HashiCorp relicensed Terraform (and Vault, Consul, Nomad, Packer, Boundary, Waypoint) from MPL 2.0 to the Business Source License (BSL/BUSL) v1.1. The Terraform license change was framed as a defence against vendors monetising HashiCorp's OSS work without contributing back — MongoDB, Elastic, and Confluent had taken similar steps.

The practical impact of the HashiCorp BSL:

• Terraform v1.5.7 and earlier remain MPL 2.0 — fully open source, forever.
• Terraform v1.6+ ships under BSL: source-available, with restrictions on offering a competing commercial product. The OSI does not classify BSL as open source.
• Internal use (build pipelines, your own infra, your own SaaS) is still allowed. Building a competing IaC SaaS on top of post-1.5.7 Terraform is not.

Within five days, the OpenTF Manifesto launched. By September 20, 2023, the Linux Foundation accepted the project — renamed OpenTofu — and on April 23, 2025, OpenTofu was accepted into the CNCF at Sandbox maturity.

What is OpenTofu and who's behind it?

OpenTofu is an MPL 2.0 fork of Terraform v1.5.7, maintained by a Technical Steering Committee under the Linux Foundation and stewarded by the CNCF. It's not a clone — it has its own release cadence (v1.12 shipped Q2 2026), its own roadmap, and its own divergent feature set.

Engineering contributors include Spacelift, env0, Gruntwork, Harness, and Scalr, plus 180+ community contributors. No single vendor controls the roadmap, which is the entire point of the governance model. The contrast with Terraform — now owned by IBM after the 2025 acquisition — is the structural argument for OpenTofu.

Are OpenTofu and Terraform compatible?

For most teams, yes — tofu is a drop-in replacement for terraform. Same HCL syntax. Same provider ecosystem (the OpenTofu Registry mirrors the Terraform Registry and lists 3,000+ providers). State files written by Terraform 1.5.x are readable by OpenTofu, and vice versa for that baseline version.

Where they diverge:

• Provider lockfile uses different registry hashes — you'll regenerate .terraform.lock.hcl after switching.
• Newer Terraform features (post-1.6) like ephemeral resources, dynamic provider config, and certain state moves are tracked but not always 1:1 — OpenTofu has its own takes (e.g., removed block landed in both, but with subtle differences).
• File extension: OpenTofu supports .tofu files for language-specific overrides while still parsing .tf.
• HCP Terraform / Terraform Enterprise backends work with Terraform only. OpenTofu pairs with Spacelift, env0, Scalr, or self-hosted state.

OpenTofu features Terraform doesn't have

Two and a half years of divergence, and several OpenTofu features now have no Terraform equivalent:

• Native state encryption (1.7+). OpenTofu encrypts the entire state JSON before it touches your backend — AWS KMS, GCP KMS, or PBKDF2 are supported out of the box. Terraform still requires backend-level encryption (S3 SSE, Azure Blob CSE) and treats sensitive values as plaintext in state. For teams handling regulated data, this single feature has been the trigger to switch.
• Early variable evaluation (1.8+). Variables and locals are usable inside backend blocks, module source strings, and required_providers — the three places Terraform users have asked for variables for years. No more -backend-config wrappers in CI.
• Exclude flag for plan/apply. tofu plan -exclude=module.legacy is the inverse of -target and far more useful for incremental rollouts.
• Provider iteration (for_each on providers). Cleaner multi-region/multi-account modules without hand-rolled provider aliases.
• Ephemeral values and removed block — both projects shipped these, but OpenTofu's semantics around lifecycle were finalised first in 1.11 (Dec 2025).

OpenTofu vs Terraform comparison table

When should you switch to OpenTofu in 2026?

Switch when one or more of these is true:

• You need state encryption at rest, natively. Healthcare, fintech, regulated SaaS — this is the cleanest argument.
• You're vendor-neutral by policy. Public sector, OSS-first teams, and organisations with procurement-level open-source mandates can't ship BSL in production.
• You're building an IaC SaaS or platform product. BSL prohibits competing commercial offerings on top of post-1.5.7 Terraform. OpenTofu has no such restriction.
• You're starting greenfield. No migration tax, no Enterprise contract, no Sentinel investments to preserve.
• Your CI/CD already runs Spacelift, env0, Scalr, Atlantis, or Terragrunt. All four added first-class OpenTofu support in 2024.

When should you stay on Terraform?

Be honest about reverse-cases. Stay on Terraform if:

• You've invested heavily in HCP Terraform or Terraform Enterprise. Sentinel policies, dynamic provider credentials, no-code modules, and the run UI don't have a one-line OpenTofu equivalent.
• You rely on the wider HashiCorp stack. Vault, Consul, and Nomad integrations are still tightest with Terraform.
• Your auditors only recognise vendor-supported tooling. Some regulated environments require a commercial support contract on the IaC tool itself.
• You need IBM/HashiCorp's AI features. The HCP AI Ecosystem rolled out in early 2026 — that's a Terraform-only roadmap item.

If you're already happy on Terraform 1.5.7 (MPL) or Terraform CE — the recently rebranded community edition — there's no urgency. The fork is real; the panic is not.

OpenTofu migration guide: how to move in an afternoon

For most teams the OpenTofu migration guide fits in a single afternoon. The Terraform vs OpenTofu tutorial below is what we run with clients during a Terraform consulting engagement:

1. Install OpenTofu. brew install opentofu on macOS, snap install opentofu on Linux, or grab the binary from GitHub releases. Same versioning scheme as Terraform.
2. Run tofu init in an existing Terraform project. It reads your existing .tf files, downloads providers from the OpenTofu Registry, and regenerates the lockfile. Your state file is untouched.
3. Plan and diff. tofu plan should show zero changes against a Terraform-managed state, provided you came from Terraform 1.5.x or earlier. If you used post-1.6 features, expect a 10-minute config cleanup.
4. Update CI/CD. Replace terraform with tofu in your pipeline scripts. Most plugins (Atlantis, Spacelift, env0, Scalr, GitLab CI templates, GitHub Actions) accept either binary. For a full GitLab CI walkthrough see our Terraform CI/CD pipelines with GitLab guide.
5. Pin the OpenTofu version. Add required_version = ">= 1.12.0" to your terraform {} block. Yes, OpenTofu still uses the terraform block name for backward compatibility — they decided not to break HCL parsing.
6. Migrate state encryption (optional but recommended). Add an encryption block with AWS KMS, run tofu init, and OpenTofu rewrites the state encrypted on next apply. For deep state guidance see our Terraform state best practices.

What about Terragrunt, Atlantis, and Spacelift?

All three ship first-class OpenTofu support today. Terragrunt added terragrunt_binary config, Atlantis 0.27+ accepts tofu as a workflow runner, and Spacelift made OpenTofu the default in mid-2024. If you're already using one of these, the migration is largely a one-line config change. For deeper Terraform best practices that carry over to OpenTofu without modification, see our Terraform best practices at scale and Infrastructure as Code tools guide.

The bottom line

For greenfield IaC, OSS-first teams, and anyone with state-encryption or vendor-neutrality requirements, OpenTofu is the safer 2026 default. For teams locked into HCP Terraform, Sentinel, or Vault-tight workflows, Terraform still wins. The migration cost is genuinely low — most teams can pilot in an afternoon — so the decision is less "should we switch?" and more "when do we run the pilot?" Talk to our Terraform consulting team or book a 30-minute call to scope your migration.