Terraform vs OpenTofu: What Changed and How to Migrate Safely

Why there are suddenly two Terraforms

In August 2023 HashiCorp relicensed Terraform from the Mozilla Public License to the Business Source License (BSL). The BSL is not open source in the OSI sense: it restricts using Terraform to build a competing product. For most teams running infrastructure this changes nothing legally, but the community reaction was strong, and a fork called OpenTofu (originally OpenTF) launched under the Linux Foundation with an MPL-2.0 license. OpenTofu reached general availability in early 2024 and has since shipped features Terraform does not have. So the question landing on a lot of platform teams is: do we stay on Terraform, or move to OpenTofu, and how risky is the switch?

What the license change actually means for you

Read the BSL clause plainly. It prevents you from offering Terraform itself as a competing commercial product, for example running a hosted Terraform-automation SaaS that competes with HashiCorp Cloud Platform. If you are a normal company using Terraform to provision your own infrastructure, or even an agency running Terraform on behalf of clients, you are almost certainly unaffected. Do not migrate out of fear alone. Migrate because OpenTofu offers something you want, or because your organization has a policy requiring OSI-approved open-source tooling. Both are legitimate reasons; vague licensing anxiety is not.

How compatible are they really

OpenTofu forked from Terraform 1.5.x, so for the vast majority of configurations the two are drop-in compatible. HCL syntax, providers from the registry, modules, and state file format all work. OpenTofu maintains its own provider registry that mirrors the ecosystem, and existing provider source addresses resolve. In practice, a codebase that runs on Terraform 1.5 will run on the equivalent OpenTofu version with no HCL changes.

The divergence began after the fork. OpenTofu shipped features Terraform lacked at the time, including state encryption at rest, provider-defined functions arriving on its own schedule, early support for variables in module sources, and a for_each on provider configurations. Terraform, meanwhile, kept advancing its own 1.x line with features like the testing framework and ephemeral values. The two are broadly interchangeable today for standard use, but they are no longer identical, and the gap widens over time. If you adopt an OpenTofu-only feature, you have made the migration one-directional.

State compatibility, the one thing to respect

Both tools use the same state format at the versions people run today, but do not casually run both against the same state file. Once a newer version of either tool writes to a state file, an older version of the other may refuse to read it, and OpenTofu's state encryption, once enabled, is not something Terraform understands. Treat your state as the source of truth and change only one tool at a time against it. Always back up state before you touch it.

A safe migration path

1. Pin and inventory. Note your exact Terraform version and every provider version. Migrating from Terraform 1.5.x to the matching OpenTofu release is the lowest-risk jump. If you are on a much newer Terraform, expect more testing.
2. Back up state. Snapshot every state file. If you use an S3 backend, confirm versioning is on. This is your rollback.
3. Install OpenTofu alongside. Do not uninstall Terraform yet. Keep both binaries available during the transition.
4. Run a plan, not an apply. In a non-production workspace, run tofu init then tofu plan against existing state. A clean migration shows no changes, or only trivial diffs. Investigate anything that proposes to destroy or recreate resources before going further.

# Point OpenTofu at your existing config and state
tofu init
tofu plan -out=tofu.plan

# Expect: "No changes. Your infrastructure matches the configuration."
# If you see destroys, STOP and investigate provider version drift.

5. Promote environment by environment. Migrate dev first, let it bake for a few days, then staging, then production. Never flip everything at once.
6. Update CI/CD. Swap the Terraform binary for OpenTofu in your pipeline, update any wrapper (many teams use tools that support both), and adjust cache keys and version pins. Update your linting and policy tooling to the OpenTofu-aware versions.
7. Decide on OpenTofu-only features deliberately. State encryption and provider for_each are nice, but each one you adopt makes going back to Terraform harder. Adopt them on purpose, not by accident.

When to choose which

Stay on Terraform if you rely on HashiCorp Cloud Platform, use Terraform-specific features like the native test framework heavily, want vendor support with an SLA, or your team simply has no appetite for a tooling change and the BSL does not affect you. Inertia is a valid reason when the incumbent works.

Move to OpenTofu if your organization requires OSI-approved open-source tooling, you want state encryption or other OpenTofu-native features, you prefer Linux Foundation governance over single-vendor control, or you want to avoid any future BSL surprises. The switch is low-risk for standard configurations.

Either is fine for the average team, and that is the honest takeaway. This is not a decision worth agonizing over. Pick based on governance preference and feature needs, migrate carefully, and keep your state backed up.

If you are running Terraform or OpenTofu across many environments and want the migration handled without disrupting deploys, that is squarely the kind of platform work we do under our managed DevOps services. Teams on a DevOps monthly retainer often use us to run exactly this sort of controlled, environment-by-environment migration while their own engineers keep shipping.

The short version

OpenTofu forked over the BSL relicense, stays broadly compatible for standard configs, and adds a few features of its own. The license rarely affects normal users, so migrate for real reasons, plan (never apply) first, back up state, and promote one environment at a time.

Want a senior engineer to plan and execute the migration with a tested rollback? InstaDevOps offers exactly that on retainer, Startup ($2,999/mo) and Business ($4,999/mo), with roughly 48-hour turnaround on requests. Book a 15-minute call and we will map out a safe path.