What Does It Take to Migrate Off Terraform Cloud? Effort, Timeline & Risk (2026)

The thing that usually stalls a migration after you've already decided to do it is the effort question. People picture a months-long re-platforming project. But if you're moving to a remote-backend replacement, it's a data-moving exercise that takes days, because your engineers keep running terraform plan and terraform apply exactly as they do now. This guide covers the work itself: the phases, the tooling each platform provides, the steps that stay manual, and what real migrations took. If you're still deciding whether to go, start with should you migrate off Terraform Cloud.

How long does it take to migrate off Terraform Cloud?

Days, not months, and the size of your estate matters less than you'd expect, because the work parallelizes and automates.

Two real datapoints from teams that migrated to Scalr:

• Ably ran a phased migration (recreating workspaces through the Terraform provider, then moving state across all workspaces with an API script) and cut over with approximately 20 minutes of downtime.
• TV4 migrated 1,000 workspaces and 50,000 resources using a fully automated script. After a one-week pilot in which they migrated their platform team's workspaces and dogfooded the result, they froze deployments for roughly 2 hours to perform the cutover. They noted it could have been faster with multithreading, but treated it as a one-off.

The pattern: small teams finish in a day or two; even a 1,000-workspace estate is a single-digit-hours cutover after a short pilot. What does not scale linearly with workspace count is the manual work (policy rewrites, team access, and any secrets a tool misses), covered below.

What are the phases of a Terraform Cloud migration?

Six phases, in order. The sequence is what keeps the risk low.

1. Export your state files first. Before anything else, pull state for every workspace via terraform state pull or the HCP Terraform API. Workspace deletion in HCP Terraform is unrecoverable: lose state and your resources keep running in your cloud account with no way to manage them through Terraform. How to export state from Terraform Cloud explains each method, plus the API token permission that most export scripts get wrong.
2. Inventory workspaces, variables, and access. Most teams find stale workspaces here. Migrate what's live; archive the rest. This is also the moment to decide whether to keep your existing structure or redesign it. A single TFC organization can become several environments for cleaner credential scoping and isolation.
3. Recreate workspaces, VCS connections, and variables. Automated tooling reads your TFC organization and recreates the equivalents on the target platform. If your TFC workspaces are already defined in Terraform code, recreating them can be as small as swapping the provider and a few variable names.
4. Recover or re-enter sensitive variables. The HCP Terraform API never returns a sensitive value, so migration tools recover them indirectly. As of September 2026, Scalr's script reads them from plan files and from one TFC run per cloud account, and Spacelift's liftoff reads them by temporarily switching each workspace to agent execution mode. Re-enter whatever a tool can't recover, or use the migration as the moment to switch to OIDC dynamic credentials and remove static secrets entirely.
5. Rewrite Sentinel policies in Rego. If you used Sentinel, policies translate to OPA. Most teams find their policy set smaller than they remembered, and Rego is portable across platforms.
6. Cut over per environment. Point one environment's backend configuration at the new platform, run plans side by side until results match, then repeat. There's no big-bang moment: workspaces still on HCP Terraform keep working while migrated ones run elsewhere.

Which Terraform Cloud workspace migration tool should you use?

The one your target platform ships. There are three: Scalr's open-source terraform-scalr-migrate-tfc script, Spacelift's liftoff, and env0's built-in Migration Wizard. All three scan your TFC organization through an API token and recreate workspaces, variables, and state on the target, so the tool choice follows the platform choice rather than driving it:

• Scalr ships migrate.sh in terraform-scalr-migrate-tfc. As of September 2026 it turns a TFC organization or project into a Scalr environment and each workspace into a Scalr workspace with its VCS settings, Terraform version, execution mode, working directory and auto-apply setting. It also moves variables, variable sets and state with its history, and it can migrate every workspace at once or a name pattern at a time. The Scalr migration walkthrough covers it step by step.
• Spacelift ships liftoff, which, per its documentation as of September 2026, stages the estate in batches, audits it, generates OpenTofu code for spaces, stacks, contexts and modules, applies that code from an admin stack, and then uploads and imports each workspace's state.
• env0 provides a Migration Wizard that, as of July 2026, scans your TFC organization via API token, recreates workspaces as environments, and migrates variables and state with staged cutover.

If you are comparing platforms, note that automated TFC migration is standard across this category, so the tool isn't the differentiator. Where the tool lands you is. Weigh the platforms on pricing model and workflow fit instead, which the decision guide and our walkthrough on choosing a TFC replacement both cover. HashiCorp's own tooling, by contrast, only automates migration into HCP Terraform, not out of it.

How does Scalr's migration script compare with Spacelift's liftoff?

As of September 2026, Scalr's migrate.sh and Spacelift's liftoff both move workspaces, variables, variable sets and state out of Terraform Cloud, and both can recover sensitive values. The difference is where each workspace lands. Scalr is a drop-in replacement: it keeps TFC's remote-backend model, so a migrated workspace is still a workspace your CLI and API pipelines can target. Liftoff re-platforms each workspace into a Spacelift stack, and a workspace with no VCS repository can't become a stack.

Object by object, per each tool's own documentation (read September 24, 2026):

Liftoff automates more of the data move in places. It stages the estate in batches, audits it before changing anything, resolves module versions to commits, and can convert stacks to OpenTofu on the way. Both tools still leave teams, policies and run tasks to you, and both cap Terraform at 1.5.7 unless you move to OpenTofu or supply your own image. The larger difference comes after cutover. On Scalr, a pipeline that ran terraform plan against Terraform Cloud runs it against Scalr with a new hostname. On Spacelift, runs start from Spacelift, and Spacelift itself calls the cutover "lift-and-shift by design" followed by an adoption phase for Spacelift-native workflows. If your pipelines call the TFC API or the Terraform CLI, that is the migration you are really sizing.

What is the manual effort that tooling cannot remove?

Three things stay hands-on regardless of which tool you use:

• Whatever secrets the tool can't recover. Terraform Cloud's API never returns a sensitive value, so tools recover them indirectly and some cases fall through (Scalr's script skips OIDC workspaces, for example). Re-enter those by hand or, better, replace them with OIDC dynamic credentials so there is no static secret to migrate at all.
• Sentinel policies. These need rewriting in Rego. The effort is proportional to policy-set size and complexity, not to workspace count.
• Credentials and integrations. Cloud credentials, VCS connections, and notification integrations are remapped. Using IAM role delegation instead of static keys both reduces this work and improves your security posture. Ably removed a standing AWS IAM user this way during their migration.

The headline: effort scales with policy complexity and access design, not workspace count. A thousand simple workspaces migrate faster than a hundred workspaces wrapped in intricate Sentinel policy.

What can go wrong, and how do you de-risk it?

Real migrations hit small, recoverable snags rather than disasters. TV4, migrating 1,000 workspaces, ran into pagination limits in their script, a few missing IAM roles, and stale TFC lock files, each resolved quickly. The de-risking playbook that keeps those snags from becoming incidents:

• Keep Terraform Cloud live until cutover. Migrated workspaces and not-yet-migrated workspaces coexist, so there's no point where everything is down.
• Validate with side-by-side plans. After moving state, run a plan on the new platform and confirm it shows no diff against TFC before cutting over that workspace.
• Pilot first. Migrate one team's workspaces a week ahead and dogfood them, exactly as TV4 did, so the cutover runs against a proven process.
• Freeze briefly at cutover. Lock workspaces, run the state sync one final time, run the plans once more, then merge the prepared backend-configuration changes. That freeze is the ~20 minutes to ~2 hours in the real examples above.

The cost-benefit framing in our guide to evaluating IaC platform pricing models helps put the effort against the savings. For most teams leaving over RUM pricing, the migration pays for itself well inside a single renewal cycle. Current Scalr plans are on the pricing page. When you're ready to run it, the Scalr migration walkthrough is the step-by-step.