Terraform to OpenTofu Migration: A Practical Guide

Migrating from Terraform to OpenTofu is mostly a binary swap. OpenTofu is a fork of Terraform that keeps the same HCL language, the same provider ecosystem, and the same state file format, so for most projects the move is replacing the terraform binary with tofu, updating CI, and re-running init. The harder part is not the swap. It is operating both engines safely while the migration is in flight. ops0 runs Terraform and OpenTofu side by side under one governance layer, so teams can adopt OpenTofu project by project instead of attempting a risky all-at-once cutover.

This guide covers why teams are moving, what the migration involves, where the real risk sits, and how to run a mixed Terraform and OpenTofu estate without losing policy, drift, or approval control.

Why teams move to OpenTofu

OpenTofu exists because Terraform changed its license in 2023 from the open MPL 2.0 to the Business Source License. OpenTofu is the community fork that continues under the original open license, with open governance under the Linux Foundation.

Teams move for a few practical reasons: keeping an open-source license for their core infrastructure tooling, avoiding tool-layer lock-in, and staying on a fork whose roadmap is governed in the open. For most teams the decision is about licensing and governance, not features, because the two tools remain highly compatible.

The migration itself is small

Because OpenTofu shares HCL, the provider protocol, and the state file format, the mechanical steps are short:

1. 1Replace the terraform binary with tofu in your local and CI environments.
2. 2Run tofu init so the lock file is created or updated from registry.opentofu.org.
3. 3Update CI/CD pipelines and any automation that calls the terraform command.
4. 4Move any Terraform Cloud or Sentinel workflows to open alternatives if you used them.

There is no state conversion step. The state format is shared, so OpenTofu reads existing state directly. That is what makes this one of the easier infrastructure migrations.

The hard part is the in-between

The risk is not the swap on a single project. It is the period when your estate runs a mix of Terraform and OpenTofu at the same time. During that window you still need the same policy checks, the same drift detection, the same cost visibility, and the same approval gates applied consistently across both engines. If governance only understands one engine, the migration creates blind spots exactly when you can least afford them.

This is why a big-bang migration is risky and a gradual, project-by-project adoption is safer. Gradual adoption only works if both engines are governed the same way while they coexist.

How ops0 runs both engines under one model

In ops0, the IaC engine is selected per project. A project can be Terraform, OpenTofu, or Oxid, and the interface stays the same while the engine underneath changes. The command layer routes to the right binary automatically: terraform, tofu, or oxid.

Policies follow the HCL family. A policy written for Terraform applies to OpenTofu projects too, so you do not maintain two separate rule sets during a migration. Validation, plan, and deploy work the same way for both engines, drift detection runs against both, and the same remote state backends are supported across AWS S3, Google Cloud Storage, Azure Blob, and Oracle Object Storage.

The result is that a mixed estate behaves like one estate. You can pilot OpenTofu on a low-risk project, keep the rest on Terraform, and apply identical policy, cost, approval, and drift controls to both while you expand.

What ops0 does not do, on purpose

ops0 does not silently rewrite your Terraform into a different language, and it does not convert your state behind your back. The state format is already shared between Terraform and OpenTofu, so there is nothing to convert. ops0 does not claim a magic instant migration. Its role is operating, governing, and reviewing both engines, not pretending the swap is more complicated than it is.

That honesty matters: the migration is simple, and the value is in keeping it governed.

A safe adoption plan

1. 1Pick one low-risk, non-production project as the OpenTofu pilot.
2. 2Swap the binary, run tofu init, and confirm plan output matches what Terraform produced.
3. 3Keep the same policies, cost checks, and approval gates applied to the pilot.
4. 4Watch drift on the pilot for a cycle or two to confirm parity.
5. 5Expand engine by engine, project by project, with governance unchanged the whole way.

Because ops0 treats Terraform and OpenTofu as interchangeable HCL engines, this plan does not require a separate toolchain for the OpenTofu projects.

The bottom line

Terraform to OpenTofu is a small technical migration with a real operational risk: governing a mixed estate during the transition. The swap is a binary change and a re-init. The discipline is keeping policy, cost, approval, and drift consistent across both engines until the move is complete. ops0 is built to run both side by side under one governed model, which is what makes a gradual, low-risk migration practical.