Definition
Terraform vs OpenTofu
Terraform and OpenTofu share HCL, state, and most providers. They differ in license, release cadence, and who you trust to ship the binary. Here is how to choose — and when a migration is actually worth it.
Terraform vs OpenTofu · reference
Terraform and OpenTofu are two CLIs that speak the same infrastructure language. A module written in HCL, a terraform.tfstate file, and a pinned AWS or Azure provider will usually run under either binary.
The useful comparison is not “which syntax is better.” It is license, governance of the toolchain, and operational risk of switching.
What they still share
- HCL. Resources, modules,
for_each, locals, and most functions you already use. - State. A JSON state file, remote backends, and lock files. Treat state as sacred either way.
- Providers. The same plugin protocol. Pin versions in
required_providers. - The plan/apply contract. Write a plan file, review it, apply that exact plan.
If someone on your team can read a Terraform module, they can read an OpenTofu module.
Where they differ
| Topic | Why it shows up in a real decision |
|---|---|
| License | Terraform's BSL changed how some companies redistribute or embed the CLI. OpenTofu is MPL. Legal review, not a tweet, should decide this. |
| Release train | Features and deprecations land on different calendars. Do not assume a Terraform 1.x flag exists in your OpenTofu version, or the reverse. |
| Remote products | HashiCorp's commercial run/state products are Terraform-oriented. OpenTofu does not magically give you that SaaS. |
| Ecosystem assumptions | Some wrappers, Sentinel policies, or vendor images still say terraform on the PATH. Your CI must be explicit about the binary. |
None of these are reasons to rewrite modules. They are reasons to treat the runner as a dependency you pin, the same way you pin providers.
When staying on Terraform is the simpler path
Stay if:
- legal has already accepted the current Terraform license for how you use the CLI,
- your remote state and policy stack is built around a Terraform-specific product you are not leaving,
- you need a Terraform-only feature that OpenTofu has not shipped yet, and you have no workaround.
Switching to look modern is a bad migration reason.
When OpenTofu is a reasonable move
Consider OpenTofu if:
- counsel wants an MPL CLI for how you distribute or embed the toolchain,
- you already run plan/apply in your own CI and only need a compatible binary,
- you want a community-governed release process and can accept a slightly different feature lag.
Then treat it as a binary swap with a rehearsal, not a rewrite. Use the OpenTofu migration checklist.
What should stay the same after either choice
Governance does not come from the executable name.
You still need IaC governance: who can apply, which policies run on a plan, and how approvals work. Generation and review work the same for both binaries — see Terraform / OpenTofu generation.