The line you have heard a hundred times is that OpenTofu and Terraform are the same tool with different logos. Change terraform to tofu in your pipeline, run tofu init against your existing state, and you are done. Fidelity Investments is the proof everyone cites: they moved more than 50,000 state files across 2,000 applications managing over 4 million cloud resources, and their VP of Automation Tooling said the quiet part out loud. "The code itself isn't the hard part. Changing the CLI in a pipeline is trivial."
He is right. And that framing is exactly why teams are about to get burned.
The swap being trivial is a statement about a single moment in time, tested against a codebase that stayed on the common subset the two tools still share. It says nothing about whether you can swap back, or swap at all, six months from now. Because since the August 2023 fork, OpenTofu and Terraform have not just diverged in license and governance. They have diverged in the file formats they can read. Every feature one tool shipped that the other did not is a small latch on a one-way door, and the industry is cheerfully turning those features on because they are genuinely useful. The thesis of this issue: the migration is trivial, but keeping the migration trivial is real, ongoing engineering work that nobody is budgeting for.
What actually forked
Start with the facts, because the marketing on both sides obscures them. HashiCorp relicensed Terraform from MPL-2.0 to the Business Source License in August 2023. Five days later the OpenTF manifesto went up, signed by over 120 companies, and by September the Linux Foundation had adopted the project as OpenTofu. IBM then bought HashiCorp for 6.4 billion dollars, closing in February 2025. OpenTofu joined the CNCF in April 2025, keeping its MPL-2.0 license under special exception. As of mid-2026 Terraform is at the 1.14 line under IBM, OpenTofu shipped 1.12.0 on May 14, 2026. Both are actively developed by well-funded teams. They are not the same tool anymore.
The governance split is the part everyone writes about, and it does matter: BSL prohibits building "a competitive offering," which is vague enough that GitLab's legal team concluded they were exposed and deprecated their Terraform CI/CD templates in GitLab 18.0. If you are in EU procurement, OSI-approved MPL-2.0 saves you a documented justification that BSL now requires. Fine. But governance is a decision you make once, with your lawyers, and then live with. The technical divergence is different. It compounds silently, in your config files, every time an engineer reaches for a feature that solves a real problem.
The features are one-way doors, not just checkboxes
Here is where the "same tool" story breaks. Look at what OpenTofu shipped that Terraform's open-source CLI does not have.
Native state encryption, since OpenTofu 1.7, encrypts the state client-side before it ever reaches a backend, with AWS KMS, GCP KMS, and passphrase key providers. Terraform has no equivalent; it leans entirely on backend-level encryption. This sounds like a pure win, and for security it is. But read the compatibility note carefully: once you enable OpenTofu state encryption, those state files become unreadable by Terraform. That is not a governance preference. That is a file your other tool physically cannot parse. You have walked through a door and the handle is gone on the far side.
terraform {
encryption {
key_provider "aws_kms" "prod" {
kms_key_id = "arn:aws:kms:eu-west-1:111122223333:key/..."
region = "eu-west-1"
key_spec = "AES_256"
}
method "aes_gcm" "prod" {
keys = key_provider.aws_kms.prod
}
state {
method = method.aes_gcm.prod
}
}
}
Ship that block, run one tofu apply, and your state is now OpenTofu-only. Nobody made a strategic decision. An engineer closed a security ticket.
Early variable evaluation, since OpenTofu 1.8, lets you use variables inside the backend configuration block. Anyone who has fought Terraform's -backend-config gymnastics across environments knows why people want this.
terraform {
backend "s3" {
bucket = "state-${var.environment}"
key = "app/tofu.tfstate"
region = var.aws_region
}
}
That is valid OpenTofu and a hard syntax error in Terraform. The moment it lands in a module, that module is OpenTofu-only, and it fails the instant a Terraform user runs init against it. Ephemeral values (OpenTofu 1.11) that live only in memory and never touch state, OCI registry sources for providers and modules (1.10), native S3 state locking without a DynamoDB table (1.10) using use_lockfile = true: each is a feature you adopt to solve a concrete problem, and each nudges your configuration off the shared dialect.
The drift runs the other direction too, and it is worse because it is architectural. Terraform Stacks went GA in September 2025 and orchestrate multiple components as one lifecycle unit, but they live only in HCP Terraform and use .tfstack.hcl files OpenTofu cannot read. Sentinel, HashiCorp's policy-as-code engine, has no OpenTofu equivalent; if you build a compliance program on Sentinel policies, migrating means rewriting all of them in OPA or Checkov. Project Infragraph wires Terraform state into IBM watsonx, Ansible, and OpenShift. Adopt any of these and you have not configured a tool, you have married a platform.
The overlap is large today, and shrinking on a schedule
The honest counterweight is that the common subset is still enormous. Providers are the shared bedrock: the OpenTofu registry lists more than 3,900 providers, all independently licensed, and they work with both tools. State files remain binary-compatible between Terraform 1.5.x and OpenTofu in both directions, with the single exception of encryption. Most HCL you write today parses cleanly on either side. This is why the Fidelity swap worked and why yours probably would too, right now.
But "right now" is doing a lot of load-bearing work in that sentence. The overlap is not a stable equilibrium. It is a high-water mark that recedes every release. OpenTofu 1.12 added dynamic prevent_destroy and import-by-identity in May. Terraform's 1.14 line keeps building toward Infragraph. Neither team is trying to preserve cross-compatibility as a design goal anymore, because they are competitors now, not the same project with two maintainers. The syntax overlap is large the way two languages that split from a common ancestor are still mutually intelligible for a while. Give it enough releases and you need a translator.
The practical consequence is that the cost of switching is not fixed. It is a function of how many fork-specific features you have adopted, and that number only goes up unless you actively hold it down. A team that has used nothing but the 2024 common subset can still swap in an afternoon. A team that turned on state encryption, moved backends to early-evaluated variables, and built a Sentinel policy library has three separate one-way doors to unwind before they can even start. Same tool on the surface. Completely different migration bill.
Yes, but Fidelity proved it is trivial at scale
The strongest objection is the one I opened with: an enterprise moved 50,000 state files and reported the CLI swap was the easy part. Does that not disprove the whole "one-way door" worry?
No, and the detail is instructive. Fidelity migrated from Terraform to OpenTofu, which is the direction the compatibility currently favors, because OpenTofu was built to read Terraform's formats. They also reported hitting exactly the blockers this issue is about: Terraform Cloud workspaces that OpenTofu cannot connect to, Sentinel policies with no equivalent, and the general truth that "the complexity lives in the surrounding ecosystem." Their own words describe latched doors, not open ones. What made their migration tractable is that they were leaving the platform-integrated tool for the portable one, and they were willing to do the organizational work of rewriting what did not port.
Try it in reverse. Take a shop that has been on OpenTofu for two years with state encryption enabled and early-evaluated backends across 300 modules, and ask them to move to Terraform for an IBM integration mandate. The CLI swap is still trivial. Everything else is a rewrite. The lesson of Fidelity is not "migration is easy." It is "migration is easy in the compatible direction if you budget for the ecosystem, and the ecosystem is where the fork-only features bite."
What to do on Monday
Stop treating the tool choice as reversible by default, because your config is quietly making it irreversible. Two concrete moves.
First, pick the tool on governance grounds now, not on the feature comparison, and not "later." The features leapfrog each other every quarter and will keep doing so; the license and the owner will not change. If you are outside the IBM ecosystem and not locked into HCP Terraform, OpenTofu's OSI-approved license removes a category of procurement and compliance questions, and its security features are currently ahead. If you run Red Hat, watsonx, and hybrid cloud through IBM, Terraform's roadmap is converging with your stack and the integration is real. Decide on that axis, because it is the axis that is actually permanent.
Second, if you want to keep the option to switch, treat every fork-only feature as a deliberate commitment with a sign-off, not a default an engineer flips to close a ticket. Grep your configs for the latches: encryption blocks, variables inside backend blocks, .tfstack.hcl files, Sentinel policies, OCI module sources. Each one is fine to adopt, on purpose, knowing it is a one-way door. What you cannot afford is to find out you walked through five of them the week a mandate forces you to switch. The terraform to tofu swap will still be one line. Whether you can actually run it depends on how carefully you spent the last two years of releases.
