Terraform vs OpenTofu in Practice: What to Use After BSL, and When to Switch

What “Can we still use Terraform on a new project?” actually means

Since HashiCorp moved Terraform from MPL 2.0 (open source) to BSL (Business Source License) 1.1 in 2023, one question has become a fixture in infrastructure team meetings: “Does this trip the license?” And once IBM announced its acquisition of HashiCorp in 2024 and completed it on February 27, 2025, that anxiety grew into a larger decision: “Are we willing to accept vendor lock-in?”

At the same time, OpenTofu—the community fork of Terraform—started at the Linux Foundation, joined the CNCF as a Sandbox project in April 2025, and has started shipping its own features, such as state encryption. The question is no longer “which is better,” but “which should we use in our situation.”

This post is a decision, not an introduction. Every section ends with a decision rationale, and the end includes a situation-by-situation decision table plus copy-pasteable migration commands. The license interpretation below is for practical judgment only; the final call must go through your in-house legal review.

License judgment: does BSL actually apply to our company?

The core BSL clause is not, as often misunderstood, “no commercial use.” Precisely, it prohibits use to create a competitive offering against HashiCorp’s commercial products. Most in-house infrastructure management use does not trigger it.

You can self-assess in about five minutes with this Yes/No flow.

[when]
  │
  ▼
① Terraform Result
 external SaaS/ ?
  │
 ├── No ──▶ [BSL ]
 │ ( , → )
  │
  └── Yes
        │
        ▼
② HashiCorp
 (Terraform Cloud/Enterprise ) ?
        │
 ├── No ──▶ [BSL — , check ]
        │
 └── Yes ──▶ [⚠ BSL — required / OpenTofu ]

In short:

Core decision rationale: If you use infrastructure, you can keep using Terraform without much worry. If you sell infrastructure automation itself, OpenTofu is the safe zone.

Head-to-head: features and compatibility

OpenTofu started as a fork of Terraform 1.5.x, so early compatibility is very high. As the two projects evolve independently, though, gaps appear.

⚠️ Feature gaps by version (e.g. whether Terraform 1.6/1.7/1.8 features landed in the matching OpenTofu release) change quickly. Do not treat any snapshot as definitive—always check each project’s official release notes. Support for stacks, certain functions, and provider-defined functions in particular shifts often.

Decision rationale: Because state remains compatible, the migration itself is technically low-burden. If you need state encryption, OpenTofu is the only built-in option.

Migration in practice: terraform → tofu procedure

Technically it is surprisingly simple. Below is the full copy-pasteable flow.

1) Install the binary

# macOS (Homebrew)
brew install opentofu

# Linux
curl -fsSL https://get.opentofu.org/install-opentofu.sh -o install.sh
chmod +x install.sh
./install.sh --install-method standalone
rm install.sh

# check
tofu version

Expected healthy output:

OpenTofu v1.x.x
on darwin_arm64

2) Command mapping — just replace terraform with tofu

3) Always back up state and lock before switching

# state
cp terraform.tfstate terraform.tfstate.bak
cp .terraform.lock.hcl .terraform.lock.hcl.bak

# backend / state

4) Init and confirm a no-op plan

tofu init -upgrade
tofu plan

Expected healthy result: No changes. Your infrastructure matches the configuration.

If you get that no-op, state was interpreted correctly. If the plan shows resource recreation (destroy/create), do not apply—investigate provider version and lock-file differences first.

5) Swap the CI pipeline (GitHub Actions)

# Before
- uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: "1.5.7"

# After
- uses: opentofu/setup-opentofu@v1
  with:
    tofu_version: "1.8.0"

If you use Atlantis, set the execution binary in atlantis.yaml or server config:

# atlantis.yaml
projects:
  - dir: .
    workflow: tofu
# server-side: workflows.tofu.plan.steps tofu call

6) Rollback procedure

If something goes wrong, reverting is equally simple.

# 1. backup state/lock
cp terraform.tfstate.bak terraform.tfstate
cp .terraform.lock.hcl.bak .terraform.lock.hcl

# 2. when terraform
terraform init -upgrade
terraform plan # No changes check

Because the state format is compatible, two-way switching is possible—that is the psychological safety net.

Failure-branch checklist: what actually blocks a migration

The commands are easy. What actually blocks a move is the dependencies below. Check these before you switch.

• Is the provider on the OpenTofu Registry? If a minor or in-house provider is unregistered, you need an explicit source (source = "registry.opentofu.org/...") or a mirror.
• Do you depend on TFC/TFE-specific features?
  • Workspace management via remote backend → partially compatible; reconfiguration may be needed
  • Sentinel policies → not supported on OpenTofu (consider OPA/Conftest as a replacement)
  • TFC-only features such as Run Tasks / Drift Detection → cannot be migrated as-is
• Are wrappers and the tool chain compatible?
  • Terragrunt: OpenTofu supported (terraform_binary = "tofu")
  • TFLint / tfsec / Checkov: mostly HCL-parse based so they work, but confirm versions
• Are module sources hardcoded to a specific registry?

Decision rationale: If you are deeply tied to TFC/TFE Sentinel and Run Tasks, migration cost spikes. In that case the real decision is larger than “move to OSS”: keep TFC vs. switch to self-hosting.

Decision table by situation

Cost comparison: open source is free; the real cost is the management layer

Both CLIs themselves are free. Cost shows up in the “management layer” that handles collaboration, policy, and state.

Exact unit prices change with vendor policy, so check each vendor’s official pricing page.

Korea in one paragraph: In Korea, OpenTofu adoption is growing among cloud MSPs and platform teams, and Korean-language materials and community talks keep accumulating. That said, large enterprises that need a commercial support contract should separately confirm Terraform Cloud/Enterprise’s official support channels, or whether vendors such as Spacelift and Env0 have local partnerships.

Conclusion: one-line verdicts

• You use infrastructure + new project → OpenTofu as the default.
• Org deeply tied to TFC-specific features → stay as-is until a replacement is designed.
• Vendor that sells IaC → OpenTofu + legal review.

The technical migration is as light as swapping terraform for tofu and confirming a no-op on tofu plan. The real decision is license and TFC dependency.

FAQ

Q. We only manage in-house infrastructure. Does Terraform BSL apply? A. Generally no. BSL restricts use to create a product that competes with HashiCorp’s commercial offerings, and provisioning your own infrastructure is not that. Final judgment still needs in-house legal review.

Q. If we move to OpenTofu, do we have to rebuild existing state? A. No. The state format is compatible, so the same state file is read as-is. After a backup, run tofu init and tofu plan and confirm a no-op (No changes). You can also roll back to terraform if needed.

Q. We use Terraform Cloud Sentinel policies. Can we go to OpenTofu? A. Sentinel is not supported on OpenTofu. Finish a replacement design with an open-source policy engine such as OPA (Open Policy Agent)/Conftest first, then migrate.

Sources · checked 2026-10-04

• IBM, completion of the HashiCorp acquisition (2025-02-27)
• CNCF, OpenTofu project page — accepted at the Sandbox level on 2025-04-23