OpenTofu 1.9 vs Terraform 1.9 — what do I need to change?
Decide whether to keep Terraform 1.9 or migrate to OpenTofu 1.9, balancing licensing, state migration, and ecosystem compatibility in 2026.
Blockers
- OpenTofu documents a focused migration path: first move from Terraform 1.9.8 to OpenTofu 1.9.0.
- OpenTofu documents that the legacy hashicorp/terraform provider is not compatible.
Who this is for
- cost-sensitive
- enterprise
Candidates
Keep Terraform 1.9
Terraform 1.9 keeps you on HashiCorp's upstream toolchain and avoids a state-format handoff right now. The Terraform source license for version 1.6.0 or later is Business Source License 1.1, with a later change date to MPL 2.0, so the licensing posture remains the main non-technical consideration as of 2026-04-03. If you use HCP Terraform, HashiCorp's current Flex pricing is RUM-based: Standard Edition is free for the first 500 managed resources, then usage is billed per managed resource-hour, while Plus Edition starts billing from the first managed resource. Keeping Terraform also avoids the OpenTofu-specific registry and migration checks.
When to choose
Use this when licensing is acceptable and the main goal is minimizing operational change, especially if you already depend on HCP Terraform workflows or want to avoid a registry/state migration now. It is the lower-risk choice when you do not need an open-source license and do not want to validate provider and module resolution again.
Tradeoffs
Least migration work and no immediate state handoff, but you stay on BUSL-licensed upstream code and any HCP Terraform spend remains tied to HashiCorp's RUM pricing model.
Cautions
If you may migrate later, do not casually move beyond the documented Terraform 1.9.8 migration point first. OpenTofu's official 1.9 migration guide is explicitly written for Terraform 1.9.8, and says to wait for another guide if you are already on a higher Terraform version.
Migrate to OpenTofu 1.9
OpenTofu 1.9 is the Linux Foundation-governed fork that remains under the Mozilla Public License 2.0, which is the main reason teams move after the BSL split. OpenTofu documents a focused migration path from Terraform 1.9.x: first move from Terraform 1.9.8 to OpenTofu 1.9.0, then upgrade OpenTofu further. The official guide says OpenTofu 1.9.0 is largely compatible with Terraform 1.9.x, but requires a state backup, a clean no-change Terraform plan before switching, and a follow-up `tofu apply` so OpenTofu updates state. As of 2026-04-03, the CLI itself is open source under MPL 2.0; check official docs for any separate hosted-service pricing you may adopt around it.
When to choose
Use this when open-source licensing, governance neutrality, or reducing dependency on HashiCorp-controlled licensing is the decisive factor. It is the better fit for cost-sensitive or policy-sensitive teams that can afford one controlled migration window and can validate provider/module availability before cutover.
Tradeoffs
You regain an MPL-licensed IaC CLI and a documented rollback path, but you must execute a real migration and validate registry compatibility. Some configurations can fail during `tofu init` if a provider or module is not available in the OpenTofu registry.
Cautions
Back up local or remote state before the switch and verify restore procedures. OpenTofu also documents that the legacy `hashicorp/terraform` provider is not compatible and should not be declared in `required_providers`.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "OpenTofu 1.9 vs Terraform 1.9 — what do I need to change?"