OpenTofu 1.13 is supported to August 2027; your state file decides the switch

What 1.13 changed and what it took away

OpenTofu 1.13.0 landed on 29 September 2026, and the project says that series carries security support until August 2027. The development window was deliberately shortened to line up with the Go release cycle, so 1.13 is a light release: official Windows ARM64 packages, the convert and assume-family functions that reduce unknown values during planning, and early experimental work on built-in linting.

The removals matter more than the additions on a Windows estate. WinRM is no longer supported for provisioners, official 32-bit builds are being phased out, base64gzip returns slightly different results, and OpenTofu on macOS now needs version 13 or later. A team that still provisions Server 2016 hosts over WinRM has upgrade work to do before it has a migration.

The support window is the part to put in a delivery plan. A series that carries security fixes until August 2027 forces an upgrade cadence on the team, and a development cycle shortened to match Go releases pulls that deadline forward rather than leaving it open.

The licence is why the fork exists

OpenTofu's FAQ is direct about the origin. The project was created by Gruntwork, Spacelift, Harness, Env0, Scalr and others in response to HashiCorp moving Terraform from an open-source licence to the Business Source License, and the FAQ argues that the additional use grant is ambiguous enough that companies cannot tell whether their own use sits inside it.

For most enterprises the licence question is not about reading the source. It is about what a platform team may build with the binary: a service that manages infrastructure for customers, a hosted internal portal, a component inside another product. Those are the cases where legal, not engineering, decides, and where a fork governed as a Linux Foundation project is easier to defend in a procurement review than a licence whose definition of competitive use can change.

None of that settles whether the licence is a problem for a particular company, which is why the question belongs to legal early rather than at the end of a migration, when the engineering work is already done and the answer cannot change the plan.

State files are the compatibility surface

Configuration travels well between the two projects. State is where they can part company. The FAQ states that OpenTofu will work with state files created up to Terraform 1.5.x, and that OpenTofu uses its own registry while working with the current Terraform providers, since it will not ship providers of its own. A team already writing state with a later Terraform release has a test to run before it has a decision.

That test is cheap and the failure is loud: either the plan is empty and the state is readable, or every resource shows as a create and the state is not. If the answer is that the state is unreadable, the choice stops being OpenTofu against Terraform and becomes whether the estate can be re-imported, or left where it is until it can.

The four commands and the rollback

The published migration guide is short and designed to be reversible. Back up the state and the configuration, install OpenTofu, run tofu init so providers come from the OpenTofu registry and the backend initialises, then run tofu plan and expect no changes or the same plan Terraform produced. If the plan differs, the guide says stop, do not apply, and investigate.

The first apply is what rewrites the state format, and it happens even when there is nothing to change in the infrastructure, which is why the guide treats it as a deliberate step rather than a formality.

backup terraform.tfstate and commit the configuration
tofu init
tofu plan   # expect no changes; stop here if the plan differs
tofu apply  # this is the step that rewrites the state format

Where the plan still lies to you

InfoQ reported in May 2026 that OpenTofu 1.12 shipped dynamic lifecycle blocks, a pattern requested in Terraform's issue tracker since the 0.7 era roughly a decade earlier, and that HashiCorp never shipped it. That is the shape of the divergence: features arrive in one project years before the other, and each addition is one more reason for the two state formats to drift apart.

Unknown values are the practical symptom. Plan-time checks reject values that cannot be known until apply, and policy tools reading a machine-readable plan are left guessing between blocking a change that would have passed and allowing one that will fail. The convert and assume-family functions let a module author state what is true instead of leaving it unknown, which is useful and also a promise: if the hint is wrong, the apply fails.

Provider lock files are the other quiet change. 1.12 moved checksum handling into the registry, so the OpenTofu Registry returns a full set of checksums in both formats, and a pipeline that builds on a shared plugin cache or a local mirror behaves differently afterwards. A pinned hash that fails to resolve is a pipeline failure on the morning of the migration, not a footnote.

The decision rule

Stay on Terraform if the licence question is already answered, if the estate depends on HashiCorp's current release cadence, or if the newest provider behaviour is a hard requirement. Move to OpenTofu if the licence is a live restriction on something the team ships, or if the state is old enough that the documented 1.5.x line is not a risk.

A pilot is the cheap middle. Copy the configuration to a branch, point it at a non-production state, and run tofu plan against it for a fortnight. An empty plan with resolved providers makes the migration a scheduling exercise. Anything else is the real cost, found before the finance paper says the licence is free.

The cost that decides the question is rarely the licence. It is the engineering weeks spent proving that a plan against a copied state is empty, and that price is the same whether the answer turns out to be yes or no.