OpenTofu vs Terraform: how to choose and how to migrate with a rehearsal and rollback plan

What each tool is

Terraform and OpenTofu are infrastructure as code (IaC) tools: you describe infrastructure in declarative files, and the tool computes a change plan and applies it against cloud providers. The workflow (init, plan, apply) and the state that records which resources are managed are equivalent in essentials.

OpenTofu began as a fork of Terraform. According to its own FAQ, it was created in response to HashiCorp's move away from an open-source licence to the Business Source License (BUSL). Terraform continues to be developed by HashiCorp, now part of IBM.

Licensing and governance: the real reason for the comparison

Terraform. On 10 August 2023 HashiCorp announced that future releases of its products would move from MPL 2.0 to BUSL 1.1. The LICENSE file in the Terraform repository currently states BUSL 1.1, with IBM as licensor, a change date four years after each version is published, and MPL 2.0 as the change licence. It includes an additional use grant that allows production use, with restrictions on offering the software to third parties on a hosted or embedded basis in competition with the paid products. IBM completed its acquisition of HashiCorp on 27 February 2025.

OpenTofu. The repository is published under MPL-2.0. It was announced as a Linux Foundation project on 20 September 2023 and accepted into the CNCF on 23 April 2025 at the Sandbox level (the earliest maturity level). Its FAQ describes a core team with a technical lead, a steering committee for major changes and a public RFC process.

Implications, not legal advice. If you use Terraform only internally to manage your own infrastructure, the BUSL restrictions may not affect you in practice; if you offer services or products that embed IaC, read the text carefully. Which licence is acceptable is each organisation's decision, with its own legal counsel. What we can say is that licence, governance and single-vendor dependency are risk criteria worth writing down.

Practical differences that matter

Compatibility. OpenTofu aims to stay compatible with Terraform configurations and, per its FAQ, works with existing providers: it has no providers of its own. The same FAQ states compatibility with state files created up to Terraform 1.5.x; it may be out of date, so always check the migration guide for the version you run.

Registry. OpenTofu uses its own registry (search.opentofu.org) with compatible providers and modules. In your rehearsal, confirm that every provider and module you use resolves and installs correctly; the source of each one may change the download path.

State. Both keep a state file. OpenTofu documents state and plan encryption (AES-GCM), with keys derived from a passphrase or managed in AWS KMS, GCP KMS, Azure Key Vault or OpenBao, among others. It is worth evaluating if your state holds sensitive data; we have not compared the Terraform equivalent, so we do not claim it lacks one.

Features and versions. The two projects evolve separately and add their own features. Before deciding, check each project's current release notes against what you actually use. Decide on the features your code needs, not on a generic feature list.

When to choose each

Terraform makes sense if you already use it and the licence fits your use after review, if you depend on HashiCorp/IBM ecosystem products you want to keep integrated, or if your team and support provider are aligned with it. Switching for its own sake has a cost and adds nothing.

OpenTofu makes sense if internal, customer or procurement requirements call for an open-source licence (MPL-2.0) and neutral governance, if you want to reduce single-vendor dependency, or if specific features such as state encryption matter to you.

Staying put is also a valid decision. If your code works and the licence is not an issue, there is no urgency: document the decision and review it periodically rather than migrating by inertia.

How to migrate with a rehearsal and rollback plan

OpenTofu's official documentation states that the process is designed to be safe and reversible, and splits it into four stages: back up state and code, install, initialise and verify, and test with a small change. We do not promise it will be trivial in your case: it depends on versions, providers and how your code is organised. A reasonable rehearsal plan:

1. Inventory. List repositories, state backends, Terraform and provider versions, in-house and third-party modules, and where IaC runs (pipelines, workstations).

2. State backup. Before anything else, copy the state (local state files, or your backend's backup procedure for remote state) and confirm you know how to restore it.

3. Rehearse outside production. Start with a test environment and a copy of the state. Run tofu init and tofu plan: the expected result is “no changes” or the same output as Terraform. If the plan shows unexpected changes, do not apply: investigate first.

4. Controlled first apply. In the rehearsal environment, run tofu apply: the guide says it runs even with no infrastructure changes, because it may update the state file format, so have the backup ready first. Then test with a small, non-critical change (for example a tag) and review the plan before applying.

5. Mind terraform_remote_state. If several configurations pass data to each other with it, migration needs more care and ordering; OpenTofu's documentation has a separate guide.

6. Written rollback plan. OpenTofu's guide describes returning to Terraform: stop using OpenTofu, restore backups if the state changed, run terraform init and terraform plan, and confirm there are no unexpected changes. Because tofu apply may change the state format, rollback depends on having the earlier backup, and it is wise to keep the Terraform version you used pinned. Rehearse it before migrating production, with an agreed window and a change owner.

7. Change in steps. Migrate environment by environment and repository by repository, with pull request review and pinned versions in your pipelines.

How it fits platform design

Terraform and OpenTofu can be the IaC layer of an internal platform (platform engineering and IDPs) on AWS, Azure, Google Cloud and OCI: accounts, subscriptions, projects or compartments, networking, identity, clusters and tagging, versioned and reviewed through pull requests. The tool choice is secondary to design decisions such as module structure, per-environment state separation, secrets kept out of code and version policy.

At Nubyron we design platforms with IaC on top of Kubernetes and DevOps and help you choose and rehearse the tool that fits your case; we can also support the continuous delivery workflow as DevOps as a service. We deliver the architecture, reference code and guides so your teams can operate it.

Frequently asked questions