OpenTofu

TL;DR

• OpenTofu is a fork of Terraform’s open-source version, licensed under MPL 2.0 by the Linux Foundation; the decision driver is licensing and governance, not technical capabilities.
• HCL syntax and state file format are largely compatible, but “largely” is not a forever-guarantee; the two projects evolve independently and divergence is ongoing.
• Migration from Terraform to OpenTofu is significantly lower-effort than switching to a fundamentally different tool (Pulumi, CDK) because of syntax and backend compatibility.
• Organizations with strict open-source licensing or vendor-control concerns have real, substantive reasons to prefer OpenTofu’s governance model; others may reasonably stay on Terraform.
• Before migrating, test provider compatibility and state file behavior in a non-production environment; don’t assume automatic, permanent parity.

Core Concepts

The origin: licensing, not technical capability

OpenTofu exists due to a licensing change to Terraform. HashiCorp shifted Terraform’s licensing model, raising concerns in the open-source community about long-term control and usage restrictions. OpenTofu was established as a Linux Foundation project under the genuinely open-source Mozilla Public License (MPL 2.0) to preserve open governance and licensing certainty.

This is the actual decision driver:

• Organizations with strict compliance requirements around open-source licensing: OpenTofu’s governance model may better fit organizational risk profiles.
• Organizations already invested in Terraform Cloud’s enterprise features: staying on Terraform is reasonable.
• Organizations without specific open-source licensing constraints: the technical difference is minimal; either tool works.

The decision is not “which is technically superior” — it’s “which governance model better aligns with organizational values and constraints.”

Compatibility: real but not unconditional

OpenTofu forked from a Terraform version. For most standard infrastructure-as-code, existing:

• HCL configurations work largely unchanged
• Module syntax is compatible
• State file format is compatible
• Backend configurations carry over
• CLI commands are similar

Key caveat: “largely compatible” is not “forever guaranteed.” The two projects evolve independently. As time progresses:

• New Terraform features may not land in OpenTofu immediately (or vice versa)
• Provider support may diverge
• Edge cases and new language features may behave differently
• State file evolution may diverge

Any team evaluating migration should validate provider compatibility and test in non-production first.

Migration effort and path dependency

Migrating Terraform → OpenTofu is significantly lower effort than Terraform → Pulumi or Terraform → CDK because:

• Same .tf files work with minimal changes
• Same remote backend configuration (S3 + DynamoDB, Terraform Cloud, etc.)
• Same CLI workflow (plan, apply, state commands)
• Same CI/CD integration patterns
• No need to rewrite infrastructure as code in a different language

This is fundamentally different from switching configuration languages or execution models, which requires genuine rewriting.

Provider ecosystem: the real compatibility risk

The most concrete compatibility concern: provider support. Terraform has 2000+ official and community providers. OpenTofu maintains a community provider registry, but divergence is real. Before migrating, verify:

• All providers your infrastructure depends on are available in OpenTofu
• Provider versions are compatible or equivalent
• Any custom or proprietary providers have OpenTofu equivalents

State file divergence over time

Both projects improve and extend state file handling. If OpenTofu and Terraform state files diverge at the format level, migrating between them later becomes harder. Teams maintaining long-term OpenTofu deployments should periodically test state file compatibility (and potential migration back to Terraform) to catch divergence early.

OpenTofu vs Terraform vs Pulumi

Migration Decision Tree

Does the organization have strict open-source or anti-vendor-control requirements?
├─ Yes → OpenTofu's governance model likely better aligns
└─ No, or "maybe" → Evaluate feature gaps and ecosystem maturity

Is the team already heavily invested in Terraform Cloud?
├─ Yes → Terraform may be more practical (OpenTofu has no direct equivalent)
└─ No → Either tool works; governance alignment drives the choice

Are there provider or feature gaps in OpenTofu that are deal-breakers?
├─ Yes → Stay on Terraform (for now)
└─ No → Can safely migrate (assuming testing)

Testing Before Migration

# 1. Export state from Terraform
terraform state pull > terraform.tfstate.backup

# 2. Initialize OpenTofu with same backend
tofu init

# 3. Test plan against live infrastructure
tofu plan    # Should show no changes if truly compatible

# 4. Test state file round-trip
tofu state pull > opentofu.tfstate
# Diff the two to catch any format changes

# 5. Test all providers used in the infrastructure
tofu providers  # Verify all providers are available

# 6. Run in non-production first; validate fully before production migration

Common Pitfalls

• Pitfall: Choosing OpenTofu vs. Terraform based on “popularity” or “team preference,” without evaluating the actual licensing/governance alignment. Why: The decision was treated as technical rather than organizational. Fix: Make the licensing and governance fit the primary decision criteria; technical parity is largely equivalent.

• Pitfall: Assuming permanent, automatic compatibility with all Terraform providers; discovering gaps only after committing to the full migration. Why: Provider compatibility wasn’t validated before migration. Fix: Test provider availability and compatibility in non-production before committing to the migration.

• Pitfall: Treating an OpenTofu migration as equivalent effort to switching to Pulumi or CDK; over-budgeting time. Why: Effort estimates didn’t account for syntax and backend compatibility. Fix: Recognize that OpenTofu is a syntax-compatible fork, not a different tool entirely; budget accordingly.

• Pitfall: Migrating to OpenTofu, then three months later discovering a provider divergence causes problems. Why: Provider compatibility wasn’t monitored over time. Fix: Periodically validate provider compatibility and state file format; maintain flexibility to migrate back to Terraform if divergence becomes problematic.

Interview Questions

• OpenTofu and Terraform are technically similar. Why does OpenTofu exist at all? — Tests whether the licensing and governance origin are understood as the real decision driver.

• You’re evaluating migrating to OpenTofu. What do you validate before committing? — Tests whether provider compatibility testing is treated as a real prerequisite, not assumed.

• How is migrating from Terraform to OpenTofu different in effort from migrating to Pulumi? — Tests understanding of syntax compatibility and the lower effort of this specific migration.

• An organization has strict open-source and anti-vendor-control requirements. Why might OpenTofu’s governance model matter to them? — Tests understanding of the real organizational value of OpenTofu’s structure.

• Two years into an OpenTofu migration, a provider divergence emerges. What’s the recovery strategy? — Tests whether long-term maintainability and divergence monitoring are considered.