How to Migrate from Terraform Cloud to OpenTofu

Disclosure. Scalr runs both Terraform and OpenTofu and was a founding contributor to OpenTofu, so we have a commercial interest in teams choosing platforms that support both. The ordering advice below applies whichever platform you pick, and the section on picking one names the alternatives.

Can Terraform Cloud run OpenTofu?

No, and that is the whole reason this migration is more complicated than it sounds. HCP Terraform's workspace settings document a single "Terraform Version" field that takes an exact version or a version constraint. The Workspaces API exposes one matching terraform-version attribute. HashiCorp's own overview page states that HCP Terraform runs the Terraform CLI. OpenTofu is not mentioned on any of them.

So "migrate Terraform Cloud to OpenTofu" is two separate moves wearing one name: you are changing where runs execute, and you are changing which binary executes them. Teams that treat it as one move usually discover the split halfway through, at the point where they have OpenTofu working on a laptop and no shared state to put it on.

Which should you change first, platform or engine?

Platform first. Almost always.

The argument is about reversibility. If you move workspaces to a platform that runs both engines while everything is still on Terraform, you get to verify the platform move on its own terms: same engine, same configuration, plans should match. Then you flip the engine one workspace at a time, with state already sitting where you want it and a run history to compare against. Two changes, each one independently reversible.

Do it the other way and you spend the middle of the migration in the worst available position. OpenTofu runs locally or in your own CI, state is wherever you parked it, and there is no shared run history to diff against when a plan surprises you. Every problem in that window has two candidate causes.

There is one case for engine-first: you are a small team, you already run everything through your own CI, and HCP Terraform was only ever holding state. Then the engine switch is the smaller change and you may not need a platform at all yet.

What is the actual sequence?

1. Export every state file. Before touching anything, run terraform state pull > terraform.tfstate per workspace, or script the State Versions API for anything above a few dozen. Deleting an HCP Terraform workspace deletes its state, and there is no documented recovery path. Our guide to exporting state from Terraform Cloud covers the CLI, API, and UI routes, including why terraform init -migrate-state does not work in the outbound direction.
2. Inventory what does not travel. Sensitive variable values are write-only in HCP Terraform, so they never come back out. Sentinel policies need rewriting in Rego. Note any workspace using Stacks or no-code modules, because those have no OpenTofu equivalent and need a decision rather than a migration.
3. Recreate workspaces on the target platform, still on Terraform. Migration tooling reads your HCP Terraform organization through an API token and rebuilds workspaces, variables, and state. The migration effort and timeline guide covers what each vendor's tool does and does not move.
4. Verify with the engine unchanged. Run plans side by side until results match. This is the checkpoint that makes step 5 safe, and skipping it is how engine problems and platform problems get diagnosed as each other.
5. Switch the engine, one workspace at a time. Start with something low-stakes. tofu init -upgrade rewrites the lock file against OpenTofu's registry, then tofu plan tells you whether anything in the configuration depends on a Terraform-only feature. If the plan reports no changes, apply. The next state write swaps the terraform_version marker for OpenTofu's; resource entries are untouched.
6. Pin both versions and move on. The current releases as of July 28, 2026 are Terraform 1.15.8 and OpenTofu 1.12.5.

The OpenTofu vs Terraform comparison has the engine-level migration detail for step 5, including the failure modes that show up afterwards.

What breaks, and what does not?

Not much breaks, which is the useful thing to know before you plan for six months.

State survives. The file format is compatible and the resource entries are identical; only the version marker changes. The provider situation needs one check rather than a project: OpenTofu resolves unqualified provider addresses against registry.opentofu.org by default instead of registry.terraform.io, so tofu init -upgrade rewrites your lock file and you want to confirm every provider you depend on is available there first.

Two things reliably cost real time, and neither is the engine. Re-entering sensitive variables scales with how many secrets you have, and it is the moment to consider replacing them with OIDC dynamic credentials so there is nothing static left to migrate next time. Rewriting Sentinel policies in Rego scales with policy complexity. Both of these are platform-migration costs, not OpenTofu costs, and they would apply if you moved to another Terraform platform and never touched the engine.

The version-string problem is the one that catches people later rather than during. After the fork, "1.6" identifies a different binary depending on which engine you mean, so a policy or a report that checks a version number no longer tells you which engine ran. If you are going to operate a mixed fleet for any length of time, make the engine a first-class attribute in your policies instead of inferring it from a version.

Which platform should you move to?

Automated TFC migration is standard across this category rather than a differentiator, so pick on pricing model and workflow fit. What matters for this particular migration is narrower: whether the platform runs OpenTofu as a first-class engine, and whether it lets a single account run both at once so you can move workspace by workspace.

Scalr, Spacelift, env0, and Harness all support both engines in the same account. Scalr sets the engine per workspace through an iac_platform setting that takes terraform or opentofu, and its own documentation supports Terraform through 1.5.7 and directs anything newer to OpenTofu, which makes OpenTofu the path for staying current rather than a side option. On Scalr's platform OpenTofu is now the majority engine, around 63% of runs and 72% of newly created workspaces as of mid-2026.

For the wider comparison, the decision guide for replacing Terraform Cloud weighs the platforms against each other, and selecting a Terraform Cloud alternative covers the shortlist in more depth. If the licensing question is what started this for you, is Terraform still open source has the current state of the license files.