The OpenTofu 1.9 transition and the end of Terraform dominance

Licensing and the widening feature gap

The decision to switch from Terraform to OpenTofu often starts when a license change makes infrastructure feel like a hostage. I remember the moment when a pipeline fails on an import command because a managed service requires a Business Tier subscription to manage state. This is the "Open Core" pincer maneuver where vendors hook you with a free binary and change the locks once you build your foundation. Inertia is a massive force in IT, and many teams stay with Terraform because they fear the scale of their state files or the complexity of their modules. However, the Terraform binary is useless without the Registry, which acts as the supply chain. When HashiCorp changed its license in August 2023, it introduced Divergence Risk. I built an internal Terraform Feature Lag Tracker to monitor if the proprietary version was prioritizing gatekeeping features over engineering ones. IBM completed its acquisition of HashiCorp on February 27, 2025, and the Terraform license now names IBM as the licensor. While using Terraform in production is allowed under the Business Source License 1.1, companies that offer the engine to third parties on a hosted basis cannot compete with IBM’s paid versions. OpenTofu uses the Mozilla Public License 2.0 and is a project of the Linux Foundation, which accepted it to the CNCF Sandbox level on April 23, 2025. OpenTofu 1.9 introduced provider for_each and the exclude flag, which allow a single provider block to create configurations for different regions or accounts. When a company sells a managed service that uses the engine to provide infrastructure to customers, they cannot use the Business Source License without running into significant legal conflicts with IBM.

Engineering features and state security

OpenTofu prioritizes engineering features that the proprietary version often restricts to enterprise users. I find the native client-side state encryption in the 1.7 release to be an essential security standard for sensitive workloads. This feature encrypts state and plan files with AES-GCM using keys from a passphrase or an external program. However, I observed a failure where OpenTofu 1.7.0-alpha1 cannot save encrypted state to a GitLab HTTP state backend, resulting in a 500 error. In that scenario, the tool writes the updated state to a file named errored.tfstate to prevent total loss. The 1.8 release allowed variables and locals to be used in backend blocks and module sources, while the 1.10 release added OCI registry support. OpenTofu 1.11 added an enabled lifecycle argument and 1.12 introduced a dynamic prevent_destroy that reads variables. Terraform 1.17 still provides access to proprietary features like Stacks, actions, and Terraform Policy. The 1.10 release of OpenTofu also enabled native S3 state locking, which matches the capability Terraform added in version 1.11. These updates address community requests that commercial tools often treat as billing features.

A blueprint for the binary swap

A production environment migration requires a structured protocol to avoid destroying your state files. I follow three phases: the Registry Scrub, the Binary Swap, and the CI/CD Refactor. First, you must sanitize your code by explicitly defining providers to pull from the OpenTofu registry instead of relying on proprietary behaviors. If you have hardcoded references that rely on proprietary registry behaviors, you will break. Second, you must back up your terraform.tfstate file because corruption requires a manual import of every resource. I do not trust S3 versioning alone, so I pull a local copy before the init. If you run tofu apply and see a provider hash mismatch, you must delete the .terraform.lock.hcl file and run tofu init. I modeled the cost of this transition using a Cloud ROI Estimator. Even if I bill my time at $200 per hour, the refactor cost $8,000, while the Business Tier upgrade would cost $45,000 per year. Third, you must migrate the pipeline rather than individual repositories. I watched Fidelity migrate 2,000 applications and 50,000 state files by simply updating their pipelines to use the OpenTofu CLI. If you use a shared workflow like Atlantis or Terragrunt, you only change the binary invocation in a few definitions. I recommend the "Runners first, laptops last" approach to minimize local disruption. I still wonder if the maintenance of the mirrored registry will eventually cause a significant compatibility break for all users.