How to Migrate Off Terraform Cloud: A Platform Engineer's Decision Guide (2026)

If you're reading this, something probably forced the question: the legacy HCP Terraform free tier reaching end-of-life on March 31, 2026, a renewal quote that tracked your resource count instead of your usage (if you're still weighing whether to switch at all, start with should you renew Terraform Cloud?), or a procurement review triggered by IBM's acquisition of HashiCorp. Whatever the trigger, you now own a decision that affects every team that ships infrastructure through your platform.

Here's the short version. Teams replacing Terraform Cloud in 2026 land on one of four paths: Scalr if they want a drop-in replacement that preserves the remote backend workflow with run-based pricing; Spacelift if they orchestrate Pulumi, CloudFormation, or Kubernetes alongside Terraform; env0 if FinOps visibility is the priority; or self-hosted Atlantis if zero license cost matters more than governance features. The rest of this guide is the reasoning (what to require, how the options compare, what migration actually involves, and how the cost math works) so you can defend the choice in front of your security team and your CFO. If you're still deciding whether to leave at all, the stay-or-go framework weighs the reasons to go against the legitimate reasons to stay. Once you've decided, the migration effort and timeline guide scopes the work.

Why are platform engineers replacing Terraform Cloud in 2026?

Four drivers come up in nearly every migration conversation:

The free tier is gone. HashiCorp's legacy HCP Terraform Free plan reached end-of-life on March 31, 2026. The replacement free experience caps out at 500 managed resources. A single EKS cluster with networking, IAM, and add-ons consumes that quickly. Teams that built real workflows on the free tier now have to pay RUM rates or move.

RUM pricing decouples cost from value. As of early 2026, HCP Terraform's published tiers are Essentials at $0.10, Standard at $0.47, and Premium at $0.99 per resource per month. The bill grows with the size of your state files, not with how much you use the platform. A team that doubles its managed resources doubles (or more) its bill, even if run volume stays flat. We've broken down the full model in our Scalr vs Terraform Cloud pricing analysis.

This is rarely abstract for the teams involved. One regulated financial-services team we spoke with this spring was staring at a footprint about to jump sharply, partly organic growth, partly absorbing another company's infrastructure, and their resource-based bill tracked that jump one-for-one, even though much of the growth was lightweight access-management entries rather than new infrastructure. They'd already decided to leave before the evaluation even started. The open questions were which platform to land on, and whether the migration would finish before the next renewal. It wouldn't, so they budgeted one final renewal as a migration cost.

No OpenTofu, no Terragrunt. HCP Terraform runs Terraform only. If your organization is hedging against the BSL license by adopting OpenTofu, or has teams standardized on Terragrunt, Terraform Cloud can't run those workloads at all.

Concurrency and feature gates. Essentials caps concurrency at 3 runs, Standard at 10. Policy enforcement on the Free tier is limited to a single policy set of up to five policies; connecting policy sets to a VCS repo or the API requires Standard or Premium. The features platform teams need for governance, like SSO, audit logging, and meaningful policy-as-code, push you up the tier ladder, and that multiplies the per-resource rate.

None of this means Terraform Cloud is a bad product. It pioneered the category, and its native HashiCorp integration is still the tightest pure-Terraform experience. But the pricing model and the IaC lock-in are structural, not fixable with a discount.

What should you require in a Terraform Cloud replacement?

Evaluate candidates against these seven requirements before you look at a single feature matrix:

1. The CLI workflow must survive. Your engineers run terraform plan and terraform apply against a remote backend today. A replacement that forces a new workflow (GitOps-only, custom CLI, new mental model) turns a migration into a retraining project. Only a true remote operations backend preserves this.
2. A documented state migration path. State is the one thing you cannot recreate. The platform needs tooling to pull state from HCP Terraform and import it per workspace, at whatever scale you're running.
3. Pricing that scales with usage, not inventory. If you're leaving because of RUM, don't adopt a model with the same failure mode. Run-based, concurrency-based, and deployment-based models all behave differently. Model each against your actual numbers (see the cost section below).
4. Policy enforcement on every tier. If policy-as-code is gated behind an enterprise tier, your governance posture depends on your budget. Prefer OPA (an open standard, written in Rego) over proprietary policy languages, so your policies stay portable.
5. OpenTofu support. Even if you're on Terraform today, OpenTofu support is your hedge against future licensing changes. It costs nothing to have the option.
6. RBAC and SSO without upsells, and a clear price on the compliance tier. Custom roles and SAML belong on day one and shouldn't force a tier jump. For a SOC 2 or ISO 27001 audit you'll also want exportable audit logs and SCIM provisioning. On most platforms, Scalr included, those sit on an enterprise plan, so put that tier in your cost model up front instead of discovering it at renewal.
7. Evidence of migration timelines. Ask vendors for references with workspace counts and dates. "Most teams migrate in under a week" should be backed by named customers, not aspiration.

How do the main Terraform Cloud alternatives compare?

Scalr operates as the same kind of remote operations backend as Terraform Cloud: runs execute remotely, state lives in the backend (or, on the Enterprise plan, in your own S3, GCS, or Azure bucket), and the Terraform CLI works unchanged. That's what "drop-in replacement" means concretely: your engineers don't learn a new workflow. On top of that base: OPA policies with pre-plan and post-plan checks (pre-plan failures don't consume a billable run), 147 granular permissions for custom RBAC roles, free drift detection, native Terragrunt run-all, and an MCP server that lets AI assistants like Claude and Cursor query your workspaces directly. All core features are included on every tier, including the free one. A handful of enterprise add-ons (SCIM, bring-your-own state storage, audit log export) sit on the Enterprise plan. The full comparison lives in our guide to selecting a Terraform Cloud alternative.

Spacelift is the right call if you genuinely orchestrate multiple IaC tools. Running Pulumi, CloudFormation, and Terraform through one platform is a real advantage that Scalr doesn't offer. The tradeoffs: a GitOps-centric model that's a bigger workflow change coming from TFC, and concurrency-based pricing that's harder to forecast for bursty workloads. We've written a detailed Terraform Cloud vs Spacelift comparison.

env0 (rebranding to "env zero") pairs multi-IaC support with strong cost-management features and good developer self-service. If your FinOps team is the loudest voice in the evaluation, it's worth a look. Note that env0's free tier has ended and pricing is now plan-tiered rather than usage-metered. As of mid-2026, the entry plan starts at $1,500/month for up to 100 active environments, with higher tiers custom-quoted. Check carefully which governance features sit on which tier, and model which tier your environment count actually lands you in.

Atlantis is free, open source, and self-hosted, genuinely the right answer for a single team that wants plan/apply automation in pull requests and has someone willing to operate it. Budget for the total cost: hosting, scaling, patching, and upgrades typically consume 0.5–1 FTE, and while Atlantis does ship server-side Conftest (OPA) policy checking, you'll be assembling RBAC, audit trails, and drift detection from other tools. Those gaps become blockers around your first compliance audit or your fifth team. (If your team likes the Atlantis workflow, note that Scalr supports the same PR-comment commands (/scalr plan, /scalr apply) so you can keep the ergonomics.)

DIY pipelines (Jenkins, GitHub Actions, GitLab CI wrapping Terraform) work until they don't. The inflection points are predictable: the first compliance audit, the third team onboarded, the first production incident from an unreviewed apply. Every hour spent maintaining custom Terraform tooling is an hour not spent on the platform capabilities your teams actually asked for.

What does migrating off Terraform Cloud actually involve?

Less than you'd think, if you sequence it right. The workflow on a drop-in replacement is identical, so migration is a data-moving exercise, not a re-platforming. The sequence:

1. Export your state files first. Before touching anything else, pull state for every workspace via terraform state pull or the HCP Terraform API. Workspace deletion in HCP Terraform is unrecoverable. If you lose state, your resources keep running in your cloud account with no way to manage them through Terraform.
2. Inventory workspaces, variables, and team access. Most teams discover stale workspaces here. Migrate what's live; archive the rest.
3. Recreate workspaces and import state. Automated migration tooling can read your HCP Terraform organization and recreate workspaces, VCS connections, and variables on the target platform. Our migration guide walks through the Scalr tooling step by step.
4. Re-enter sensitive variables. HCP Terraform doesn't export sensitive values. This is the one genuinely manual step. Budget time for it, or use the migration as the moment to switch to OIDC dynamic credentials and eliminate static secrets entirely.
5. Rewrite Sentinel policies in Rego. If you used Sentinel, policies need translation to OPA. Most teams find their policy set is smaller than they remembered, and Rego is an open standard you keep regardless of platform.
6. Cut over gradually. Point one environment's CLI configuration at the new backend, run plans side by side until results match, then repeat per environment. On a drop-in replacement, the cutover is a backend block change, and the rest of your Terraform configuration is untouched:

terraform {
  backend "remote" {
    hostname     = "<account>.scalr.io"
    organization = "<environment-id>"
    workspaces {
      name = "network-prod"
    }
  }
}

There's no big-bang moment: workspaces still on HCP Terraform keep working while migrated ones run on the new backend.

Timelines from real migrations: small teams finish in a day or two; teams with 500+ workspaces have completed migrations to Scalr in under a week. Ably and TV4 have both written up their experiences. For a full breakdown of the phases, the automated tooling each platform offers, and the genuinely manual steps, see what it takes to migrate off Terraform Cloud.

What does replacing Terraform Cloud cost?

Work the math with your own two numbers: resources under management and runs per month.

Take a mid-size platform team: 1,000 managed resources, 200 workspaces, 500 runs per month. On HCP Terraform Standard at $0.47 per resource, that's roughly $470/month before you've run anything, and the bill grows every time application teams ship new infrastructure, whether or not run volume changes. On Scalr's run-based model, the same team pays for 500 runs, with volume discounts on prepaid packages and a $0.99/run flex rate beyond them, and the bill doesn't move when the resource count doubles.

RUM punishes large, stable estates; run-based pricing punishes nothing-but-churn workloads. If you manage a big inventory that changes infrequently, the most common platform-team profile, run-based pricing wins decisively. If you run constantly against a tiny estate, model both before assuming.

Three second-order effects that don't show up in the headline rate:

• Drift detection is free on Scalr. Scheduled drift checks don't consume billable runs, and they're available on every tier. On HCP Terraform, health assessments (drift detection and continuous validation) are a paid capability gated to higher tiers rather than something every plan includes.
• Failed checks don't bill. On Scalr, runs that fail at pre-init, Checkov scanning, or pre-plan OPA checks aren't billable. You don't pay to find out a change violates policy.
• No feature-gate multiplier. Every Scalr tier, including the free 50-runs/month tier, has the core governance features: OPA policies, custom RBAC, SSO/SAML, drift detection. The "we need SSO, so we need Premium, so every resource now costs 10x" math doesn't exist. (Audit log export, SCIM, and bring-your-own state storage are Enterprise-plan features.)

Which Terraform Cloud alternative should you choose?

The decision rules, condensed:

• You run Terraform/OpenTofu and want the same workflow with predictable pricing → Scalr. It runs as the same kind of remote operations backend as Terraform Cloud, which is what makes it a drop-in replacement.
• You orchestrate Pulumi, CloudFormation, or Kubernetes alongside Terraform → Spacelift, and accept the workflow change and concurrency-based pricing.
• FinOps tooling is your top evaluation criterion → env0, after checking tier gates against your governance needs.
• One team, zero budget, ops capacity to spare → Atlantis, with a plan for what happens at your first audit.
• You're tempted to build it yourself → re-read the inflection points above, then price the FTE.

If the drop-in path fits, the evaluation is cheap to run: Scalr's free tier includes 50 runs per month with every core feature enabled, so you can migrate a real environment (state, policies, RBAC, drift detection) and judge it against your actual workloads before committing. Start with the migration guide, and export your state files today regardless of what you choose.