For years Terraform was the uncontroversial default for infrastructure as code. In August 2023 HashiCorp moved it from the open-source MPL license to the Business Source License, the community forked it as OpenTofu, and in 2025 IBM completed its acquisition of HashiCorp. Three years later, teams starting a new project — or renewing an enterprise contract — ask the same question: Terraform or OpenTofu? This guide explains the licensing in plain terms, compares the tools as they stand in 2026, and describes how we migrate existing Terraform codebases.

What happened, briefly

  • August 2023: HashiCorp announced that future Terraform releases (from 1.6) would use the Business Source License 1.1 instead of MPL 2.0.
  • September 2023 – January 2024: the OpenTF initiative forked the last MPL version, the project joined the Linux Foundation as OpenTofu, and OpenTofu 1.6.0 became generally available in January 2024 (OpenTofu manifesto; OpenTofu is going GA).
  • February 27, 2025: IBM completed its acquisition of HashiCorp (IBM, 2025).
  • April 2025: OpenTofu was accepted into the Cloud Native Computing Foundation as a sandbox project (CNCF: OpenTofu).

What the BSL means for you

The Business Source License is source-available, not open source. In short, it allows broad use — including production use inside your company — but restricts offering products or hosted services that compete with HashiCorp's commercial offerings. For most companies that use Terraform to manage their own infrastructure, day-to-day usage did not change.

Where it matters:

  • Vendors and platforms that embed or host Terraform as part of a commercial offering.
  • Companies with strict open-source policies that require OSI-approved licenses for core tooling.
  • Long-term risk assessment: the license holder can change terms for future versions; with an open-source, foundation-governed project that risk is lower.

Read the license and HashiCorp's FAQ with your legal team if you are in a grey zone (HashiCorp licensing FAQ).

Compatibility in 2026

OpenTofu started as a drop-in replacement for Terraform 1.5/1.6, and both tools still share the HCL language, the provider protocol and the state format at their core. Most providers work with both, and the OpenTofu registry mirrors the provider and module ecosystem. Over time the tools have diverged in features, so "drop-in" now depends on which newer features you use on each side.

Feature comparison

Area Terraform OpenTofu
License BSL 1.1 (source-available) MPL 2.0 (open source), Linux Foundation / CNCF
Governance HashiCorp, an IBM company Community, multiple vendors
State encryption Relies on the backend (e.g. encrypted S3) Built-in client-side state and plan encryption since 1.7
Registries Terraform Registry, HCP Terraform private registry OpenTofu Registry, plus OCI registries for providers and modules since 1.10
S3 backend locking DynamoDB or S3 native locking in newer versions Native S3 locking since 1.10
Managed platform HCP Terraform, Terraform Enterprise Third-party platforms (Spacelift, env0, Scalr and others) or self-hosted CI
Language extras Stacks, Terraform-specific features Early variable evaluation, provider for_each, -exclude, deprecation support

OpenTofu 1.10, released in June 2025, added OCI registry support for air-gapped environments, native S3 state locking, external key providers for state encryption, deprecation markers for module variables and outputs, and OpenTelemetry tracing (OpenTofu 1.10). Releases continued through 2026, with 1.12 published in May (OpenTofu releases).

State encryption deserves a closer look

Terraform state often contains secrets: database passwords, private keys, connection strings. OpenTofu can encrypt state and plan files client-side before they reach the backend, with keys from passphrases or key management services (OpenTofu: state encryption):

terraform {
  encryption {
    key_provider "aws_kms" "main" {
      kms_key_id = "arn:aws:kms:eu-central-1:123456789012:key/abcd-..."
      region     = "eu-central-1"
      key_spec   = "AES_256"
    }
    method "aes_gcm" "default" {
      keys = key_provider.aws_kms.main
    }
    state {
      method = method.aes_gcm.default
    }
    plan {
      method = method.aes_gcm.default
    }
  }
}

How to choose

Choose OpenTofu when:

  • You want an open-source, foundation-governed tool for a long-lived platform.
  • State encryption, OCI registries or air-gapped operation matter.
  • You run IaC from your own CI or a third-party platform rather than HCP Terraform.
  • You build a product or service around infrastructure automation.

Stay on Terraform when:

  • You rely on HCP Terraform or Terraform Enterprise features and support contracts.
  • Your organization is standardized on HashiCorp tooling and the BSL is acceptable to your legal team.
  • You use Terraform-only features that have no OpenTofu equivalent.

For our own client platforms — such as the Hetzner clusters in Kubernetes on Hetzner — we default to OpenTofu.

Migrating from Terraform to OpenTofu

OpenTofu publishes migration guides per Terraform version (OpenTofu: migration). Our process:

  1. Inventory Terraform versions, providers, backends and any Terraform-specific features in use.
  2. Back up state for every workspace.
  3. Install OpenTofu in CI next to Terraform; pin the version.
  4. Run tofu init and tofu plan per workspace. The goal is a plan with no changes.
  5. Switch one low-risk workspace to tofu apply, then the rest in batches.
  6. Update CI pipelines, pre-commit hooks and documentation; remove Terraform binaries.
  7. Adopt OpenTofu-only features, such as state encryption, only after the switch is complete — they make going back harder.
# per workspace
cp terraform.tfstate terraform.tfstate.backup     # or snapshot the remote backend
tofu init -upgrade
tofu plan -out=tofu.plan                           # expect: No changes.

Treat your IaC pipeline as part of the software supply chain: pin provider versions, verify checksums and review plans in pull requests, as described in CI/CD without pain and Container and supply chain security.

Running OpenTofu in CI

A minimal GitHub Actions job that plans on pull requests and applies on main, with the plan reviewed in the PR:

jobs:
  plan:
    runs-on: ubuntu-latest
    permissions: { contents: read, id-token: write, pull-requests: write }
    steps:
      - uses: actions/checkout@<pinned-sha>
      - uses: opentofu/setup-opentofu@<pinned-sha>
        with: { tofu_version: 1.12.x }
      - run: tofu init -input=false
      - run: tofu plan -input=false -out=plan.bin
      - run: tofu show -no-color plan.bin > plan.txt   # attach to the PR for review

Use OIDC to obtain short-lived cloud credentials instead of storing access keys, and keep the apply job behind a protected environment with required reviewers.

Mistakes we see during migrations

  • Switching all workspaces at once. Migrate in batches so a provider or backend issue affects one team, not all of them.
  • Unpinned versions. Let CI and developers run the same pinned OpenTofu and provider versions; mixed versions produce noisy plans.
  • Forgetting the lock file. Commit .terraform.lock.hcl so provider checksums are verified on every run.
  • Enabling state encryption mid-migration. Do it after everyone has switched, with keys stored in a KMS and a documented recovery procedure.
  • Leaving Terraform binaries in CI images. Someone will eventually run terraform apply against migrated state.

FAQ

Is Terraform still free to use? For managing your own infrastructure, the BSL allows free use. Restrictions apply to offering competing products or services.

Can OpenTofu use Terraform providers and modules? Generally yes; they share the provider protocol, and the OpenTofu registry serves the common ecosystem.

Is migration reversible? Yes, as long as you haven't adopted OpenTofu-only features such as encrypted state. Plan the switch before using them.

Will the tools keep diverging? Likely. Pick one per organization and standardize, rather than mixing both in the same codebase.

What about Terraform CDK and other wrappers? Check each tool's compatibility separately. Tools that generate HCL or JSON for the engine usually work with both; tools tied to HCP Terraform APIs may not.

Do existing modules from the public registry still work? Most do, because modules are plain HCL. Test critical modules during the plan-only phase of the migration.

Sources

  1. OpenTofu. Manifesto, GA announcement, OpenTofu 1.10, releases.
  2. OpenTofu. State and plan encryption and Migration guides.
  3. CNCF. OpenTofu project.
  4. IBM (2025). IBM completes acquisition of HashiCorp.
  5. HashiCorp. Licensing FAQ.