OpenTofu vs Terraform 2026: We Migrated 20 Projects (Here's What Changed)

We have migrated 20 client projects from Terraform to OpenTofu since the BSL license change. Some migrations took 10 minutes. Others uncovered real blockers that no comparison article warned us about.

This is not a feature checklist. This is what we learned doing actual migrations across AWS, Azure, and GCP stacks ranging from 50 to 2,000+ resources.

The License Situation in 2026

HashiCorp switched Terraform from MPL 2.0 to the Business Source License (BSL 1.1) in August 2023. IBM then acquired HashiCorp for $6.4 billion, with the deal closing in February 2025.

What this means practically:

• You can still use Terraform CLI for free for internal infrastructure
• You cannot build a competing managed service on top of Terraform without a commercial agreement
• OpenTofu forked from Terraform 1.5.x and stays under MPL 2.0, governed by the Linux Foundation
• IBM ownership adds uncertainty — large acquisitions often shift product direction and pricing

For most teams managing their own infrastructure, the BSL has zero day-to-day impact. The risk is strategic: what happens when Terraform Cloud pricing increases 18% year-over-year (which it already has) and your entire IaC pipeline depends on a single vendor?

We wrote about the original license change when it happened — see our analysis of the HashiCorp license change for the full background.

Feature Comparison: Where They’ve Diverged

As of March 2026, OpenTofu is on version 1.9.x and Terraform is on 1.14.x. They started from the same codebase but have diverged significantly. Here is where each tool has an exclusive advantage.

OpenTofu-Only Features

State Encryption at Rest (since v1.7)

This is the single most impactful feature OpenTofu has that Terraform does not. Your state file — which contains every secret, every IP, every database connection string — can be encrypted with AWS KMS, GCP KMS, or PBKDF2 before it ever hits your backend.

terraform {
  encryption {
    key_provider "aws_kms" "state_key" {
      kms_key_id = "arn:aws:kms:eu-west-1:123456789:key/abc-def"
      region     = "eu-west-1"
    }
    method "aes_gcm" "default" {
      keys = key_provider.aws_kms.state_key
    }
    state {
      method = method.aes_gcm.default
    }
    plan {
      method = method.aes_gcm.default
    }
  }
}

With Terraform, you rely on your backend’s encryption (like S3 server-side encryption) which is not the same as encrypting the state file itself. If someone gets read access to your S3 backend, they get your secrets in plaintext.

Dynamic Backend Configuration (since v1.8)

OpenTofu lets you use variables and locals in the terraform block. This sounds minor but it eliminates one of the most common hacks in Terraform codebases — partial backend configs and wrapper scripts:

# OpenTofu — clean multi-environment backends
locals {
  env = terraform.workspace
}

terraform {
  backend "s3" {
    bucket = "state-${local.env}"
    key    = "infra/terraform.tfstate"
    region = "eu-west-1"
  }
}

In Terraform, this is still not possible. You need -backend-config flags or generate files externally.

Provider-Defined Functions (since v1.7)

Providers can expose custom functions that you call in HCL. This is a significant extensibility improvement that Terraform added later in a different form.

Terraform-Only Features

Ephemeral Values (v1.10+)

Terraform introduced ephemeral variables and outputs that exist only during plan/apply and are never written to state. This is Terraform’s answer to state file security — instead of encrypting the state, prevent secrets from entering it at all.

Terraform Stacks (HCP Terraform only)

Stacks let you manage multiple infrastructure components — VPC, database, application cluster — as a single unit with coordinated deployment. This is powerful for complex multi-layer environments but is only available in HCP Terraform Plus and Enterprise tiers, not the open-source CLI.

Infragraph and MCP Integration (HCP Terraform only)

The most significant 2026 addition. HCP Terraform now exposes an MCP server that allows AI agents and IDEs to interact with your infrastructure graph, trigger workspace runs, and get context-aware insights. Again, this is exclusive to the paid platform.

Feature Summary Table

Feature	OpenTofu	Terraform
State encryption at rest	Native (KMS, PBKDF2)	Backend-level only
Dynamic backend config	Yes (v1.8+)	No
Provider-defined functions	Yes (v1.7+)	Yes (later)
Ephemeral values	No	Yes (v1.10+)
Stacks (multi-component)	No	HCP only
MCP/AI integration	Community modules	HCP only
Provider compatibility	Full (shared registry)	Full
HCL syntax	Identical	Identical
Performance	Equivalent	Equivalent
License	MPL 2.0 (open source)	BSL 1.1 (source available)
Governance	Linux Foundation	IBM/HashiCorp

Migration: What Actually Happens

We have done this 20 times now. Here is the real process, not the marketing version.

Step 1: Verify Clean State (5 minutes)

Run terraform plan and confirm zero changes. If you have drift, fix it before migrating. Migrating with pending changes is asking for trouble.

terraform plan
# Output: No changes. Your infrastructure matches the configuration.

Step 2: Back Up Everything (2 minutes)

# Back up state
terraform state pull > terraform-state-backup.json

# Back up lock file
cp .terraform.lock.hcl .terraform.lock.hcl.backup

Step 3: Install OpenTofu (2 minutes)

# macOS
brew install opentofu

# Linux
curl -fsSL https://get.opentofu.org/install-opentofu.sh | sh

Step 4: Fix Version Constraints (1 minute)

If your required_version constraint references Terraform’s versioning, OpenTofu will block:

# Before — blocks OpenTofu
terraform {
  required_version = ">= 1.14.0"
}

# After — works with both
terraform {
  required_version = ">= 1.6.0"
}

Step 5: Initialize and Validate (3 minutes)

tofu init
tofu plan

That is it. In 15 of our 20 migrations, the plan showed zero changes and we were done.

The 5 Migrations That Had Issues

Here is what broke in the other 5:

1. Terraform Cloud backend — OpenTofu cannot connect to Terraform Cloud workspaces. You need to migrate state to S3/GCS/Azure Blob first, then switch.

2. Sentinel policies — If you use HashiCorp Sentinel for policy enforcement, there is no OpenTofu equivalent. You need to switch to OPA (Open Policy Agent) or similar.

3. Private module registry on TFC — Modules hosted in Terraform Cloud’s private registry need to move to a Git-based source or a self-hosted registry.

4. required_version pinned too high — Projects pinned to >= 1.10 or higher could not run on OpenTofu 1.9.x without loosening the constraint.

5. Custom provider caching — One project had a custom provider mirror configuration that needed the registry URLs updated.

None of these were unfixable. But they turned a 10-minute migration into a 2-4 hour migration.

When to Stay on Terraform

Not every project should migrate. Here is our honest assessment:

Stay on Terraform if:

• You are deeply invested in Terraform Cloud or Enterprise with Sentinel policies, remote runs, and a private registry. The switching cost is real.
• Your team relies on Stacks for multi-component orchestration
• You have a commercial relationship with HashiCorp/IBM and the licensing terms are acceptable
• Your legal team has reviewed the BSL and confirmed it does not impact your use case

Switch to OpenTofu if:

• You are starting a new project — state encryption alone justifies it
• You run open-source Terraform CLI without Terraform Cloud — the migration is trivial
• Licensing risk matters to your organization (vendors, open-source products, MSPs)
• You want state encryption without paying for Terraform Cloud
• You are building a platform that provisions infrastructure for customers

Either works if:

• You use Terraform CLI with an S3/GCS backend and no Terraform Cloud features
• Your team is small and can switch later without major impact

Our Decision Framework

After 20 migrations, we use this decision tree:

1. Do you use Terraform Cloud/Enterprise features?
   ├── Yes → Do you use Stacks or Sentinel?
   │   ├── Yes → Stay on Terraform (migration cost too high)
   │   └── No → Consider migrating (state encryption is worth it)
   └── No → Migrate to OpenTofu (10-minute migration, clear upside)

2. Are you building a product that provisions infrastructure?
   ├── Yes → OpenTofu (BSL restricts competing services)
   └── No → Either works, but OpenTofu has better momentum

3. Do you need state encryption?
   ├── Yes → OpenTofu (native) or Terraform Cloud (paid)
   └── No → Either works

What About Pulumi and CDK?

This comparison is specifically OpenTofu vs Terraform because they share the same language (HCL), the same providers, and the same workflow. Switching between them is trivial.

Pulumi and AWS CDK are different tools entirely — they use general-purpose programming languages (Python, TypeScript, Go) instead of HCL. Migrating to them means rewriting your entire codebase, not swapping a binary.

We will cover Pulumi vs Terraform and Ansible vs Terraform in separate comparisons.

The Long-Term Outlook

The IaC landscape in 2026 has settled into a clear pattern:

• Terraform is doubling down on its commercial platform (HCP). The best features are gated behind paid tiers. The CLI remains capable but is not where innovation is happening.
• OpenTofu is shipping features that matter to practitioners — state encryption, dynamic backends, faster iteration cycles. The Linux Foundation governance means the license cannot change again.
• Provider ecosystem remains fully compatible. Both tools use the same providers, so switching does not affect your infrastructure definitions.
• IBM’s influence is the wildcard. Large acquisitions can go either way — more investment or gradual deprioritization. The HashiCorp team is still intact for now.

Our prediction: both tools will coexist for the foreseeable future. The split will be enterprise customers on Terraform Cloud vs. everyone else on OpenTofu. If you are on the open-source CLI today, OpenTofu is the more natural home.

Practical Next Steps

If you are considering migrating:

1. Audit your Terraform Cloud usage — if you only use it for remote state, the migration is trivial
2. Test OpenTofu on a non-production project — run tofu init && tofu plan and verify zero drift
3. Enable state encryption immediately after migrating — it is the biggest practical benefit
4. Update your CI/CD pipelines — replace terraform with tofu in your Jenkins pipelines or GitHub Actions workflows
5. Communicate the change to your team — the workflow is identical, but the binary name changes

If you are provisioning EKS clusters with Terraform modules, the same modules work with OpenTofu without modification. Same for any standard provider.

---

Need Help Migrating Your Infrastructure to OpenTofu?

Migrating 20 projects taught us exactly where the pitfalls are — from Terraform Cloud state extraction to policy engine replacement and CI/CD pipeline updates.

Our team provides Terraform consulting services that cover both Terraform and OpenTofu:

• Migration assessment — audit your current Terraform setup and identify blockers before you start
• State encryption setup — configure KMS-backed encryption for your most sensitive infrastructure
• CI/CD pipeline updates — update your DevOps pipelines to work with OpenTofu
• Policy migration — replace Sentinel with OPA or Kyverno for open-source policy enforcement

We have migrated stacks from 50 to 2,000+ resources across AWS, Azure, and GCP without downtime.

Talk to our Terraform and OpenTofu consultants →