Terraform vs OpenTofu 2026: Which One Should Your Team Use?

When HashiCorp changed Terraform’s license in August 2023, it forced a reckoning across the infrastructure-as-code community. The shift to the Business Source License (BSL) sent shockwaves through organizations that had built their entire cloud strategy around Terraform’s open-source model. That decision also accelerated the emergence of OpenTofu as a serious, production-ready alternative.

Fast forward to 2026, and you’re probably asking yourself: do I care anymore? The answer depends on your team’s constraints and ambitions. I’ve migrated two teams away from Terraform since the fork, and another team that’s stuck with HCP Terraform for specific workflow reasons. Both decisions were right for their contexts. Let me walk you through what changed and how to decide which tool actually serves your team best.

What the License Change Actually Meant

The Business Source License on Terraform (starting with 1.5.x in August 2023) restricts commercial use for four years. If you’re a competitor offering managed Terraform services, you can’t deploy Terraform to your customers without a commercial license. For everyone else—internal infrastructure teams, consulting firms, startups on AWS—it doesn’t practically matter. You can still use Terraform for free.

But perception became reality. The moment an open-source project closes, contributors leave. Development slows. Maintainers stop feeling like owners of something shared and start feeling like employees. The Linux Foundation’s OpenTofu, created initially by Openshift and other major players, offered an escape hatch.

Terraform 1.5.x was the last version released under the Mozilla Public License. Everything after that lives under BSL.

OpenTofu’s Journey to 1.9

OpenTofu forked from Terraform 1.5.0 in September 2023 and has been playing catch-up ever since. The Linux Foundation maintains it now, with governance that includes independent contributors, cloud vendors, and end users on the steering committee.

By early 2026, OpenTofu sits at version 1.9.x. That’s not behind Terraform (which is in the 1.7–1.8 range depending on release schedule), it’s roughly parallel. More importantly, OpenTofu has added features that Terraform hasn’t, and it’s moving at a different pace in some areas.

The provider ecosystem matters here. Terraform has providers living in the Terraform Registry (registry.terraform.io). OpenTofu has its own registry at registry.opentofu.org, but—and this is critical—it pulls from the same upstream providers that Terraform does. If a provider works on Terraform, it works on OpenTofu. State files are identical. The .tfstate format hasn’t diverged, so moving between them is genuinely a drop-in replacement at the file level.

Feature Differences in 2026

OpenTofu 1.8 shipped with provider-defined functions, letting provider authors write custom functions that you can call directly in your configurations. It also tightened loop syntax to avoid a lot of the cognitive overhead that comes with nested for_each statements. Small wins, but they add up.

OpenTofu 1.9 added something Terraform teams have been asking for since Terraform 0.12: variables in provider configurations. Previously, you had to put provider configuration in terraform.tfvars and hope no one manually edited a backend or provider block. Now you can write:

variable "aws_region" {
  type    = string
  default = "us-east-1"
}

provider "aws" {
  region = var.aws_region
}

Simple. But Terraform still doesn’t support this natively. If you’re managing a platform where teams pass in their own region or assume role, that variable in the provider config cuts down on boilerplate and reduces configuration errors.

Terraform Enterprise and HCP Terraform are where Terraform pulls ahead. If you’re using the cloud backend with Sentinel policies, team management, cost estimation, and full audit trails, Terraform Enterprise is mature and deeply integrated. OpenTofu has no equivalent. You’re using S3 backends, Consul, or other remote state stores. For some teams, that’s perfectly fine. For teams running security-sensitive infrastructure where you need organization-level policy enforcement and compliance auditing, HCP Terraform is still the answer.

HashiCorp also maintains tighter backward compatibility than OpenTofu. If you’re running a large Terraform estate with hundreds of modules, you’re probably more confident upgrading OpenTofu—the Linux Foundation treats major version breaks seriously. Terraform changes behavior more frequently within minor versions.

State Files and Drop-In Replacement

The .tfstate file format is unchanged. If you’re moving from Terraform to OpenTofu, you can literally replace the binary and run tofu init. Your state is valid. Your modules work. Provider source blocks are compatible as long as you point to the right registry.

Where you might hit friction is if you’re using HashiCorp’s Terraform Cloud backend. HCP Terraform won’t recognize an OpenTofu client by default—you’ll need to self-host state. That’s another advantage of running Terraform OSS: you’re probably already using S3 with a locking DynamoDB table, or Consul, or some other backend. The migration becomes trivial.

How to Actually Migrate

If you decide to move from Terraform to OpenTofu, here’s the real workflow:

# Install OpenTofu (or replace terraform binary if you prefer)
# On macOS: brew install opentofu
# On Linux: download from releases.opentofu.org

# Navigate to your infrastructure repo
cd ~/infrastructure

# Initialize with OpenTofu
# This reads your existing state, verifies provider locks
tofu init

# Plan to ensure everything loads
tofu plan

# That's usually it. If you had manual provider selections or special flags,
# migrate those to your backend or variable files.

If you’re using HCP Terraform, you need one more step:

# Remove the cloud block from your terraform block
# or comment it out
# Then set backend to S3 (or your self-hosted backend)

terraform {
  backend "s3" {
    bucket         = "my-tfstate"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

# Migrate your state
tofu init  # It will detect existing state and migrate

# Verify
tofu state list

The scary part is usually just in people’s heads. State migration is safe because OpenTofu reads the existing state, validates it, and applies it. If something’s broken, tofu plan shows you before you apply.

CI/CD Integration: GitLab and GitHub

This is where the rubber meets the road. Your pipeline needs to invoke OpenTofu instead of Terraform.

Here’s a GitLab CI pipeline that runs OpenTofu for a typical AWS infrastructure:

stages:
  - init
  - plan
  - apply

variables:
  AWS_DEFAULT_REGION: "us-east-1"
  TF_ROOT: "${CI_PROJECT_DIR}/infrastructure"
  TOFU_VERSION: "1.9.2"

before_script:
  - cd $TF_ROOT
  - which tofu || (curl -fsSL https://get.opentofu.org/install-linux.sh | sh)

init:
  stage: init
  script:
    - tofu init
  artifacts:
    paths:
      - $TF_ROOT/.terraform
    expire_in: 1 day

plan:
  stage: plan
  script:
    - tofu plan -out=tfplan
  artifacts:
    paths:
      - $TF_ROOT/tfplan
    expire_in: 7 days
  only:
    - merge_requests

apply:
  stage: apply
  script:
    - tofu apply -auto-approve tfplan
  artifacts:
    paths:
      - $TF_ROOT/.terraform.lock.hcl
  only:
    - main
  environment:
    name: production
    action: prepare

For GitHub Actions, the pattern is similar. You’d use the official OpenTofu action or install it directly:

name: OpenTofu Plan

on:
  pull_request:
    paths:
      - 'infrastructure/**'

jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Install OpenTofu
        uses: opentofu/setup-opentofu@v1
        with:
          tofu_version: 1.9.2
      
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::$:role/GitHubActionsRole
          aws-region: us-east-1
      
      - name: OpenTofu Init
        run: tofu init
        working-directory: ./infrastructure
      
      - name: OpenTofu Plan
        run: tofu plan -no-color
        working-directory: ./infrastructure
        
      - name: Comment on PR
        uses: actions/github-script@v7
        with:
          github-token: $
          script: |
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: 'OpenTofu plan completed. Review above.'
            })

Both approaches work identically to Terraform. The only real difference is the binary name and where you pull it from. If you’re running self-hosted runners on AWS—say, in an autoscaling GitLab CI setup on Fargate—you just swap the installation source and move on.

Provider Configuration with Variables (OpenTofu 1.9)

Here’s what OpenTofu 1.9 enables that Terraform still can’t do:

variable "assume_role_arn" {
  type    = string
  default = ""
}

variable "aws_region" {
  type    = string
  default = "us-east-1"
}

provider "aws" {
  region = var.aws_region

  dynamic "assume_role" {
    for_each = var.assume_role_arn != "" ? [var.assume_role_arn] : []
    content {
      role_arn = assume_role.value
    }
  }
}

This pattern lets you write a single module that different teams consume with different regions and roles. In Terraform, you’re forced to use -var on the command line or environment variables. It works, but it’s less declarative.

Backend Configuration (Identical for Both)

Your S3 backend works unchanged:

terraform {
  backend "s3" {
    bucket         = "org-tfstate-prod"
    key            = "production/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }

  # Lock DynamoDB table must have a primary key named "LockID"
  # Terraform and OpenTofu both use the same lock structure
}

This is one of the genuinely nice parts of switching. Your state backend format is identical. No migration needed beyond changing the binary.

When Terraform Is Still the Right Answer

Pick Terraform if:

Your team uses HCP Terraform with Sentinel policies and organization-level enforcement. The cloud backend gives you cost estimation, policy as code, and team collaboration features that OpenTofu can’t replicate without significant engineering effort.

You have a support contract with HashiCorp. This matters if you’re running Terraform at enterprise scale and need paid technical support for unusual issues.

You’re heavily invested in Terraform Cloud’s workflow. Cost estimation, state locking, team management, and run history all live in HCP Terraform. Migrating that to a self-hosted backend means losing some operational convenience.

You need the exact HashiCorp integration story. Terraform integrates more tightly with Vault, Consul, and other HashiCorp products. If your organization runs that stack, the integration is seamless.

When OpenTofu Is Clearly Better

Pick OpenTofu if you’re running Terraform OSS anyway and self-hosting state. You’re already handling team access control, state locking, and everything else yourself. OpenTofu adds variables in provider configs, provider-defined functions, and tighter loop syntax without asking for anything in return.

Pick OpenTofu if your organization has an open-source mandate. Using a Linux Foundation project instead of a vendor-licensed tool makes compliance simpler.

Pick OpenTofu if you care about governance and decision-making transparency. OpenTofu has a technical steering committee that includes independent contributors, not just the project creators. Decisions happen in the open. That matters for teams worried about a tool’s long-term direction.

Pick OpenTofu if you want faster iteration on features that matter to your use case. The Linux Foundation moves quicker on certain request types. Provider variables came through the community pressure. It worked.

Migration Timing

Here’s my honest take: if you’re on Terraform 1.4.x or earlier, you’re probably running the MPL version anyway. The fork didn’t affect you. But when you’re ready to upgrade, seriously consider jumping to OpenTofu. Your state is portable. Your modules work. You get all the infrastructure without the licensing conversation.

If you’re already on Terraform 1.5+ (BSL), you’re not locked in. The migration takes a day for most teams. Document your backend, test a non-critical environment, then roll it out to prod. The risk is lower than upgrading Terraform itself, which you probably do yearly anyway.

The fork was the right call from the community’s perspective. It preserved an open-source IaC tool at a moment when the commercial pressure threatened to kill it. Four years later, both tools are healthy. Terraform has its niche with HCP Terraform customers. OpenTofu serves everyone else.

Your team’s decision comes down to one question: do you need what Terraform Enterprise sells, or are you comfortable with open-source infrastructure and self-hosted state? If it’s the latter, OpenTofu is simply the better choice. Faster features, smaller governance footprint, and no licensing ambiguity.