Why Teams Are Migrating from Terraform to OpenTofu in 2026

The Infrastructure-as-Code market hit $2.1 billion in 2026 with 28.2% annual growth, driven by platform engineering adoption reaching 80% of large enterprises. Within that market, Terraform’s BSL license change triggered a migration wave that continues in 2026. The practical driver is not ideological: teams building SaaS platforms, internal developer portals, or tooling that competes with HashiCorp products face real legal exposure under BSL. The restriction prohibits using Terraform to build products that compete with HashiCorp offerings — a definition that is broadly interpreted enough to create compliance risk for many commercial applications. Enterprise adopters of OpenTofu include Boeing, Capital One, and AMD, driven primarily by license compliance requirements and OpenTofu’s native state encryption feature that regulated industries need. OpenTofu has 12% adoption among IaC practitioners as of April 2026, with 27% of teams planning to evaluate or expand its use in the next 12 months. For teams whose legal counsel flags BSL risk, or who need features like native state encryption that Terraform still lacks, migration to OpenTofu is increasingly the straightforward compliance decision.

OpenTofu vs Terraform: Technical Feature Comparison

OpenTofu and Terraform share the same HCL configuration language, state file format (JSON, compatible with Terraform 1.5.x), and provider ecosystem — the vast majority of Terraform Registry providers work with OpenTofu’s registry at registry.opentofu.org. The technical divergence has accelerated in 2026 as OpenTofu develops features that HashiCorp has not shipped in Terraform. OpenTofu 1.9 delivered provider iteration using for_each on provider blocks and the -exclude flag for targeted plan/apply operations, directly reducing code duplication in multi-region and multi-account deployments. Native state encryption is OpenTofu’s most significant security differentiator: Terraform requires external key management workarounds (AWS KMS wrappers, custom backends) to encrypt state files at rest, while OpenTofu encrypts state natively using configurable key providers including AES-GCM and PBKDF2. Dynamic backend configuration variables, also absent in Terraform, allow environment-specific backend configurations without wrapper scripts. The feature gap in OpenTofu’s favor is widening, not narrowing, as the project’s 140+ corporate backers drive a release cadence that Terraform under BSL cannot match commercially.

License Deep Dive — BSL vs MPL 2.0: What It Actually Means for Your Team

HashiCorp changed Terraform’s license from MPL 2.0 to the Business Source License (BSL) 1.1 in August 2023, triggering the OpenTofu fork that was formally accepted into the Linux Foundation. The BSL restriction that matters most for developers is Section 1.1: you may not use the software to provide a “competitive service” — defined as any managed or hosted service that lets third parties access the software’s functionality. In practice, this affects teams building: internal developer platforms that expose Terraform-like provisioning APIs to internal teams (arguably competitive with HCP Terraform), SaaS products that include infrastructure provisioning as a feature, and consulting tooling or automation products that wrap Terraform and sell it as a service. The restriction does not affect teams using Terraform purely for their own infrastructure management. MPL 2.0, which OpenTofu uses, imposes no such commercial restriction — it requires only that modifications to the MPL-licensed code itself be open-sourced, not that products built with it be restricted. For regulated industries including financial services, defense, and government, the CNCF/Linux Foundation stewardship of OpenTofu also provides a more stable governance model than a single commercial vendor controlling license terms.

Step-by-Step Migration Guide: Terraform to OpenTofu (Zero Downtime)

OpenTofu uses the same state file JSON format as Terraform 1.5.x, which means migration does not require any state conversion — you point the new binary at the existing state and run. The migration is reversible at any point before you use OpenTofu-specific features. The recommended approach is to migrate projects individually, starting with non-production environments, before touching production state.

Step 1: Install OpenTofu

# macOS
brew install opentofu

# Linux (latest binary)
curl -fsSL https://get.opentofu.org/install-opentofu.sh | sudo bash

# Verify
tofu version
# OpenTofu v1.9.x

Step 2: Back up existing Terraform state

# For local state
cp terraform.tfstate terraform.tfstate.backup

# For remote state (S3 example)
aws s3 cp s3://my-tfstate-bucket/prod/terraform.tfstate \
  s3://my-tfstate-bucket/prod/terraform.tfstate.backup

# Export full state as JSON for disaster recovery
terraform show -json > pre-migration-state.json

Step 3: Initialize OpenTofu on existing configuration

# In your existing Terraform project directory
tofu init

# OpenTofu reads terraform.tfstate and .terraform.lock.hcl directly
# No conversion needed — the state format is compatible

Step 4: Validate the plan matches expectations

tofu plan

# Compare this output against the last terraform plan output
# There should be no unexpected changes on a clean migration

Step 5: Update provider registry references (if needed)

Most providers work without changes. If you have explicit registry references in your configuration, update them:

# Before (Terraform)
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# After (OpenTofu — registry reference is optional, same source works)
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"  # works with registry.opentofu.org
      version = "~> 5.0"
    }
  }
}

Step 6: Replace lock file for OpenTofu

rm .terraform.lock.hcl
tofu providers lock

Step 7: Run apply on non-production first

# Apply on dev/staging first
tofu apply

# Verify all resources are in expected state
tofu state list
tofu show

CI/CD Pipeline Migration: GitHub Actions, Jenkins & GitLab CI

CI/CD migration is the most visible operational change — every pipeline that calls terraform must be updated to call tofu. The binary substitution is straightforward; the configuration context changes are minimal.

GitHub Actions:

# Before (Terraform)
- name: Setup Terraform
  uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: 1.9.0

- name: Terraform Init
  run: terraform init

- name: Terraform Plan
  run: terraform plan

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

# After (OpenTofu)
- name: Setup OpenTofu
  uses: opentofu/setup-opentofu@v1
  with:
    tofu_version: 1.9.0

- name: OpenTofu Init
  run: tofu init

- name: OpenTofu Plan
  run: tofu plan

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

GitLab CI:

# Replace the Terraform image and commands
variables:
  TOFU_VERSION: "1.9.0"

.tofu_base:
  image:
    name: ghcr.io/opentofu/opentofu:${TOFU_VERSION}
    entrypoint: [""]
  before_script:
    - tofu --version
    - tofu init

plan:
  extends: .tofu_base
  script:
    - tofu plan -out=planfile

apply:
  extends: .tofu_base
  script:
    - tofu apply planfile
  when: manual
  only:
    - main

Jenkins (Declarative Pipeline):

pipeline {
  agent any
  environment {
    TOFU_VERSION = '1.9.0'
  }
  stages {
    stage('Install OpenTofu') {
      steps {
        sh 'curl -fsSL https://get.opentofu.org/install-opentofu.sh | sudo bash'
        sh 'tofu version'
      }
    }
    stage('Init') {
      steps { sh 'tofu init' }
    }
    stage('Plan') {
      steps { sh 'tofu plan -out=tfplan' }
    }
    stage('Apply') {
      when { branch 'main' }
      steps { sh 'tofu apply tfplan' }
    }
  }
}

Should You Migrate? A Decision Framework for Engineering Teams

The migration decision depends on four primary factors: license risk exposure, required features, HCP dependency, and team size. Not every team needs to migrate — Terraform remains the safe default for teams without BSL exposure who rely on HCP Terraform or Terraform Cloud for collaboration features that OpenTofu does not replicate. The decision matrix below captures the most common scenarios that determine which path is correct for a given team’s situation in 2026.

Migrate to OpenTofu if:

• Legal counsel has flagged BSL exposure for your SaaS product or commercial tooling
• You need native state encryption for compliance with SOC 2, FedRAMP, or PCI requirements
• You are deploying in air-gapped environments where Terraform’s commercial registry creates supply chain concerns
• You need provider for_each or dynamic backend variables available in OpenTofu 1.9+
• Your organization’s open-source policy prohibits BSL-licensed dependencies

Stay on Terraform if:

• You use HCP Terraform or Terraform Cloud for team collaboration, sentinel policies, or remote execution
• Your infrastructure is fully managed by a HashiCorp technology partner who requires Terraform
• Your team has no BSL exposure and the feature gap does not create operational pain
• You have HashiCorp Enterprise support contracts that would be invalidated by migration

Incremental migration (both in parallel):

• Large organizations with hundreds of Terraform projects should migrate incrementally by team or environment
• Start with non-production environments owned by teams with highest BSL risk
• Establish an internal standard: all new projects use OpenTofu, legacy projects migrate on a defined schedule

Enterprise Considerations: Regulated Industries and Security Requirements

Enterprise adoption of OpenTofu is concentrated in industries where the combination of open-source licensing, native state encryption, and CNCF governance creates a compliance profile that Terraform under BSL cannot match. Boeing, Capital One, and AMD have publicly confirmed OpenTofu adoption, each citing different primary drivers. For financial services teams operating under SOC 2 Type II, PCI-DSS, or HIPAA requirements, native state encryption is the most immediate technical requirement. Terraform state files frequently contain secrets — database passwords, API keys, TLS certificates — that must be encrypted at rest under these frameworks. OpenTofu’s native encryption eliminates the need for custom backend wrappers or external KMS integrations that add operational complexity and audit surface. For government and defense contractors operating under FedRAMP or ITAR requirements, the Linux Foundation governance model provides documented supply chain provenance that a single commercial vendor’s BSL product cannot provide equivalently. Air-gapped deployment is also cleaner with OpenTofu: the registry.opentofu.org mirrors can be self-hosted without commercial licensing concerns. For enterprises running on Kubernetes with GitOps workflows, the Flux and ArgoCD OpenTofu integrations maintain feature parity with the Terraform equivalents.

OpenTofu Roadmap and Long-Term Outlook for 2026

OpenTofu’s development velocity has accelerated since its Linux Foundation acceptance, with 140+ corporate backers funding a release cadence that 2026 shows no sign of slowing. The OpenTofu 1.9 release delivered provider for_each, the -exclude flag, and state encryption enhancements — features that the community had requested for years in Terraform but HashiCorp had not prioritized. The roadmap for 2026 includes AI-assisted infrastructure generation through the tofu ai command (in preview), enhanced testing frameworks aligned with the terraform test command that launched in Terraform 1.6, and deeper GitOps operator integrations. The governance model — CNCF Technical Advisory Group steering with corporate contributors including Spacelift, Env0, Scalr, and Gruntwork — means no single vendor controls the roadmap. For the 27% of teams currently planning to evaluate or expand OpenTofu use in 2026, the technical risk is low: the migration is reversible, the state format is compatible, and the provider ecosystem overlap is near-complete. The long-term risk of remaining on Terraform is the opposite: HashiCorp’s BSL terms can be changed unilaterally, HCP Terraform pricing can increase, and the feature gap with OpenTofu will continue to widen as the open-source project moves faster than a commercially constrained product.

FAQ

OpenTofu migration questions cluster around three practical concerns: whether the migration is safe, how long it takes, and what breaks. The reassuring answer on safety is that OpenTofu uses the same state file format as Terraform 1.5.x, making the migration reversible at any point before using OpenTofu-specific features. The IaC market at $2.1 billion in 2026 means tooling maturity is high — both OpenTofu and Terraform have robust state management, provider ecosystems, and CI/CD integrations. The 12% adoption figure for OpenTofu understates actual usage because many teams run OpenTofu silently in production without publicizing the migration. The questions below address the most common blockers teams encounter when evaluating whether and how to move from Terraform to OpenTofu in 2026, based on real migration case studies covering 20+ production projects.

Is it safe to migrate Terraform state to OpenTofu without converting it?

Yes. OpenTofu uses the identical JSON state file format as Terraform 1.5.x. No state conversion is required — you run tofu init in a directory containing a terraform.tfstate or pointing at a remote backend configured for Terraform, and OpenTofu reads it directly. The migration is fully reversible: you can switch back to Terraform by running terraform init in the same directory at any point before you use OpenTofu-exclusive features like native state encryption, which modifies the state format in a way Terraform cannot read. The recommended safety practice is to create a state backup before migrating (terraform state pull > backup.tfstate) and run tofu plan before any tofu apply to verify no unexpected changes.

Do all Terraform providers work with OpenTofu?

The vast majority do. OpenTofu’s provider registry at registry.opentofu.org mirrors the Terraform registry and supports all providers published under open-source licenses. Providers under BSL (notably the hashicorp/hcp and some HashiCorp-specific providers) may have registry policy differences, but community and major cloud providers (AWS, Azure, GCP, Kubernetes) work identically. The .terraform.lock.hcl file is compatible between Terraform and OpenTofu, though the recommended practice is to delete and regenerate it with tofu providers lock after migration to ensure provider hashes match the OpenTofu registry’s signatures.

How long does a typical Terraform to OpenTofu migration take?

A single Terraform project migration takes 30–60 minutes: install OpenTofu, back up state, run tofu init, validate tofu plan shows no changes, update the lock file, and update CI/CD pipelines. For a portfolio of 20 projects, the migration team at the case study organization completed the work in 2 weeks running migrations in parallel across teams. The main time investment is CI/CD pipeline updates — each pipeline that calls terraform must be updated to call tofu, and the hashicorp/setup-terraform GitHub Action must be replaced with opentofu/setup-opentofu@v1. Organizations with standardized pipeline templates can make this a one-template change that propagates automatically.

Can OpenTofu and Terraform manage the same state file simultaneously?

No — only one tool should manage a given state file at a time. Running both tools against the same state file simultaneously creates lock conflicts and risks state corruption. The correct approach for incremental migrations is to migrate individual projects fully (switching all pipelines and local workflows to OpenTofu) before moving to the next project. Teams that need to run both tools in parallel for different reasons should use separate state backends (separate S3 buckets or Terraform Cloud workspaces) for each tool.

Does OpenTofu support Terraform modules from the public registry?

Yes. Terraform modules published to registry.terraform.io are accessible from OpenTofu configurations using the same source references. OpenTofu resolves module sources from the Terraform registry transparently. The only exception is modules that have BSL-licensed dependencies baked into their configuration — in that case, the module source code runs fine in OpenTofu, but the license terms of the module content still apply. For modules in private registries, OpenTofu supports the same authentication mechanisms (tokens, SSH keys, HTTPS credentials) that Terraform uses.