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’s acquisition of HashiCorp was confirmed in 2024, 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—has been growing steadily under the Linux Foundation 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.

[시작]
  │
  ▼
① 우리는 Terraform으로 만든 결과물을
   외부에 재판매하거나 SaaS/관리형 서비스로 제공하는가?
  │
  ├── No ──▶ [BSL 저촉 가능성 낮음]
  │           (사내 인프라, 자사 서비스 배포 등 → 대부분 안전)
  │
  └── Yes
        │
        ▼
② 그 제품이 HashiCorp의 상용 제품
   (Terraform Cloud/Enterprise 등)과 경쟁하는가?
        │
        ├── No ──▶ [BSL 저촉 가능성 낮음 — 단, 법무 확인 권장]
        │
        └── Yes ──▶ [⚠ BSL 리스크 — 법무 검토 필수 / 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

# 설치 확인
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 바이너리 호출

6) Rollback procedure

If something goes wrong, reverting is equally simple.

# 1. 백업한 state/lock 복원
cp terraform.tfstate.bak terraform.tfstate
cp .terraform.lock.hcl.bak .terraform.lock.hcl

# 2. 다시 terraform으로 초기화
terraform init -upgrade
terraform plan   # No changes 확인

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.