OpenTofu vs Terraform 2026: Migration Guide and Feature Comparison

In August 2023, HashiCorp made a decision that split the infrastructure-as-code community: they changed Terraform's license from the Mozilla Public License 2.0 (MPL 2.0) to the Business Source License (BSL 1.1). Within weeks, a fork was announced. That fork became OpenTofu, now a Linux Foundation project under CNCF governance. Boeing, Capital One, and AMD run it in production. This tutorial explains the difference, helps you decide which to use in 2026, and walks through the migration step by step.

The 2023 License Change: MPL 2.0 to BSL

What Changed

Terraform was open source under MPL 2.0 from 2014 until August 10, 2023. MPL 2.0 is a weak copyleft license: you can use the software for any purpose, including commercial, as long as modifications to MPL-licensed files are shared under the same license.

HashiCorp replaced that with the Business Source License 1.1. The BSL is not an open source license by OSI standards. The key restriction:

"You may not use the Licensed Work ... for a Competing Use."

HashiCorp defined "Competing Use" as providing a commercial product or service that allows third parties to manage infrastructure using Terraform or its derivatives. In practical terms: if you are Pulumi, env0, Spacelift, or any company offering a managed Terraform service, you can no longer use Terraform freely. The BSL also converts to a permissive license after four years, but that means Terraform 1.5 will only become freely usable in 2027.

What It Means for Different Users

Individual developers and internal use: The license change has minimal practical impact. You can still use Terraform internally to manage your own infrastructure.

Platform teams and tooling vendors: Significant impact. Any company building a product that runs Terraform on behalf of customers now faces legal risk.

Consulting firms: Grey area. Billing clients for work done using Terraform may or may not constitute a "competing use" — HashiCorp's FAQ has been ambiguous.

The uncertainty itself is the problem. Enterprise procurement and legal teams started flagging Terraform as a risk, which accelerated the move to OpenTofu.

OpenTofu: Origin and Governance

OpenTofu was announced on September 5, 2023, initially as "OpenTF" by a coalition that included Gruntwork, Spacelift, env0, Harness, and others. The Linux Foundation accepted it as a project on September 20, 2023. It joined the Cloud Native Computing Foundation (CNCF) sandbox in 2024 and moved to incubating status later that year.

Who Backs It

• Gruntwork — creators of Terragrunt, the most popular Terraform wrapper
• Spacelift — Terraform/OpenTofu CI/CD platform
• env0 — infrastructure automation platform
• Linux Foundation / CNCF — governance and legal home
• Community contributors — 800+ contributors as of 2026

Governance

OpenTofu uses an RFC-based development process managed by the Technical Steering Committee (TSC). All design decisions are made in public. Releases follow a predictable cadence. The project is deliberately designed so that no single company can control its direction.

Feature Comparison

The most important differentiator is state encryption. Everything else is currently equivalent.

State Encryption: OpenTofu's Biggest Differentiator

Terraform state files contain sensitive data: resource IDs, IP addresses, database passwords, API keys. By default, Terraform state is stored in plaintext. If your S3 bucket or Terraform Cloud workspace is compromised, every secret in your infrastructure is exposed.

OpenTofu added native state encryption in version 1.7. Here is how to configure it:

Basic Configuration with PBKDF2

# main.tf or encryption.tf

terraform {
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      passphrase = var.state_encryption_passphrase
    }

    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    state {
      method = method.aes_gcm.default
    }

    plan {
      method = method.aes_gcm.default
    }
  }
}

Using AWS KMS

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

    method "aes_gcm" "default" {
      keys = key_provider.aws_kms.main
    }

    state {
      method = method.aes_gcm.default
    }
  }
}

Using GCP KMS

terraform {
  encryption {
    key_provider "gcp_kms" "main" {
      kms_encryption_key = "projects/my-project/locations/global/keyRings/my-ring/cryptoKeys/my-key"
      credentials        = file("service-account.json")
    }

    method "aes_gcm" "default" {
      keys = key_provider.gcp_kms.main
    }

    state {
      method = method.aes_gcm.default
    }
  }
}

State encryption applies to both remote state files and local plan files. The encryption is transparent to most workflows — tofu plan and tofu apply decrypt automatically when configured correctly.

Terraform has no equivalent feature. S3 server-side encryption is a partial mitigation but does not protect against application-layer breaches in Terraform Cloud or third-party state backends.

Provider Ecosystem

OpenTofu uses the same provider protocol as Terraform. Every provider that works with Terraform 1.5.x or earlier works with OpenTofu without modification. The OpenTofu registry at registry.opentofu.org mirrors all public Terraform providers and accepts new provider registrations.

In your versions.tf, point to the OpenTofu registry:

terraform {
  required_providers {
    aws = {
      source  = "registry.opentofu.org/hashicorp/aws"
      version = "~> 5.0"
    }
    kubernetes = {
      source  = "registry.opentofu.org/hashicorp/kubernetes"
      version = "~> 2.0"
    }
  }
  required_version = ">= 1.7.0"
}

The source URL change is optional — OpenTofu falls back to the OpenTofu registry automatically when a provider is not found locally. You can leave existing registry.terraform.io source URLs as-is during migration.

Installation

macOS

brew install opentofu
tofu version

Linux (APT)

curl -fsSL https://get.opentofu.org/install-opentofu.sh | sudo bash -s -- --install-method apt
tofu version

Linux (Binary)

VERSION="1.9.0"
curl -LO "https://github.com/opentofu/opentofu/releases/download/v${VERSION}/tofu_${VERSION}_linux_amd64.zip"
unzip tofu_${VERSION}_linux_amd64.zip
sudo mv tofu /usr/local/bin/
tofu version

Windows (Chocolatey)

choco install opentofu
tofu version

The binary is called tofu, not terraform. That is the only CLI change.

Migration: Existing Terraform Project to OpenTofu in One PR

The migration is genuinely simple. OpenTofu is a drop-in replacement for Terraform 1.5.x and below.

Step 1: Install OpenTofu

Install tofu on your local machine and in CI (see above).

Step 2: Verify Your Terraform Version

OpenTofu is fully compatible with Terraform up to and including 1.5.x. Terraform 1.6+ introduced the BSL and features specific to Terraform Cloud that have no OpenTofu equivalent. If you are on 1.5.x or below, proceed directly. If you are on 1.6 or 1.7, audit your code for Terraform Cloud-specific features like cloud {} blocks before migrating.

terraform version
# Terraform v1.5.7

Step 3: Initialize with OpenTofu

# In your existing project directory
tofu init

OpenTofu reads your existing terraform.tfstate, .terraform.lock.hcl, and provider configuration. No state migration is needed.

Step 4: Verify the Plan Matches

tofu plan

The plan output should be identical to what terraform plan produced. If there are differences, review them — they are almost certainly cosmetic (different formatting or provider version resolution).

Step 5: Update CI/CD

This is the one-line change. In your CI configuration, replace:

terraform init && terraform plan && terraform apply

with:

tofu init && tofu plan && tofu apply

Step 6: Update versions.tf

Update the required_version constraint:

terraform {
  required_version = ">= 1.7.0"   # OpenTofu version
  # ...
}

The terraform {} block name stays as-is. OpenTofu reads it correctly.

CI/CD Updates

GitHub Actions

name: OpenTofu

on:
  push:
    branches: [main]
  pull_request:

jobs:
  tofu:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

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

      - name: OpenTofu Init
        run: tofu init
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

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

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

Replace hashicorp/setup-terraform with opentofu/setup-opentofu. Everything else stays the same.

GitLab CI

variables:
  TOFU_VERSION: "1.9.0"

image: alpine:3.20

before_script:
  - apk add --no-cache curl unzip
  - curl -LO "https://github.com/opentofu/opentofu/releases/download/v${TOFU_VERSION}/tofu_${TOFU_VERSION}_linux_amd64.zip"
  - unzip tofu_${TOFU_VERSION}_linux_amd64.zip -d /usr/local/bin/
  - tofu version

plan:
  stage: plan
  script:
    - tofu init
    - tofu plan -out=tfplan
  artifacts:
    paths:
      - tfplan

apply:
  stage: apply
  script:
    - tofu init
    - tofu apply tfplan
  when: manual
  only:
    - main

Who Has Already Moved

The migration to OpenTofu has been broad and fast:

• Gruntwork — migrated Terragrunt to be OpenTofu-first. Their modules and documentation default to OpenTofu.
• Spacelift — supports both but recommends OpenTofu for new customers.
• env0 — fully migrated their platform to OpenTofu.
• Scalr — OpenTofu-first since early 2024.
• Boeing — uses OpenTofu for internal cloud infrastructure automation.
• Capital One — cited license compliance as the driver for switching.
• AMD — migrated infrastructure pipelines to OpenTofu in 2024.

The general pattern: companies with active legal and procurement review switched early. Companies with smaller teams and no compliance requirements often have not switched yet but face no technical barrier to doing so.

Pulumi as a Third Option

If you are evaluating infrastructure-as-code tooling from scratch, Pulumi is worth considering. Rather than using HCL (HashiCorp Configuration Language), Pulumi lets you write infrastructure code in TypeScript, Python, Go, Java, or .NET.

// Pulumi TypeScript example
import * as aws from "@pulumi/aws";

const bucket = new aws.s3.Bucket("my-bucket", {
    acl: "private",
    tags: { Environment: "production" },
});

export const bucketName = bucket.id;

Pulumi's license is Apache 2.0 for the CLI and SDKs. The state backend can be Pulumi Cloud (commercial) or self-hosted. If your team already writes TypeScript or Python and finds HCL awkward, Pulumi is worth evaluating. However, the provider ecosystem is smaller than OpenTofu/Terraform, and the community knowledge base (Stack Overflow, blog posts, modules) is less extensive.

Decision Framework for New Projects in 2026

Use this framework when starting a new project:

Choose OpenTofu if:

• You need a fully open source license (MPL 2.0) with no commercial restrictions
• You want state encryption without external tooling
• Your organization has legal/compliance requirements around BSL software
• You want CNCF-backed governance with a predictable roadmap
• Your team already knows HCL / Terraform syntax (zero learning curve)
• You use Gruntwork, Spacelift, env0, or other OpenTofu-native platforms

Choose Terraform if:

• You are already on Terraform and have no compliance concerns about BSL
• You need features specific to Terraform Cloud (Stacks, native drift detection in the managed product)
• Your organization has existing Terraform Cloud contracts
• You use HashiCorp Vault, Consul, or Nomad with tight integration expectations

Choose Pulumi if:

• Your team finds HCL limiting and prefers a general-purpose language
• You are building complex infrastructure logic that benefits from real programming constructs (loops, functions, classes)
• You are starting fresh with no existing HCL investment

For most teams starting a new project in 2026, OpenTofu is the right default. It has the same syntax as Terraform, the same provider ecosystem, better state security, and no license uncertainty.

Summary

The 2023 license change created a clear fork in the infrastructure-as-code world. Terraform remains a capable tool but comes with BSL restrictions that create legal uncertainty for many organizations. OpenTofu provides a fully open source alternative with the same HCL syntax, the same provider ecosystem, and a meaningful new feature: native state encryption.

Migration from Terraform to OpenTofu is a one-line change in CI. The technical cost is minimal. The benefit is long-term certainty: OpenTofu will remain open source under CNCF governance regardless of what any single company decides.

# Try it now
brew install opentofu
cd your-terraform-project
tofu init
tofu plan

If the plan looks correct, you have migrated.