Terraform vs OpenTofu: What Changed

By Kokil Thapa | Last reviewed: September 2026

Terraform vs OpenTofu: What Changed is the question every team hits after HashiCorp relicensed Terraform under the Business Source License in August 2023. The tooling looked identical on day one. The governance, license terms, and long-term roadmap diverged fast. If you provision servers with infrastructure as code, you need a clear picture of what still works, what broke, and what is politics versus engineering. This guide maps the fork timeline, license impact, CLI differences as of 2026, and a practical migration path you can run in CI this week.

Why Did HashiCorp Change the Terraform License in 2023?

HashiCorp announced the license change on 10 August 2023. Terraform moved from the Mozilla Public License 2.0 to the Business Source License 1.1. MPL allowed unrestricted use, modification, and redistribution. BSL restricts competing commercial offerings built on the same code.

The stated goal was protecting HashiCorp's business model. Terraform Cloud, Terraform Enterprise, and HCP Terraform generate revenue. Cloud vendors had shipped managed Terraform services. HashiCorp wanted to block direct clones of their hosted product.

The community reaction was immediate. Within weeks, a group of companies and contributors announced OpenTofu. The project landed under the Linux Foundation in September 2023. It forked from Terraform 1.5.x — the last MPL release line.

For teams running Terraform on VPS infrastructure, the shock was less about daily commands and more about legal review. Legal teams asked whether internal IaC pipelines counted as a "competing service." Most internal use cases were fine. The uncertainty pushed many orgs toward OpenTofu anyway.

What Is the Difference Between BSL and MPL for Terraform Users?

The license change is the root cause of the entire fork. Everything else — CLI flags, provider pins, CI images — flows from that decision.

Business Source License (Terraform)

BSL 1.1 is source-available, not open source by OSI definition. You can read, modify, and use the code. You cannot offer a competing commercial service built on Terraform's code without HashiCorp's permission.

HashiCorp set a change date — four years after each release version — when that version converts to MPL 2.0. Terraform 1.14.x (current in 2026) will eventually become MPL, but always four years behind the leading edge.

For most engineering teams, internal IaC use is unaffected. You write modules, run plans in CI, and store state remotely. The friction appears when you build a product on top of Terraform's engine or when legal wants written clearance.

Mozilla Public License 2.0 (OpenTofu)

OpenTofu stays under MPL 2.0 permanently. You can fork it, embed it in products, and ship commercial offerings without a relicensing clock. That matters for platform teams, consultancies, and vendors building IaC tooling.

The OpenTofu manifesto commits to keeping the core tool free and community-governed. Governance runs through the OpenTofu Technical Steering Committee under the Linux Foundation.

Neither license affects your HCL syntax for basic resources. Your main.tf files do not need a rewrite on day one. The split shows up in governance, new features, and long-term product bets.

Are Terraform and OpenTofu CLI Commands Still Compatible?

Yes, for the core workflow. Both tools use the same fundamental commands: init, plan, apply, destroy, import, and state. Provider plugins follow the same protocol. A module written for Terraform 1.5 generally runs on OpenTofu 1.9+ without edits.

Divergence grows with each release after the fork. By 2026, you cannot assume feature parity.

Features OpenTofu Added First

OpenTofu 1.7 introduced client-side state encryption. You encrypt state at rest before it hits S3, Azure Blob, or GCS. The encryption passphrase never transits to the remote backend. For teams storing state in shared buckets — a pattern covered in remote state on S3 with locking — this is a genuine security upgrade.

OpenTofu also shipped the removed block. It replaces awkward terraform state rm workflows when you decommission resources cleanly. Early variable evaluation landed in OpenTofu 1.8, letting you reference variables in backend and provider blocks more flexibly.

Features Terraform Added Post-Fork

Terraform 1.8+ added removed blocks with a different semantic model, plus import blocks for declarative adoption. Terraform 1.10 introduced ephemeral resources — credentials and tokens that exist only during apply and never persist in state.

Terraform Stacks, available through HCP Terraform, target multi-environment deployments with a higher-level abstraction. OpenTofu has no equivalent as of late 2026.

Pin your tool version in CI. Treat it like you treat provider version pinning — unpinned runners cause silent drift.

# .terraform-version or CI env
TOFU_VERSION=1.10.6
TF_VERSION=1.14.2

# Install OpenTofu in CI (GitHub Actions example)
- uses: opentofu/setup-opentofu@v1
  with:
    tofu_version: 1.10.6

# Equivalent Terraform install
- uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: 1.14.2

Can You Migrate from Terraform to OpenTofu Without Breaking State?

Yes. Migration is a binary swap for most teams, not a rewrite. State files use the same underlying JSON structure. OpenTofu reads Terraform-produced state and vice versa for standard resources.

I have migrated sister-site pipelines on shared EC2 infrastructure from Terraform to OpenTofu. The process took one CI pipeline change and a tofu init -upgrade run. No resource recreation occurred.

Step-by-Step Migration Checklist

1. Audit provider constraints. Open your versions.tf. Confirm providers allow OpenTofu in their required_providers block. Most HashiCorp and community providers added opentofu to the compatibility matrix by 2024.
2. Pin OpenTofu version. Match or exceed your current Terraform minor version where possible. OpenTofu 1.8.x aligns roughly with Terraform 1.8.x feature sets.
3. Replace the binary in CI. Swap hashicorp/terraform Docker image for ghcr.io/opentofu/opentofu. Update GitLab CI or GitHub Actions accordingly — see Terraform CI/CD with GitHub Actions for the pipeline pattern.
4. Run init with state upgrade. Execute tofu init -upgrade locally first, then in CI against a staging workspace.
5. Verify with plan. A clean migration shows zero changes. Any unexpected destroys mean a provider version mismatch — stop and investigate.
6. Update backend lock table. If you use DynamoDB or equivalent for state locking, no change is needed. The lock schema is identical.
7. Remove old Terraform lock file entries. Delete .terraform.lock.hcl provider checksums if the provider republished binaries under new hashes for OpenTofu.

# After swapping binary, from your module root:
tofu init -upgrade
tofu plan -out=migration.plan

# Expected output:
# No changes. Your infrastructure matches the configuration.

# Optional: enable state encryption (OpenTofu only)
# encryption.tf
terraform {
  encryption {
    key_provider "pbkdf2" "main" {
      passphrase = var.state_passphrase
    }
    method "aes_gcm" "main" {
      keys = key_provider.pbkdf2.main
    }
    state {
      method   = method.aes_gcm.main
      enforced = true
    }
  }
}

Back up state before any migration. Pull the current state file from your remote backend and store it offline. Use the same discipline described in managing Terraform state safely.

Do not run Terraform and OpenTofu against the same workspace concurrently. Pick one binary per state file. Mixed tooling corrupts state locks and produces conflicting serial numbers.

How Do Providers and Registries Work After the Fork?

Provider plugins are the bridge between HCL and real infrastructure. Both tools use the Terraform Plugin Framework and SDK. A provider built for Terraform runs on OpenTofu without recompilation in nearly all cases.

The Terraform Registry at registry.terraform.io remains the primary source for providers and modules. OpenTofu can consume it directly. The OpenTofu project also maintains registry.opentofu.org as a mirror and fallback.

HashiCorp providers — AWS, Azure, Google, Kubernetes — continue publishing to the public registry. Licensing of provider binaries is separate from the Terraform CLI license. HashiCorp has not restricted provider downloads for OpenTofu users.

Module sources in your module blocks still work:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"
  # Works on both Terraform and OpenTofu
}

For policy scanning, tools like Checkov support both engines. See Checkov for Terraform misconfiguration scanning for the CI integration pattern. Validate your scanner version explicitly supports OpenTofu if you switch.

Which Tool Should You Choose in 2026 — Terraform or OpenTofu?

There is no universal winner. The right choice depends on your license comfort, existing platform investments, and feature needs.

Stay on HashiCorp Terraform If…

• You run HCP Terraform or Terraform Enterprise and rely on Sentinel policies, private registry, or drift detection.
• Legal has already approved BSL for your use case and sees no benefit in re-reviewing.
• You need Terraform Stacks or ephemeral resources in production today.
• Your team holds HashiCorp certifications and wants to stay on the vendor's official track — see the Terraform Associate certification guide.

Switch to OpenTofu If…

• Your organisation requires OSI-approved open-source licenses for all toolchain components.
• You want client-side state encryption without a third-party wrapper.
• You build or sell platform tooling that embeds the IaC engine.
• You self-host everything on Ubuntu servers and want zero license ambiguity — a common setup in Linux system administration engagements.

Hybrid Approach

Some teams run OpenTofu in application CI pipelines and Terraform Cloud for a central platform team. This works if you enforce strict workspace boundaries. It adds operational overhead. I prefer one engine per organisation unless regulatory walls force a split.

Compare against alternatives in Terraform vs Pulumi vs OpenTofu if you are evaluating more than just the fork. Pulumi uses general-purpose languages. It solves different problems than a HCL migration.

For wrapper tooling, Terragrunt works with both binaries. Pass TF_CLI=true or configure the Terragrunt OpenTofu integration flag depending on your version.

Managed platform options add another axis. Spacelift vs Terraform Cloud compares hosted runners if you want policy gates without self-managing CI. Spacelift supports both Terraform and OpenTofu binaries.

On a production Laravel deployment, IaC often provisions the VPS, DNS, and database — while Deployer handles app releases. I treat the IaC engine choice as infrastructure policy, not application code. Your booking platform infrastructure and your legal-tech sister sites can share one engine decision across pipelines.

Validate JSON state exports with a JSON formatter when debugging state diffs during migration. Small syntax errors in hand-edited state are painful to trace without pretty-printing.

For workspace strategy regardless of engine, read Terraform workspaces and environments. The same patterns apply to OpenTofu workspaces.

External references worth bookmarking: the official OpenTofu migration guide, HashiCorp's BSL license FAQ, and the Linux Foundation announcement of the OpenTofu project.

Key Takeaways

• The fork was triggered by Terraform's August 2023 BSL license change — not by technical failure or a broken CLI.
• HCL modules, providers, and remote state backends remain cross-compatible for standard workloads; migration is a binary swap, not a rewrite.
• OpenTofu adds state encryption and early variable evaluation; Terraform adds ephemeral resources, Stacks, and deeper HCP integration.
• Never run both engines against the same state file — pick one binary per workspace and pin versions in CI.
• Back up remote state before migration and confirm tofu plan shows zero changes before merging the pipeline update.
• Choose OpenTofu for OSI license requirements; stay on Terraform if HCP Terraform Enterprise is your operational backbone.

People Also Ask

Is OpenTofu a drop-in replacement for Terraform?

For most HCL configurations written for Terraform 1.5 through 1.8, yes. Install the OpenTofu binary, run tofu init -upgrade, and confirm a zero-change plan. Configurations using Terraform-only features like ephemeral resources or Stacks need targeted rewrites before switching.

Will HashiCorp stop OpenTofu from using their providers?

As of 2026, HashiCorp providers remain available on the public Terraform Registry and work with OpenTofu. Provider licensing is separate from the CLI license. The OpenTofu project maintains registry mirrors as insurance, but no blocking has occurred in production.

Does the BSL license affect internal company use of Terraform?

Internal infrastructure automation — provisioning your own cloud resources, running CI plans, storing state in your own buckets — is generally permitted under BSL. Restrictions target organisations offering Terraform-as-a-service products competing with HashiCorp. Confirm with your legal team if your use case resembles a hosted platform.

Which tool has better long-term community support?

Both have active 2026 release cycles. OpenTofu has Linux Foundation governance and contributions from Gruntwork, Spacelift, Harness, and others. Terraform has HashiCorp's engineering team and the HCP commercial ecosystem. Neither project appears abandoned; the split is stable and permanent.

Pick One Engine and Pin It

Terraform vs OpenTofu: What Changed boils down to licensing and governance, not a new language. Your modules still compile. Your providers still download. Your state still lives in S3. The decision is whether BSL fits your organisation and whether OpenTofu-specific features like state encryption matter for your security model.

Run a one-workspace pilot this week. Back up state, swap the binary, and read the plan output. That single experiment beats another quarter of debate.

Need help wiring IaC into your deployment pipeline or ongoing infrastructure maintenance? Contact us to review your current setup. For deeper context on the fork itself, read OpenTofu — the open Terraform fork and the broader state management guide on the blog.