The question comes up in every infrastructure review now, and the answers available online are mostly advocacy. The useful version is narrower: what changed, who it actually affects, and what it costs to choose wrong.
What changed, precisely
HashiCorp moved Terraform from an open source licence to the Business Source Licence. That licence permits use, modification and redistribution, with one restriction: you may not use it to provide a competitive offering to HashiCorp's products. After a defined period each version converts to an open source licence.
The word doing the work is "competitive", and the reason this caused so much noise is that it is not precisely defined. For the overwhelming majority of organisations, using Terraform to manage their own infrastructure, nothing changed at all and nothing is likely to. For companies whose product includes running Terraform for customers, the restriction is real and immediate.
The Linux Foundation then adopted the community fork, OpenTofu, which is genuinely open source under a permissive licence and governed by a foundation rather than a company. HashiCorp has since been acquired by IBM, which changes the corporate context without changing the licence.
Who is actually affected
End users managing their own infrastructure. You are not a competitive offering. You can keep using Terraform indefinitely, and the licence is not your reason to move. If you choose to move, choose for a different reason such as governance preference or a specific feature.
Software vendors whose product embeds or runs it. If you sell a platform that runs Terraform on behalf of customers, the restriction plausibly applies to you and the safe answer is OpenTofu. This is the group the licence was aimed at, and several such vendors moved immediately.
Consultancies and managed service providers. The murky middle. Running Terraform as part of delivering a client engagement is using it to manage infrastructure, which is fine. Building a productised platform around it for many clients starts to look different. If your business model sits near that line, get a view from counsel rather than from a blog, and note that OpenTofu removes the question entirely, which is a legitimate reason to prefer it.
Regulated organisations with procurement rules about licences. Some public sector and regulated buyers have policies that exclude non-open-source dependencies, which decides it for you regardless of the technical merits.
Compatibility, and the divergence
OpenTofu forked from a Terraform version and remains highly compatible: the same configuration language, the same state format, the same provider protocol. The entire provider ecosystem works with both, because providers are separate programs communicating over a defined interface, and the module registries are interoperable.
For most configurations, migration is changing which binary your pipeline calls.
The divergence is real and growing, though. Both projects have shipped features the other does not have, and each release cycle adds a little more. Notable OpenTofu additions include state encryption at rest and some early-evaluation capabilities. Terraform has continued adding its own features, and some of its ecosystem functionality is tied to HashiCorp's platform.
The practical consequence: compatibility today is high, compatibility in three years is a guess, and any feature you adopt that exists in only one of them is a decision to stay. Check the current feature comparison at the moment you decide rather than trusting a summary, because this is the part that ages fastest.
Migration is cheap, returning is less so
Moving to OpenTofu is genuinely straightforward for a typical estate. Install the binary, point your pipeline at it, run a plan and confirm it is empty, and commit. Back up your state first, which you should be doing anyway. For most teams this is an afternoon.
The asymmetry is the part to think about. Once you adopt an OpenTofu-only feature, going back means removing it. Once a provider or a module in your supply chain becomes OpenTofu-first, your options narrow. That is not an argument against moving, it is an argument for deciding deliberately rather than drifting.
A few practical checks before migrating: confirm every provider you use is available, check that your CI tooling and any policy or cost tooling in the pipeline support the binary you are switching to, and verify your state backend works unchanged. The patterns in Terraform state and pipelines on AWS apply identically to either tool, which is part of why the switch is cheap.
What we recommend, by situation
Already on Terraform, single organisation, no licence concern. Stay. The migration has a cost and no benefit for you today. Revisit if a feature you need appears on one side only.
Starting fresh. Slight preference for OpenTofu. Foundation governance removes a category of future risk, the compatibility is high, and there is no migration cost when there is nothing to migrate.
Building a product on top of it. OpenTofu, and stop thinking about it.
Regulated or public sector procurement with open source requirements. OpenTofu, decided for you.
Already invested in HashiCorp's managed platform. Staying is coherent. The platform integration is the thing you are paying for, and fragmenting your tooling to make a point costs more than it saves.
Whichever you pick, the decision that matters more is the one underneath: your module structure, your state layout, your pipeline discipline and your testing. Those determine whether your infrastructure code is maintainable, and they are identical in both. A team with good module design and real testing of infrastructure code will be fine on either tool. A team without them will struggle on both.
The things people forget
- Pin the version. Whichever you use, pin it in the pipeline and in the configuration. An unpinned binary upgrading itself is how a plan produces a surprise.
- Providers are licensed separately. The provider you depend on has its own licence and its own maintainer, and that is a supply chain question independent of this choice.
- State is the valuable asset. Both tools read the same format today. Guard the state, back it up, and never let a migration be the first time you test restoring it.
- Do not run both. A team using different binaries against the same state is asking for a subtle incompatibility at the worst moment.
- The documentation diverges too. An answer found online may describe the other tool's behaviour.
What to do this week
Run a plan with both binaries against one non-production stack and diff the output. If it is identical, which for most estates it will be, you have established that the choice is reversible today and you can decide on governance grounds rather than technical ones. That is a half-hour experiment that removes most of the anxiety from the decision. We run it during the platform review in a cloud engagement.