Should You Migrate Off Terraform Cloud? A Stay-or-Go Framework (2026)

"Should we leave Terraform Cloud?" is a different question from "where should we go?" — and it deserves its own answer first. Switching the platform that manages all of your infrastructure carries real cost and real risk, so the move only makes sense when the reason is structural. This guide is the stay-or-go framework: what genuinely justifies leaving HCP Terraform, what legitimately justifies staying, and how the risks and rewards of the migration itself net out. Once you have decided to go, the decision guide covers where to land and the migration effort guide covers what it takes.

Should you migrate off Terraform Cloud?

Start with the short test. Migrate if any one of these describes you:

• Your bill is driven by inventory, not activity. HCP Terraform uses resources-under-management (RUM) pricing — every resource in your state files is billed per hour whether or not you run anything. A large, stable estate is expensive under this model and gets more expensive as application teams ship infrastructure.
• You need OpenTofu or Terragrunt. HCP Terraform runs Terraform only. If you have adopted OpenTofu to hedge the BSL license change, or teams standardized on Terragrunt, those workloads cannot run on the platform at all.
• You keep hitting concurrency limits. Lower tiers cap how many runs execute in parallel. If engineers queue during releases or incidents, that constraint scales with your team, not down.

Stay where you are if the opposite holds: your estate is small, your reasons to leave are price-of-a-discount rather than structural, or your investment in the current platform is deep enough that the switching cost outweighs the gain. The next two sections make both cases honestly.

What are the real reasons teams leave HCP Terraform?

These are the drivers that come up in nearly every migration conversation, and each is dated to what is true as of mid-2026:

RUM pricing decouples cost from value. As of mid-2026, HCP Terraform's published paid tiers are Essentials at $0.10, Standard at $0.47, and Premium at $0.99 per resource per month (Free, Essentials, Standard, Premium, and Enterprise are the current editions). The bill grows with the size of your state files, not with how much you use the platform. Doubling managed resources roughly doubles the bill even if run volume never changes. Our Scalr vs Terraform Cloud pricing analysis breaks down the full model.

The legacy free tier is gone. HashiCorp's legacy HCP Terraform Free plan reached end-of-life on March 31, 2026. It was replaced by an enhanced free tier capped at 500 managed resources — workable for a small footprint, but a single production cluster with networking, IAM, and add-ons can consume that quickly.

No OpenTofu, no Terragrunt. If your organization is moving to OpenTofu or running Terragrunt, HCP Terraform cannot execute those workloads.

Concurrency and feature gates. Run concurrency and several governance capabilities scale with the tier you pay for, which interacts badly with per-resource pricing: needing a higher tier for a governance feature raises the rate on every resource you manage.

Procurement uncertainty. IBM completed its acquisition of HashiCorp on February 27, 2025. For some teams a procurement or vendor-risk review triggered by the acquisition is what put the question on the table, independent of pricing.

None of this makes HCP Terraform a bad product. It defined the category and remains the tightest native Terraform experience. But pricing structure and IaC lock-in are design choices, not negotiables.

What are good reasons to stay?

A credible framework names the cases where leaving is the wrong call:

• A small or stable estate. If your managed-resource count fits comfortably under the 500-resource enhanced free tier, or sits low enough that RUM pricing stays cheap, the cost driver that justifies most migrations does not apply to you.
• Heavy Sentinel investment. If you have a large library of Sentinel policies, those need rewriting in Rego (OPA) on most alternatives. A deep policy estate raises the switching cost enough to be worth weighing — see enforcing policy as code in Terraform for what that translation involves.
• Tight HashiCorp ecosystem coupling. If your workflow leans on native integration with other HashiCorp products, the most seamless-on-paper integration is the first-party one. Weigh whether an alternative's integrations cover your real dependencies.
• No appetite for any switching cost right now. Migration is days of work, not months, but it is not zero. If you are mid-incident-season or pre-audit, deferring a quarter is a legitimate choice.

If you are staying, the productive move is to model your 12-month resource trajectory so the decision is revisited on data, not deferred indefinitely.

What is the risk-reward of migrating?

The migration's risks and rewards are concrete enough to put in a table. Every risk here has a standard mitigation.

Risk	Severity	Mitigation
State loss (workspace deletion in HCP Terraform is unrecoverable)	High	Export every state file via terraform state pull or the API before deleting anything in TFC
Downtime during cutover	Low	Cut over one environment at a time; keep TFC live until each is validated
Re-entering sensitive variables (TFC cannot export them)	Medium	Budget time, or switch to OIDC dynamic credentials and remove static secrets entirely
Sentinel → Rego policy rewrite	Medium	Most policy sets are smaller than expected; Rego is portable across platforms
Integration and credential remapping	Medium	Inventory integrations during the pilot; use IAM role delegation instead of static keys

Reward	What it changes
Cost tracks activity, not inventory	A large, stable estate stops getting more expensive as it grows
OpenTofu and Terragrunt become available	Removes the IaC lock-in that RUM pricing sits on top of
No concurrency ceiling on usage-based models	Runs stop queueing during releases and incidents
Governance on every tier (on platforms that offer it)	SSO, RBAC, and policy stop being a reason to pay a higher per-resource rate

The honest summary: the reward is cost predictability and removed constraints, not a longer feature list. If your estate is large and stable, the reward is decisive. If it is tiny and churns constantly, model both pricing structures before assuming — RUM can be the cheaper option in that corner case.

How do you decide? A scorecard

Turn the framework into a weighted scorecard rather than a gut call. Score each factor 1–5 for your situation:

1. Cost trajectory — how fast is your managed-resource count growing under RUM? (Higher growth → migrate.)
2. IaC roadmap — do you need OpenTofu or Terragrunt within 12 months? (Yes → migrate.)
3. Governance needs — are SSO, RBAC, or policy enforcement pushing you up the tier ladder? (Yes → migrate.)
4. Concurrency pain — are runs queueing today? (Yes → migrate.)
5. Switching cost — how large is your Sentinel estate and sensitive-variable count? (Higher → weight toward staying.)

If the first four outweigh the fifth, the decision is to go. Then de-risk the decision cheaply: run a single-environment pilot on a free tier — migrate real state, policies, and RBAC, and judge it against your own workloads before committing the rest. The migration effort guide shows what that pilot looks like in practice, and the Ably and TV4 write-ups show how the math played out for teams that left.