OpenTofu vs Terraform. Should I switch?

Terraform isn’t MPL anymore. OpenTofu is the community fork. If you’re responsible for a Terraform codebase you probably want a considered answer to “should I switch.” Here is mine.

What actually happened

Quick recap, with as little drama as possible:

• August 2023: HashiCorp re-licensed Terraform (and all their other products) from MPL 2.0 to the Business Source License. The TL;DR: still free for most uses, not free if you compete with HashiCorp’s commercial products.
• September 2023: A coalition of vendors and individuals announced a fork. It was renamed to OpenTofu and adopted by the Linux Foundation in early 2024.
• 2024–2025: OpenTofu released 1.6, 1.7, 1.8, 1.9. It tracks Terraform’s features pretty closely but has shipped some of its own — early-evaluation variables, encrypted state files, the for_each in provider blocks.

That is the entire substance of the “drama.” The boring practical question is whether the syntax you already write still works.

The practical answer

For almost everyone the answer is: yes, both still work, OpenTofu is a drop-in replacement, you can switch the binary and your code is fine. I have done the switch on two reasonable-sized codebases. Both times it went like this:

$ brew install opentofu       # or whatever your package manager is
$ tofu init
$ tofu plan
$ tofu apply

That is the migration. The state file format is compatible. terraform_remote_state still works. Modules from the registry still install. The same providers from registry.terraform.io can be used, and OpenTofu also has its own registry at registry.opentofu.org mirroring most of them.

The minor wrinkle is the binary name. tofu instead of terraform. If you have CI scripts or developer workflows hardcoded to terraform plan, that’s a search-and-replace. Some teams alias terraform to tofu on shared runners during the transition. That works, but I would rather rip the band-aid off.

Should you switch?

The reasons to switch:

• License clarity. If your company has a clear policy about not using BSL software in production, the decision is made for you.
• You want the new features. Encrypted state out of the box is the one I have actually used.
• You don’t want to depend on a single vendor’s commercial roadmap for what is, by now, very foundational software.

The reasons not to switch:

• You use HCP Terraform / Terraform Cloud / Sentinel policies. That ecosystem is HashiCorp-only. OpenTofu does not currently aim to clone it.
• You use a specific recent feature in stable Terraform that OpenTofu has not yet shipped. The gap is shrinking but they are not exactly the same software.
• Your team has zero appetite for tool-name changes — which, fair enough, is sometimes the only reason that matters.

Running both

You don’t actually have to choose. The two binaries can operate on the same code, sometimes even on the same state, as long as you avoid features that exist in only one of them. I have a small CI matrix on one project that runs terraform fmt -check and tofu fmt -check, and terraform validate and tofu validate, as a smoke test. It catches accidental drift.

jobs:
  lint:
    strategy:
      matrix:
        tool: [terraform, tofu]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
        if: matrix.tool == 'terraform'
      - uses: opentofu/setup-opentofu@v1
        if: matrix.tool == 'tofu'
      - run: ${{ matrix.tool }} fmt -check -recursive
      - run: ${{ matrix.tool }} validate

What I actually do

I run OpenTofu locally and in CI for everything new. I have not migrated a couple of older systems that are tied to a Terraform Cloud workspace. I don’t feel any urgency about it. The point of infrastructure-as-code was always that the code was the durable artifact, not the binary that interprets it.

The thing I would not do is wait for the dust to settle. The dust has settled. OpenTofu is here, it is fine, the licensing is clean. If you have a quiet afternoon, switch and stop thinking about it.