OpenTofu vs Terraform in Production: The Fork Story, What Actually Changed, and Whether You Should Migrate

I remember exactly where I was when HashiCorp dropped the license change announcement on August 10, 2023. I was on a plane back from a client engagement, no wifi, laptop closed. When I landed and opened Slack, my feed was a wall of reactions. Terraform, the tool I had built our entire multi-account AWS infrastructure automation around at three different companies, was no longer truly open source. HashiCorp was switching from Mozilla Public License 2.0 to the Business Source License 1.1, effective immediately for all future versions.

The practical impact was the thing that mattered most to us: any competing product, cloud managed service, or platform built on top of Terraform was now in legal gray territory. HashiCorp’s stated intent was to protect their business from cloud providers who were offering Terraform-compatible managed services without contributing back. Reasonable, maybe. But the execution was a gut punch to the ecosystem.

Within weeks, the OpenTofu fork was announced. What started as righteous anger in Slack channels became a governed, Linux Foundation-backed project with CNCF adoption. Two and a half years later, with OpenTofu 1.8 shipped and Boeing and Capital One running it in production, the question has moved from “will this fork survive?” to “should we actually migrate?”

I’ve spent considerable time over the past year evaluating this for clients, and I’ll give you my honest take.

What the BSL License Actually Means

The Business Source License is not a viral license like GPL. You can use Terraform under BSL for your own internal infrastructure, your application deployments, anything that isn’t competitive with HashiCorp’s commercial offerings. For the vast majority of teams running terraform apply against AWS accounts, nothing changed legally.

The pain hit in three places. First, managed Terraform platforms. Services like Spacelift, env0, and Scalr had to make legal determinations about whether their product constituted a competing service. Most concluded they were fine, but the legal uncertainty was real. Second, tooling builders. If you were building tooling on top of the Terraform codebase, wrapping it, extending it, you now needed legal review. Third, the signal it sent. Open source ecosystems run on trust. When the foundational tool signals it might charge you later, teams start hedging.

The practical question for most organizations comes down to: do you have a HashiCorp contract or HCP Terraform subscription today? If yes, you’re paying for Terraform and the license change affects you in the contractual dimension. If no, and you’re running open source Terraform locally or in CI, the license change is mostly philosophical right now because the BSL converts to a fully open license after four years.

That said, philosophical matters. Twenty years in this industry has taught me that ecosystem health is infrastructure. The tooling you build on, the provider ecosystem, the Stack Overflow answers, the modules in the registry, that’s all sustained by community investment. When community investment forks, you want to be on the right fork.

What OpenTofu Has Actually Shipped

The skeptical take in late 2023 was: “Sure, they forked it, but they’ll never be able to keep pace with HashiCorp’s engineering resources.” That skepticism has been largely disproven.

OpenTofu 1.6 through 1.8 have shipped features that Terraform still does not have. Not just parity, actual differentiation. Here is what matters in practice:

Native state encryption. This is the one that consistently surprises teams when I bring it up. OpenTofu has built-in, provider-level state encryption. Your state files, containing resource IDs, sensitive outputs, and sometimes credentials, can now be encrypted at rest using AES-GCM or PBKDF2 key derivation before being pushed to your backend. With Terraform, you’re relying entirely on backend-level encryption (S3 bucket KMS, GCS encryption keys), which protects you at the storage layer but leaves state unencrypted in memory and in transit to your CI runner. OpenTofu’s model encrypts the state payload itself. For teams operating under HIPAA, PCI, or FedRAMP, this is material.

Provider for_each. If you’ve written non-trivial Terraform code, you’ve hit the wall where you want to instantiate multiple provider configurations dynamically, say, one AWS provider per account in a multi-account setup, and you can’t do it without code generation or workarounds. OpenTofu 1.7 ships for_each on the provider block. This sounds minor until you’re managing 50 AWS accounts and you realize you can eliminate 400 lines of repetitive provider configuration.

Early variable evaluation. OpenTofu allows variables in backend blocks during initialization, something Terraform has refused to do for years, citing technical complexity. In practice this means you can parameterize your backend configuration without shell scripting sed replacements or wrapper scripts. This alone has cleaned up a lot of ugly CI pipelines I’ve inherited.

Independent provider registry. OpenTofu maintains its own registry mirroring 2,000-plus providers, which means you’re not dependent on registry.terraform.io for provider downloads. For air-gapped environments and highly regulated deployments, having a registry you control is meaningful.

The features OpenTofu has not shipped yet are mostly HashiCorp’s commercial differentiators: Sentinel policy framework (though the open source policy as code ecosystem with OPA and Kyverno covers this well), the HCP Terraform workspace features, and some advanced drift detection UI. If you’re heavily invested in HCP Terraform’s collaboration features, OpenTofu is not a drop-in replacement for your full workflow, just for the CLI and execution layer.

The Enterprise Adoption Story

By Q1 2026, the fork has proven staying power. Boeing is running OpenTofu for declarative infrastructure management, partly because they need long-term (ten-plus year) assurance that the binary won’t change licensing on them, a legitimate concern when you’re building infrastructure that outlasts software companies. Capital One has moved greenfield projects to OpenTofu, citing open governance as a requirement for their technology risk assessments. The CNCF sandbox status, moving toward incubation, gives OpenTofu governance weight that matters in enterprise procurement.

The contributor story is healthier than I expected. HashiCorp had a large engineering team, but a lot of the ecosystem investment in Terraform came from the community and from integrators. Much of that community followed the fork. OpenTofu’s release cadence has been solid, and the core team has been responsive to contributor PRs in a way that the late-stage Terraform project was not always known for.

That said, I’m not pretending the market share picture is clear. Terraform (including HCP Terraform) still has the majority of the installed base. The default for most tutorials, certification courses, and module examples is still terraform. When you hire someone with “Terraform” on their resume, they may have never touched OpenTofu. For some teams, that friction matters.

Should You Migrate? The Actual Decision Framework

I’ve helped four teams evaluate this over the past year. Here is how I’d frame the decision:

Migrate now if:

• You have no HashiCorp contract and are running open source Terraform in CI
• You’re building greenfield infrastructure and have no existing Terraform state to deal with
• You operate in a regulated environment where open governance and source auditability are compliance requirements
• You’re building a platform product or tooling that provisions infrastructure for others (the legal risk from BSL is most acute here)
• You need native state encryption or provider for_each and don’t want to wait for Terraform to ship them

Stay on Terraform if:

• You’re an active HCP Terraform customer and deeply use Sentinel policies and workspace features
• Your team has heavily invested in Terraform certification and tooling, and migration cost isn’t justified by current pain
• You need Terraform’s commercial support SLAs

The hybrid path (what most large organizations are doing): Run existing Terraform deployments as-is, and default to OpenTofu for all new workspaces and modules. The state file format is compatible. The HCL syntax is identical. Providers work on both. You can run both in the same organization without conflict.

I want to be direct about migration complexity: for most teams it is lower than you fear. OpenTofu is genuinely drop-in compatible with Terraform for the vast majority of configurations. You change the binary from terraform to tofu, update your version constraints, and your existing state and providers continue to work. I have done this migration for a 200-resource production deployment in under a day, including testing. The tricky edge cases are version pinning to specific Terraform versions with provider protocol quirks, and teams using Terraform Cloud workspace-level features that don’t translate to an OpenTofu equivalent.

The piece most teams underestimate is the CI/CD pipeline changes. If you’ve built GitOps workflows around Terraform tooling, particularly anything using the Terraform GitHub Actions or official Terraform container images, you’ll need to update those to the OpenTofu equivalents. Not hard, but not invisible either.

How to Actually Migrate

Here is the practical path for a team migrating an active infrastructure deployment:

Phase 1: Audit your version constraints. Run a search for required_version = "~> 1.x" constraints across your modules. OpenTofu 1.6 and later is compatible with Terraform configurations targeting Terraform 1.5 and earlier. If you’re pinned to a very recent Terraform version that added features, check whether OpenTofu has shipped those features.

Phase 2: Install OpenTofu alongside Terraform. Use tfenv or tenv (the OpenTofu-aware version manager) to manage both binaries. This lets you run tofu plan against existing state without committing to the migration.

Phase 3: Run tofu init and validate. This is the moment of truth. OpenTofu will re-download providers from its registry and reinitialize the working directory. The state is not modified. Check that your provider versions resolve correctly.

Phase 4: Run tofu plan and diff against terraform plan. I do this in a non-production environment first. The output should be identical. If you see differences, investigate before proceeding. I’ve seen differences in edge cases with provider version resolution, particularly with providers that have had recent registry changes.

Phase 5: Update CI/CD pipelines. Replace Terraform binary installs with OpenTofu installs in your pipeline definitions. Update any Atlantis, Spacelift, or Terragrunt configurations. For infrastructure drift detection workflows, make sure your drift tooling can invoke tofu rather than terraform.

Phase 6: Migrate state backend metadata (optional). Your state files don’t need modification. The .terraform directory and lockfile will be recreated by OpenTofu on first init. You can optionally rename references from terraform to opentofu in any metadata, but it’s not required for operation.

For teams using Terragrunt, the migration is straightforward as Terragrunt has had explicit OpenTofu support since version 0.55.

What This Means for the Broader IaC Ecosystem

The Terraform fork is the most significant event in infrastructure-as-code tooling in the past five years, and its ripple effects are still playing out.

The first ripple is in the infrastructure as code tool landscape broadly. Pulumi has benefited from the OpenTofu discussion because teams evaluating a switch have considered whether to move to Pulumi’s general-purpose language model instead. Pulumi is genuinely differentiated: real programming languages, unit testing, and a different mental model for infrastructure. But the learning curve is steeper and the provider ecosystem, while large, is still smaller than Terraform’s. Most teams evaluating IaC today are choosing between OpenTofu and Pulumi for greenfield, with OpenTofu winning when the team already has Terraform expertise.

The second ripple is in the Crossplane ecosystem. Crossplane’s model of using Kubernetes as a control plane for cloud infrastructure sidesteps the Terraform/OpenTofu debate entirely. For teams already running Kubernetes and wanting to provision cloud resources through the Kubernetes API, Crossplane is compelling. It’s not a replacement for Terraform/OpenTofu in every scenario, but it’s capturing some of the teams that were already frustrated with Terraform before the license change.

The third ripple is around module registries. The Terraform Module Registry at registry.terraform.io remains the largest collection of community modules. OpenTofu’s registry mirrors this collection, but the canonical source is still terraform.io. For module development, teams need to decide whether to publish to one registry, both, or to host their own. Most enterprise teams hosting private modules are using artifact repositories (Artifactory, GitHub Packages) for this anyway, so the public registry distinction matters less to them.

The State of the Ecosystem in 2026

HashiCorp’s acquisition by IBM closed in mid-2024. IBM has said the right things about continuing Terraform development and maintaining the BSL license terms. Whether IBM sustains HashiCorp’s engineering investment in Terraform long-term is an open question. IBM has a mixed track record with open source acquisitions. This uncertainty is itself an argument for OpenTofu: CNCF governance is more stable across corporate ownership changes than commercial product governance.

The Terraform provider ecosystem remains the biggest asset either fork can point to. There are thousands of providers covering every cloud service and SaaS platform you can imagine. Both Terraform and OpenTofu can use these providers. The ecosystem is the shared asset that neither fork can afford to fracture, and so far neither has. Provider compatibility has been maintained carefully by both sides.

For cloud landing zone designs and enterprise-scale account vending machines, the toolchain choice matters over a five-to-ten year horizon. I’m advising clients building new landing zone implementations to default to OpenTofu unless they have specific HCP Terraform requirements. The governance model is better for long-lived enterprise infrastructure.

The practical reality is that the majority of the IaC work I do today, the modules, the state backends, the workspace patterns covered in our Terraform state management guide, all of it works identically on OpenTofu. The muscle memory and expertise transfers. The ecosystem has not fractured. The fork has matured into a genuine alternative, not just an ideological statement.

My Recommendation

If you are starting fresh, use OpenTofu. The open governance, the feature differentiation, and the trajectory all point the same direction. The syntax is identical to what you already know, the provider ecosystem is shared, and the migration path back if something goes catastrophically wrong is just swapping binaries.

If you are running existing Terraform infrastructure with no pressing pain, the cost-benefit of migration is less clear. Prioritize the migration for greenfield work and high-sensitivity workloads where native state encryption is valuable. Defer migration for stable, low-change infrastructure where disruption risk outweighs benefit.

If you are building a platform engineering practice that provisions infrastructure for other teams, make OpenTofu your standard now. The legal clarity around BSL when you’re building internal tooling on top of IaC is worth the migration cost, and your internal users will never notice the difference.

The BSL license change was a bad day for the ecosystem. The OpenTofu response has been one of the more impressive open source fork stories I’ve seen in twenty years of this work. The combination of Linux Foundation governance, CNCF backing, a coherent technical roadmap, and real enterprise adoption makes this a fork worth betting on.

What started as righteous anger in Slack channels has become a serious piece of infrastructure for some of the largest companies on the planet. That’s not nothing.