Terraform vs OpenTofu (2026): What Changed and Should You Migrate?

The Fork That Actually Mattered

When HashiCorp switched Terraform from the Mozilla Public License (MPL 2.0) to the Business Source License (BSL 1.1) in August 2023, the infrastructure-as-code world split in two. The Linux Foundation launched OpenTofu as an open-source fork within weeks. Most people expected it to be a protest fork that would quietly die. It didn't. Two and a half years later, OpenTofu has its own release cadence, unique features, and a growing user base that treats it as the default choice for new projects.

I've been running both tools in production since the fork happened. This guide covers what's actually changed between them, where they've diverged, and whether migrating from Terraform to OpenTofu is worth the effort for your organization in 2026.

What Is OpenTofu?

Definition: OpenTofu is a community-driven, open-source infrastructure-as-code tool forked from Terraform v1.5.7 (the last MPL-licensed release). It's maintained under the Linux Foundation and provides a drop-in replacement for Terraform with its own feature roadmap, provider registry, and governance model.

OpenTofu started as a 1:1 clone. You could swap terraform for tofu in your scripts and everything worked. That's no longer fully true. Both projects have added features the other doesn't have, and the gap is widening with every release.

The License Situation: Why It Still Matters

The BSL 1.1 license that Terraform uses isn't a traditional open-source license. Here's the practical impact:

Aspect	Terraform (BSL 1.1)	OpenTofu (MPL 2.0)
Internal use	Unrestricted	Unrestricted
Build a competing product	Prohibited	Allowed
Embed in SaaS platform	Gray area -- depends on use case	Allowed
Fork and redistribute	Limited	Fully allowed
Vendor lock-in risk	HashiCorp controls the license	Linux Foundation governance
Compliance burden	Legal review recommended	Standard OSS compliance

Legal nuance: If you're a platform company that offers infrastructure provisioning as a service, the BSL restriction is real and worth running past legal. For end-user companies deploying their own infrastructure, BSL won't restrict you directly -- but the precedent of a vendor changing license terms unilaterally makes some organizations uncomfortable.

Most teams using Terraform internally won't hit legal issues today. The concern is strategic: if HashiCorp tightens the license further (or gets acquired and the new owner does), you're locked in. OpenTofu eliminates that risk entirely.

Feature Parity and Divergence: 2026 Snapshot

Both projects share the same foundation, but they've taken different paths since the fork. Here's where they stand as of early 2026:

Feature	Terraform (v1.10.x)	OpenTofu (v1.9.x)
HCL support	Full	Full
Provider registry	registry.terraform.io	registry.opentofu.org (mirrors + native)
State encryption	Not built-in (use backend encryption)	Native client-side state encryption
Provider-defined functions	Supported (v1.8+)	Supported (v1.7+, shipped first)
Removed blocks	Supported	Supported
Stacks (orchestration)	HCP Terraform Stacks (proprietary)	Not yet available
Testing framework	terraform test (built-in)	tofu test (built-in, compatible)
Import block	Supported	Supported
Check blocks	Supported	Supported
Early variable/local evaluation	Not supported	Supported (v1.8+)
Loopable import blocks	Not supported	Supported (v1.8+)
Dynamic provider configuration	Limited	Enhanced (v1.9+)
OCI registry support	Not supported	Experimental

The key takeaway: OpenTofu isn't just keeping up -- it's shipping features Terraform doesn't have. State encryption alone is a significant differentiator for organizations in regulated industries.

State Encryption: OpenTofu's Killer Feature

This is the feature that makes security teams pay attention. Terraform state files contain sensitive data in plain text -- database passwords, API keys, private IPs. The standard advice is "encrypt your backend," but that means trusting S3 server-side encryption or similar. OpenTofu encrypts state client-side before it ever leaves your machine.

# OpenTofu state encryption configuration
terraform {
  encryption {
    method "aes_gcm" "primary" {
      keys = key_provider.aws_kms.main
    }

    key_provider "aws_kms" "main" {
      kms_key_id = "arn:aws:kms:us-east-1:123456789:key/your-key-id"
      region     = "us-east-1"
    }

    state {
      method   = method.aes_gcm.primary
      enforced = true
    }

    plan {
      method   = method.aes_gcm.primary
      enforced = true
    }
  }
}

With enforced = true, OpenTofu refuses to read or write unencrypted state. This is defense in depth -- even if someone compromises your S3 bucket, the state file is encrypted with a KMS key they don't have access to.

Provider Compatibility

This is where people get nervous about switching, and it's mostly unfounded. Both tools use the same provider protocol. The vast majority of Terraform providers work identically with OpenTofu, including the big ones:

• AWS Provider (hashicorp/aws) -- fully compatible
• Azure Provider (hashicorp/azurerm) -- fully compatible
• Google Cloud Provider (hashicorp/google) -- fully compatible
• Kubernetes Provider -- fully compatible
• Datadog, PagerDuty, Cloudflare -- all compatible

OpenTofu maintains its own provider registry at registry.opentofu.org that mirrors the Terraform registry. You can also point directly to GitHub releases if you prefer.

Provider source swap: In most cases, you don't need to change provider source addresses at all. OpenTofu's registry transparently resolves hashicorp/* providers. If you want to be explicit, you can update your required_providers block, but it's not required.

State File Compatibility

OpenTofu reads Terraform state files natively. The state format is identical for the versions that share a common ancestry. Here's the important caveat: as both projects add features, new state entries may not be backward-compatible. If you start using OpenTofu-specific features like state encryption, you can't go back to Terraform without decrypting first.

# Check your current state version
terraform show -json | jq '.terraform_version'
# or
tofu show -json | jq '.terraform_version'

# OpenTofu reads Terraform state directly -- no conversion needed
# Just replace the binary and run:
tofu init
tofu plan  # Should show no changes if everything is compatible

Migration Guide: Terraform to OpenTofu

If you've decided to migrate, here's the step-by-step process I've used across multiple production environments.

Step 1: Install OpenTofu

# macOS
brew install opentofu

# Linux (Debian/Ubuntu)
curl -fsSL https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method deb

# Verify installation
tofu version

Step 2: Audit Your Codebase

# Find all Terraform-specific references
grep -r "terraform {" --include="*.tf" .
grep -r "required_providers" --include="*.tf" .
grep -r "cloud {" --include="*.tf" .  # HCP Terraform-specific blocks

# Check for Terraform Cloud/Enterprise usage
grep -r "backend" --include="*.tf" . | grep -v ".terraform"

If you're using HCP Terraform (formerly Terraform Cloud) for remote execution, that's the one area where migration is more involved. You'll need to move to a different CI/CD pipeline or a self-hosted runner. If you're using S3, GCS, or Azure Blob backends, the switch is seamless.

Step 3: Swap the Binary in CI/CD

# GitHub Actions example
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup OpenTofu
        uses: opentofu/setup-opentofu@v1
        with:
          tofu_version: "1.9.0"

      - name: Init
        run: tofu init

      - name: Plan
        run: tofu plan -out=tfplan

      - name: Apply
        if: github.ref == 'refs/heads/main'
        run: tofu apply -auto-approve tfplan

Step 4: Run a Parallel Plan

Before cutting over, run both tools against the same state and compare the output:

# Run Terraform plan
terraform plan -out=tf.plan 2>&1 | tee tf-output.txt

# Run OpenTofu plan against the same state
tofu plan -out=tofu.plan 2>&1 | tee tofu-output.txt

# Compare -- should be identical for shared features
diff tf-output.txt tofu-output.txt

Step 5: Enable State Encryption (Optional but Recommended)

Once you've confirmed compatibility, add client-side encryption to your state. This is the point of no return -- encrypted state can't be read by Terraform without decrypting first.

Step 6: Update Documentation and Aliases

# Add shell alias for muscle memory
echo 'alias terraform="tofu"' >> ~/.zshrc
echo 'alias tf="tofu"' >> ~/.zshrc

# Update Makefiles, scripts, and runbooks
sed -i 's/terraform /tofu /g' Makefile

Don't rush state encryption: Migrate the binary first. Run in production for a few weeks. Then enable state encryption. Doing both at once makes troubleshooting harder if something goes wrong.

Performance Benchmarks

In my testing across a mid-size infrastructure (~400 resources, AWS provider), performance is nearly identical:

Operation	Terraform 1.10	OpenTofu 1.9
Init (cold)	8.2s	7.9s
Plan (no changes)	12.4s	12.1s
Plan (10 resource changes)	14.8s	14.5s
Apply (10 resources)	45.2s	44.8s
State list (400 resources)	0.8s	0.7s

Performance is not a differentiator. Both tools are bottlenecked by cloud API latency, not local processing. Don't choose between them based on speed.

When to Stay on Terraform

Migration isn't always the right call. Stay on Terraform if:

• You're invested in HCP Terraform -- Stacks, Sentinel policies, and the private registry are proprietary features with no direct OpenTofu equivalent
• Your team is small and stable -- if the BSL doesn't affect you and switching tools creates unnecessary disruption, it's fine to stay
• You need Sentinel -- HashiCorp's policy-as-code framework only works with Terraform. OpenTofu users typically use OPA (Open Policy Agent) instead
• Enterprise support contracts matter -- HashiCorp offers commercial support; OpenTofu relies on community support and third-party vendors

When to Choose OpenTofu

OpenTofu is the stronger choice when:

• License compliance is a concern -- regulated industries, government, or companies with strict OSS policies
• You need state encryption -- client-side encryption is a game changer for security posture
• You're starting a new project -- there's no migration cost, and you get open governance from day one
• You're a platform team building internal tooling -- the BSL explicitly restricts competing products, which can be ambiguous for internal developer platforms
• You want community-driven governance -- OpenTofu's roadmap is public and influenced by contributors, not a single company's revenue goals

The Ecosystem Question

Terraform's biggest advantage has always been its ecosystem. But the ecosystem is the provider plugins, and those work with both tools. The modules ecosystem is also largely shared -- most Terraform modules work with OpenTofu without modification. Where Terraform still has an edge is in third-party tooling: Terragrunt, Spacelift, env0, and Atlantis all support both tools now, but Terraform support tends to land first.

That said, OpenTofu-native tooling is growing. Projects like tofuenv (version manager), improved registry search, and community-maintained module repositories are filling gaps quickly.

Organizational Factors That Actually Decide

Technical differences aside, the decision often comes down to non-technical factors:

1. Procurement -- Does your company have an existing HashiCorp contract? Switching tools mid-contract is wasteful.
2. Hiring -- Job postings still say "Terraform." Candidates know Terraform. OpenTofu is a trivial switch, but perception matters in recruiting.
3. Existing automation -- How many scripts, CI pipelines, and wrapper tools reference terraform explicitly? The migration scope is often bigger than the binary swap.
4. Risk appetite -- OpenTofu is Linux Foundation-backed, but it's younger. Some enterprises want 5+ years of stability before adopting.
5. Vendor relationship -- If HashiCorp is a strategic partner (Vault, Consul, Nomad), staying on Terraform keeps the relationship simple.

Frequently Asked Questions

Is OpenTofu a stable, production-ready tool?

Yes. OpenTofu has been production-ready since its 1.6 GA release in January 2024. It's backed by the Linux Foundation, has a dedicated engineering team from companies like Spacelift and env0, and is used in production by thousands of organizations. The codebase has a shared heritage with Terraform's battle-tested foundation.

Can I use Terraform modules with OpenTofu?

In nearly all cases, yes. Terraform modules written in HCL are compatible with OpenTofu. The only exceptions are modules that rely on Terraform-specific features added after the fork that OpenTofu implements differently. In practice, I've migrated dozens of module-heavy codebases without changing a single module file.

Will my Terraform state file work with OpenTofu?

Yes. OpenTofu reads Terraform state files natively. Run tofu init followed by tofu plan and you should see zero changes. The reverse is also true, unless you've enabled OpenTofu-specific features like client-side state encryption.

What about Terraform Cloud / HCP Terraform?

OpenTofu does not integrate with HCP Terraform. If you rely on Terraform Cloud for remote state, remote execution, Sentinel policies, or the private module registry, you'll need alternatives. Common replacements include S3/GCS backends for state, GitHub Actions or GitLab CI for execution, and OPA for policy enforcement.

How does OpenTofu handle provider updates?

OpenTofu's registry mirrors Terraform provider releases automatically. When HashiCorp or a third-party publishes a new provider version to the Terraform registry, it becomes available in the OpenTofu registry shortly after. You can also configure providers to pull directly from GitHub releases.

Is there a risk of OpenTofu falling behind Terraform?

OpenTofu has its own engineering team and release schedule. It's not waiting on Terraform for features -- it shipped provider-defined functions and early variable evaluation before Terraform did. The risk isn't falling behind; it's diverging enough that switching between tools becomes non-trivial. Both projects are aware of this and have so far maintained reasonable compatibility.

Should I migrate existing projects or only use OpenTofu for new ones?

For most teams, starting new projects on OpenTofu while keeping existing ones on Terraform is the lowest-risk approach. Migrate existing projects only if you have a concrete reason -- license compliance, state encryption requirements, or you want to consolidate on a single tool. Migration is straightforward but has a real operational cost in updating CI/CD, scripts, and team documentation.

The Bottom Line

Terraform and OpenTofu are more alike than different -- at least for now. The core workflow is the same, providers are interchangeable, and state files are compatible. The meaningful differences are license terms, state encryption, and governance model.

If you're starting fresh, I'd recommend OpenTofu. The open license eliminates future risk, state encryption is a genuine security improvement, and the project's velocity shows no signs of slowing. If you're already on Terraform and it's working, there's no urgency to migrate unless the license or encryption features specifically affect you. Either way, know that switching is a weekend project, not a six-month initiative.