OpenTofu vs Terraform: When to Migrate Without Breaking Your Infra

It's no longer the same tool under another name#

For almost a decade, "infrastructure as code" and "Terraform" were practically synonyms. That era is over. Today there are two tools born from the same codebase: Terraform, owned by IBM since 2025, and OpenTofu, a community fork under the Linux Foundation.

The question people type into search engines is no longer "which one is better?" but something far more practical: should I switch, and what do I risk if I do?

The short answer: it depends on three things, and none of them is strictly technical. What matters is whether the project is new, whether you depend on HashiCorp's commercial pieces and whether Terraform's license is a legal risk for your organization. This guide covers how we got here, what differs between the two engines, a decision tree and the safe migration procedure recommended by OpenTofu's own documentation.

Documentation: Linux Foundation · OpenTofu launch (2023) ↗ · HashiCorp · Terraform license (BUSL 1.1) on GitHub ↗

How we got here: license, fork and acquisition#

In August 2023, HashiCorp changed Terraform's license from the Mozilla Public License 2.0 (MPL 2.0), which is open source, to the Business Source License 1.1 (BSL or BUSL). The BSL allows you to use the software but restricts offering it in products that compete with HashiCorp's. The LICENSE file in the Terraform repository reflects that license today.

The community responded quickly. A group of companies and developers forked the last MPL-licensed version, first under the name OpenTF, and on September 20, 2023 the Linux Foundation announced OpenTofu as an open source alternative with neutral governance.

Then came the acquisition. IBM announced in April 2024 that it would acquire HashiCorp at an enterprise value of 6.4 billion dollars and closed the deal in February 2025. The license didn't change with the acquisition, but it revived a legitimate concern: Terraform's commercial direction now depends on a single large vendor.

Three years on, the question of whether OpenTofu would survive has been answered. The CNCF accepted OpenTofu on April 23, 2025 as a Sandbox-level project, and platforms like GitLab now document their infrastructure as code integration around OpenTofu. The better question is no longer whether to consider OpenTofu, but when the difference in licensing and governance actually matters for your team.

Documentation: HashiCorp · Terraform license (BUSL 1.1) on GitHub ↗ · Linux Foundation · OpenTofu launch (2023) ↗ · IBM · HashiCorp acquisition announcement (2024) ↗ · IBM · HashiCorp acquisition completed (2025) ↗ · CNCF · OpenTofu project page ↗ · GitLab Docs · Infrastructure as Code with OpenTofu ↗

What actually changed: they're no longer the same fork#

During the first year, OpenTofu was essentially a clone with a different name. That's no longer true: the two products have diverged and each one has features the other lacks.

OpenTofu focused on features for the people writing the code:

• Native state and plan encryption (since 1.7), its most cited differentiator.
• Early evaluation of variables and locals (since 1.8): you can use them in backend blocks, module sources and the encryption configuration.
• Provider iteration with for_each (since 1.9), useful for multi-region deployments without duplicating blocks.
• The -exclude flag (since 1.9) to plan while leaving certain resources out.

A nuance many comparisons leave out: provider-defined functions arrived in OpenTofu in 1.7, but Terraform has supported them since 1.8 as well, so they're no longer a differentiator.

Terraform, for its part, invested in its commercial platform: Stacks to orchestrate multiple configurations as a single unit, Sentinel for policy as code and HCP Terraform as a managed platform for runs, state, permissions and auditing.

terraform {
  encryption {
    key_provider "pbkdf2" "main" {
      passphrase = var.state_passphrase # at least 16 characters; prefer a KMS in production
    }

    method "aes_gcm" "main" {
      keys = key_provider.pbkdf2.main
    }

    # Migration only: allows reading state that is still unencrypted.
    method "unencrypted" "migration" {}

    state {
      method = method.aes_gcm.main
      fallback {
        method = method.unencrypted.migration
      }
    }
  }
}

The good news if you're on the fence is that the core is still compatible: the same HCL language, the same provider model and the same state format. That's why migrating doesn't rewrite your infrastructure; in practice, it changes the binary that runs it.

Documentation: OpenTofu · What's new in 1.7 ↗ · OpenTofu · What's new in 1.8 ↗ · OpenTofu · What's new in 1.9 ↗ · HashiCorp · Provider-defined functions (Terraform 1.8+) ↗ · HashiCorp · Terraform Stacks ↗ · HashiCorp · Sentinel ↗ · HashiCorp · HCP Terraform ↗ · OpenTofu · State and plan encryption ↗

The decision tree: three questions in order#

Instead of an "X is better than Y" verdict, answer three questions in order. The first one that gives you a clear destination wins.

Question 1: is this a new project with no prior investment in Terraform? If you're starting from scratch, OpenTofu is a reasonable default: same syntax, same provider ecosystem, state encryption and no licensing ambiguity. As long as you don't turn on exclusive features, going back to Terraform remains viable.

Question 2: do you depend on HCP Terraform, Stacks or Sentinel, or does your procurement team require HashiCorp/IBM as a supported vendor? Then stay on Terraform, or migrate only the workspaces that don't depend on those pieces. OpenTofu doesn't offer direct equivalents of those commercial products; there are third-party platforms that partially cover them, but that's a separate evaluation.

Question 3: is the BSL a legal risk for you? This applies if you sell a service or build a product around infrastructure as code, or if your legal or compliance team flags the BSL as a risk. In that case, migrate to OpenTofu, which keeps the MPL 2.0 license under the Linux Foundation. Always get your legal team's interpretation: this guide is not legal advice.

Did you answer "no" to all three? Then migrating is optional. For internal use with no licensing concerns you can stay on Terraform without issue, although it's worth evaluating OpenTofu for its features and to avoid being tied to a single vendor.

Documentation: HashiCorp · Terraform license (BUSL 1.1) on GitHub ↗ · HashiCorp · HCP Terraform ↗ · HashiCorp · Terraform Stacks ↗ · HashiCorp · Sentinel ↗

How to migrate without breaking anything#

If you decide to switch, the mechanics are deliberately boring, and that's a good thing. The safe pattern isn't a big bang but one workspace at a time, as the official guide describes:

• Back up the state and the code. With a remote backend, use the backend's own mechanism (for example, S3 bucket versioning) and work on a migration branch.
• Install the tofu binary alongside terraform. They can coexist on the same machine and in the same pipeline.
• Run tofu init and then tofu plan against a workspace. The expected result is "No changes" or the same plan you'd see with Terraform. If unexpected changes show up, don't apply: investigate.
• Run tofu apply even if there are no changes, so OpenTofu can update the state format if needed.
• Make a small, non-critical change, such as adding a tag, and apply it with tofu to confirm it can manage the infrastructure.

# 1. Backup (local backend; for remote backends use versioning or snapshots)
cp terraform.tfstate terraform.tfstate.pre-tofu

# 2. Check the binary
tofu --version

# 3. Initialize: downloads providers from the OpenTofu registry
tofu init

# 4. The plan should be empty or identical to Terraform's
tofu plan -detailed-exitcode
# exit 0 = no changes, 2 = changes present (review before applying), 1 = error

# 5. Rollback if something goes wrong
terraform init && terraform plan

Two warnings that save a lot of pain. First: state is compatible in both directions, so you can go back to Terraform, unless you enable OpenTofu's state encryption, which makes those files unreadable to Terraform. Turning on encryption is, in practice, a one-way decision.

Second: the syntax has started to diverge. Some constructs exist in only one of them, such as variables in backend blocks in OpenTofu or Stacks files in Terraform, and they fail in the other. If your system uses several configurations linked through terraform_remote_state, the OpenTofu documentation calls for extra care with the migration order.

Documentation: OpenTofu · Migrating from Terraform ↗ · OpenTofu · Installation ↗ · OpenTofu · State and plan encryption ↗ · OpenTofu · What's new in 1.8 ↗

Before production: compare plans in staging#

The most common mistake is assuming full compatibility because the language is the same. The practical rule is simple: don't migrate a production workspace without first comparing plans in an isolated environment.

• Clone the code into a staging environment and run tofu init to confirm that every provider and module resolves from the OpenTofu registry.
• Run terraform plan and tofu plan against the same state and compare the planned resources. Any difference is a friction point you need to understand.
• Validate the state backend (S3, GCS, Azure Blob or another) and secrets handling with the tofu binary.
• Update the CI/CD pipeline by swapping the binary without changing the logic, and run in staging for a reasonable period before touching production.

terraform plan -out=tf.plan
tofu plan -out=tofu.plan

terraform show -json tf.plan | jq -S '[.resource_changes[] | {address, actions: .change.actions}]' > tf.json
tofu show -json tofu.plan    | jq -S '[.resource_changes[] | {address, actions: .change.actions}]' > tofu.json

diff tf.json tofu.json && echo "Plans are equivalent"

If you use Terraform CLI without Sentinel, without Stacks and without HashiCorp managed services, the technical risk of migrating is usually low, and in most cases it doesn't require changing the HCL. But low isn't zero: a provider that behaves differently or a version not published in the OpenTofu registry can stall the migration. Validate first, migrate second.

Documentation: HashiCorp · terraform plan ↗ · OpenTofu · Migrating from Terraform ↗

When not to migrate#

To be fair: Terraform isn't broken, and it has advantages that matter to certain teams. HCP Terraform is a mature managed platform, with remote runs, state management, permissions and policies, which the OpenTofu ecosystem doesn't replicate point by point as a turnkey product. Commercial support from HashiCorp and IBM and years of accumulated documentation are legitimate reasons to stay.

The sensible conclusion isn't that everyone should standardize on one engine tomorrow. It's that OpenTofu now has enough momentum of its own that its licensing and governance advantages don't come with a significant technical cost. For teams not wedded to specific HCP Terraform workflows, OpenTofu is increasingly a reasonable default.

Whatever you decide, document it: which workspaces use each engine, which version you pin in CI and whether state encryption is enabled. That clarity prevents the worst-case scenario: two engines running in parallel with nobody knowing which one governs each piece.

Documentation: HashiCorp · HCP Terraform ↗ · CNCF · OpenTofu project page ↗