A constraint allowing Terraform 1.6
Past the fork point, so state may not come back
terraform {
required_version = ">= 1.6.0"
}Terraform to OpenTofu Migration Checker
Find out what actually has to change to run OpenTofu. Usually the configuration needs no edits at all, and the lock file, the state and where runs happen are the whole job.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Check. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
An HCP Terraform workspace
The one thing that does not port, and it decides the shape of the whole migration
terraform {
cloud {
organization = "acme"
workspaces {
name = "prod"
}
}
}A configuration pinned at 1.5
At the fork point, so state moves both ways while you decide
terraform {
required_version = "~> 1.5.0"
backend "s3" {
bucket = "my-state"
}
}Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Migrating without copying state first
State written by Terraform 1.6 or later may not be readable by OpenTofu, and once OpenTofu writes it, Terraform may refuse it. There is no downgrade path.
Instead:Run terraform state pull > before-tofu.tfstate and keep it. It is the only way back.
Keeping the old lock file
Its entries are keyed by registry.terraform.io, and OpenTofu resolves unqualified providers against its own registry, so the entries do not match what it installs.
Instead:Delete it, run tofu init, then tofu providers lock with a -platform flag per platform, and commit the result.
Treating a cloud block as something to fix later
It is the HCP Terraform integration, so state and runs both live there. It is not a line to edit, it is where the whole migration is decided.
Instead:Move to a standard backend first, as its own migration, then change tools.
OpenTofu forked from Terraform 1.5.x, and that is what decides reversibility
Moving is generally straightforward. Coming back is the part with no guarantee, and the fork point is why.
State from Terraform 1.6 or later may not come back
Both projects understand state at the 1.5 format. State written by Terraform 1.6 or later can use format details OpenTofu does not know, and once OpenTofu has written the state, Terraform may refuse it in turn. Take a copy before the first apply with either tool: that file is the only route back.
The version numbers overlap and mean different things
OpenTofu 1.6, 1.7 and 1.8 are not Terraform 1.6, 1.7 and 1.8, and each has features the other does not. So required_version = ">= 1.6.0" is satisfied by both and no longer tells a reader which tool the configuration needs. Say which one the repository targets in its README and enforce it in CI, because the constraint cannot.
The lock file has to be regenerated
Every entry is keyed by a full address such as registry.terraform.io/hashicorp/aws, and OpenTofu resolves unqualified providers against registry.opentofu.org instead. Delete the file, run tofu init, then run tofu providers lock with a -platform flag for every platform you use, because a fresh init records only the one it ran on.
A cloud block is the decision, not a detail
The cloud block is the HCP Terraform integration: state, runs and policy all live there, and OpenTofu is not that. If you have one, work out where state and runs will live before anything else, and treat moving to an S3 or GCS backend as its own migration to do first.
Standard backends port unchanged, and OpenTofu-only features do not port back
S3, GCS, azurerm and the rest are the same in both projects with the same arguments. State encryption and for_each on a provider block are OpenTofu features with no Terraform equivalent, so adopting them closes the door: fine once the decision is made, worth avoiding while it is still a trial.
The binary changes and the environment variables do not
The command is tofu, .terraformrc becomes .tofurc and terraform.d becomes tofu.d, with the old names still read as a fallback. TF_VAR_, TF_LOG and the rest are unchanged, which is why a half-migrated pipeline can look like it is working. Search for the terraform command rather than the word, and check every wrapper script and Makefile target.
More terraform tools
Terraform Validator & Formatter Does it parse, and is it formatted? Terraform dynamic Block Generator It is ingress.value, not each.value Terraform check and precondition Generator A failed check does not stop the apply Terraform variables.tf Generator From the var. references you already wrote Terraform Unused Declaration Linter Dead variables, locals and data sources Terraform Atlantis YAML Generator when_modified misses your modules Terraform Function Tester and HCL Console terraform console, in a tab Terraform for Expression Tester Where do the keys collide? Terraform Interpolation Tester null becomes an empty string Terraform templatefile Tester Render it before you apply it Terraform Resource Count Calculator How many objects, not how many blocks Terraform count to for_each Converter With the moved blocks it needs Terraform moved Block Generator Rename without destroying Terraform state mv Command Builder No plan, no undo Terraform target Flag Builder And why to stop using it Terraform outputs.tf Generator Outputs are not sensitive by default Terraform Remote State Data Source Generator It grants read of the whole state Terraform Provider Block Generator docker is not hashicorp/docker Terraform .gitignore Generator and Checker .terraform* eats the lock file Terraform tfvars to JSON Converter The JSON file wins Terraform Version Constraint Parser What ~> actually allows Terraform Resource Address Parser Quote it before the shell eats it Terraform cidrsubnet Calculator newbits is added, not the target Terraform Import Block Generator The id is not the name Terraform Lock File Viewer Why CI fails and your laptop does not Terraform Variables Checker A missing value hangs CI Terraform tfvars to Env Vars Converter Lists and maps have to be JSON Terraform Deprecated Syntax Checker What a current Terraform rejects Terraform State File Viewer Read it without uploading it Terraform Plan JSON Viewer It is not redacted Terraform HCL to JSON Converter And what the conversion loses Terraform Module Source Validator version only works for the registry Terraform Backend Config Decoder Is state actually locked? Terraform Naming Convention Validator A hyphen makes a resource unreferenceable