OpenTofu vs Terraform: A Practical Migration Guide for Enterprise Infrastructure Teams

The Fork and Why It Matters

HashiCorp's August 2023 relicensing of Terraform from MPL 2.0 to the Business Source License (BSL 1.1) was the most consequential open source licensing event of that year for infrastructure teams. The BSL prohibits using Terraform to offer a commercial service that competes with HashiCorp — a restriction that is ambiguously worded enough to create legal risk for any organisation offering managed infrastructure services, cloud consulting, or internal platforms that resemble a Terraform-as-a-service offering. The OpenTofu fork, stewarded by the Linux Foundation, preserves the MPL 2.0 licensing and has maintained compatibility with the Terraform 1.5.x baseline from which it forked.

OpenTofu 1.x Maturity Assessment

As of early 2026, OpenTofu 1.6 and 1.7 have introduced several features that go beyond the Terraform 1.5 baseline, including native state encryption, provider-defined functions, and improved test framework capabilities. Provider compatibility is excellent: any provider that builds against the Terraform Plugin Framework (rather than the deprecated SDK) works with OpenTofu without modification. The Terraform Registry remains accessible for provider and module downloads.

Where Caution Is Warranted

• HCP Terraform integration: If your organisation uses HCP Terraform (formerly Terraform Cloud) for remote state, policy-as-code via Sentinel, or audit logging, OpenTofu requires migration to an alternative backend. Spacelift, Scalr, env0, and Atlantis are the primary alternatives.
• Terraform Cloud Agents: Private network connectivity via Terraform Cloud Agents has no direct OpenTofu equivalent; the replacement pattern uses self-hosted runners in Atlantis or similar.
• Sentinel policies: OpenTofu does not support HashiCorp Sentinel. OPA with Conftest is the functional replacement; migration requires rewriting policies but the logic is directly translatable.

Migration Steps

For most enterprise infrastructure teams, migration from Terraform to OpenTofu is a drop-in replacement at the binary level. The migration sequence is:

• Install the OpenTofu CLI via the Linux Foundation-maintained installer or package repository.
• Run tofu init in each Terraform working directory to verify provider compatibility.
• Run tofu plan against existing state to confirm no unexpected diff is produced.
• Update CI/CD pipelines to call tofu instead of terraform.
• If using remote state in HCP Terraform, migrate state to Terraform-compatible backends (S3, Azure Blob, GCS) before switching to OpenTofu.

License Risk Reduction

The primary driver for enterprise OpenTofu adoption is BSL compliance risk reduction. OSSeva's Assure service tracks BSL-licensed components in your infrastructure toolchain and flags usage patterns that may require commercial licensing or legal review. The combination of automated detection and a clear migration path to OpenTofu allows infrastructure teams to address BSL exposure systematically rather than on an advisory-by-advisory basis.

Conclusion

OpenTofu is production-ready for the majority of enterprise Terraform use cases. The migration is low-risk for teams using self-managed backends and open source providers. Teams with significant investment in HCP Terraform or Sentinel should plan a parallel migration of those components alongside the binary switch, but the total migration scope is well-defined and achievable in a single sprint for most environments.