Terraform vs OpenTofu 2026: License, Features, Migration

In August 2023, HashiCorp changed Terraform’s license from MPL 2.0 to BSL 1.1. The community forked it as OpenTofu under the Linux Foundation. Two years later, both projects have diverged. Here is where they stand.

The license issue

Terraform (BSL 1.1): You can use Terraform freely for internal infrastructure. You cannot build competing commercial products on top of it. This affects:

• Companies building IaC platforms that compete with Terraform Cloud
• Managed service providers offering Terraform-as-a-Service
• Tool vendors embedding Terraform in commercial products

OpenTofu (MPL 2.0): Fully open source. No restrictions on commercial use. You can build anything on top of it.

For most end users (using Terraform to manage your own infrastructure), the BSL license has zero practical impact. The license matters if you are a vendor building products around Terraform.

Feature comparison (2026)

Where OpenTofu has diverged

State encryption (OpenTofu only)

OpenTofu encrypts state files at rest — a feature the community requested for years:

# OpenTofu state encryption
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
    }
  }
}

With Terraform, you rely on S3 server-side encryption or Vault — the state file itself is plaintext. OpenTofu encrypts before writing, so even your storage backend cannot read it.

Dynamic provider configuration

# OpenTofu: for_each on providers
provider "aws" {
  for_each = var.regions
  region   = each.value
}

resource "aws_vpc" "main" {
  for_each = var.regions
  provider = aws[each.key]
  cidr_block = "10.0.0.0/16"
}

This eliminates the need for provider aliases when managing resources across multiple regions or accounts.

Migration from Terraform to OpenTofu

The migration is straightforward because OpenTofu maintains HCL compatibility:

# 1. Install OpenTofu
brew install opentofu

# 2. In your existing Terraform project:
tofu init          # Downloads same providers
tofu plan          # Same plan output
tofu apply         # Same apply behavior

# 3. State is compatible — no migration needed
# Your existing .tfstate files work as-is

What to watch:

• Provider versions: Both use the same providers, but pin versions to avoid surprises
• Backend configuration: S3, GCS, Azure backends work identically
• CI/CD: Replace terraform with tofu in your pipeline scripts
• Terraform Cloud: Does not work with OpenTofu — use env0, Spacelift, or Scalr

Decision guide

Stay with Terraform when:

• You use Terraform Cloud/Enterprise and its features (Sentinel, cost estimation, VCS integration)
• The BSL license does not affect your use case (most internal teams)
• You want Stacks for multi-deployment orchestration
• Your organization has HashiCorp enterprise agreements
• Team training and documentation references Terraform specifically

Switch to OpenTofu when:

• You need state encryption built into the tool
• The BSL license affects your business (you are a vendor or MSP)
• You prefer open-source governance under the Linux Foundation
• You want dynamic provider configuration (for_each on providers)
• You want to reduce vendor lock-in risk
• Your organization has a policy against non-open-source infrastructure tools

The pragmatic view

For most teams managing their own cloud infrastructure, both tools produce identical results. The code is compatible, the providers are the same, and the workflow is identical. Choose based on your organization’s stance on licensing and whether you need OpenTofu’s unique features (state encryption, dynamic providers).

Related

• Crossplane vs Terraform 2026
• Terraform vs Pulumi 2026
• Terraform Cheat Sheet
• Internal Developer Platforms 2026
• ArgoCD vs Flux 2026