[Live Webinar] Top Questions Teams Ask When Switching from TFC/TFE

Register Now ➡️

Terraform

Why You Should Migrate From Terraform Cloud/Enterprise

why migrate from tfc

If you’re reading this, chances are you’ve hit a wall with Terraform Cloud or Terraform Enterprise. Maybe it’s the pricing model that’s eating into your budget, or perhaps you’ve found yourself wrestling with limitations that just don’t fit how your team actually works. You’re not alone.

We’ve talked to hundreds of teams who’ve made the move, and in this post, we’ll walk you through why they left, what to look for in an alternative, and how to make the migration as smooth as possible.

Why teams are moving on?

Let’s start with the elephant in the room: HashiCorp’s shift to Resources Under Management (RUM) pricing has been a wake-up call for many organizations. The model sounds reasonable in theory, but in practice, it can spiral quickly. You’re paying for every resource Terraform touches, including individual security group rules, IAM policies, and even DNS records. But infrastructure grows. The unpredictability is the real problem. You can’t easily forecast costs when every new security group rule or IAM policy adds to your bill.

Beyond pricing, there are legitimate technical limitations that become harder to ignore as your infrastructure matures:

  • Workspace dependencies don’t exist natively. If you need to pass outputs from one workspace to another, you’re stuck using workarounds like remote state data sources or external secrets managers. There’s no built-in way to say “deploy this network stack, then use its outputs to deploy this database stack.” This makes orchestrating complex, multi-tier infrastructure painful.
  • The free and standard tiers severely limit policy enforcement. You get one policy set with up to five policies, and only one of those can be mandatory. For any serious governance or compliance work, you’ll need to upgrade. The same goes for run tasks, TFC’s way of integrating external tools. One run task integration and ten workspace run tasks sound like enough until you realize only one can be mandatory. This means you’re either constantly monitoring runs manually or paying for a higher tier.
  • You can’t customize your execution environment beyond what HashiCorp provides. Want to use a specific version of a tool or integrate custom security scanners directly into your workflow? You’re limited to run tasks, which require external services and API integrations. There’s no way to bring your own runner image or inject custom tooling into the execution pipeline.
  • Support and responsiveness have been recurring complaints. When you hit a problem or need help with a complex configuration, the response times and quality can vary significantly. For mission-critical infrastructure, that’s a risk.

Finally, there’s the uncertainty. HashiCorp’s license change to the Business Source License has made some teams nervous about long-term platform stability and direction.

TFC vs TFE: What's different when you migrate?

Before we talk about replacements, it’s worth understanding what you’re leaving behind because the migration path differs slightly depending on whether you’re on Cloud or Enterprise.

  • Terraform Cloud is HashiCorp’s fully managed SaaS offering. You don’t manage any infrastructure yourself. HashiCorp handles upgrades, certificate rotations, scaling, and maintenance. Your data lives in HashiCorp’s infrastructure. This makes it operationally simple but gives you less control over data residency, networking, and compliance requirements.
  • Terraform Enterprise is the self-hosted version of the same platform. You deploy it in your own environment (on-premises or private cloud), which means you control networking, data residency, and integration points. But you also own the operational burden. You’re responsible for upgrades, backups, monitoring, and high availability. TFE provides additional enterprise features, such as audit logging and SAML SSO, but at the cost of managing the platform yourself.

When migrating from TFC, your main considerations are extracting state files and reconfiguring VCS integrations. You’re moving from a fully managed service to…something else. The good news is you don’t have infrastructure to decommission. The bad news is you’ll need to replicate the operational simplicity elsewhere.

When migrating from TFE, you have the added complexity of shutting down your own deployment. This means coordinating with infrastructure teams, ensuring proper data backups, and potentially dealing with networking changes if you’re moving to a SaaS alternative. On the flip side, you’re already used to managing infrastructure complexity, so the operational aspects of migration might feel more familiar.

In both cases, the technical migration steps (state file extraction, workspace reconfiguration, policy migration) are similar. The difference is whether you’re also dealing with infrastructure decommissioning and where your data lives.

What should you look for in a replacement?

The platform you choose should solve the problems that drove you away from TFC/TFE in the first place. Here’s what matters:

  • Predictable, transparent pricing. You need to know what you’re going to pay without spreadsheet gymnastics. Look for models based on runs, users, or flat fees rather than resource counts. This lets you scale infrastructure without worrying about surprise bills.
  • Native dependency management. Complex infrastructure has dependencies. Your new platform should let you define relationships between stacks (or workspaces) and pass outputs between them without hacky workarounds. This isn’t just about convenience. It’s about building reliable, maintainable infrastructure that deploys in the right order every time.
  • Flexible policy enforcement. You need robust governance from day one, not behind a paywall. Look for platforms that give you meaningful policy enforcement capabilities in their free or standard tiers. Policies should be expressive enough to handle real-world compliance requirements, not just toy examples.
  • Tool flexibility. Your team might use Terraform today, but what about tomorrow? Maybe you want to try OpenTofu, or parts of your infrastructure are better managed with Pulumi or CloudFormation. Your platform should support multiple IaC tools without forcing you to manage separate systems.
  • Customizable workflows. You should be able to integrate your security scanners, cost analysis tools, and custom validation scripts directly into your deployment pipeline. Look for platforms that let you bring your own containers and inject custom logic wherever you need it.
  • Real drift detection and remediation. Drift happens. Someone makes an emergency change in the console. An external process modifies resources. Your platform should detect drift automatically on a schedule and, optionally, reconcile it back to your desired state. This isn’t a nice-to-have; it’s essential for maintaining infrastructure reliability.
  • Strong support and community. When things go wrong (and they will), you need responsive support. Look for platforms with active communities, comprehensive documentation, and support teams that actually understand infrastructure challenges.

Spacelift: An alternative that checks the boxes

This is where I’d be remiss not to talk about why we built Spacelift the way we did. We’ve spoken to countless teams frustrated by the limitations of TFC and TFE, and Spacelift was designed specifically to address those pain points.

  • Pricing is straightforward. We don’t charge based on resources under management. Our model is based on features, so you can scale your infrastructure without watching costs balloon. You know what you’ll pay, and it scales predictably as your team and workload grow.
  • Stack dependencies are a first-class feature. In Spacelift, you can define dependencies between stacks and automatically pass outputs from one to another. This makes complex, multi-tier deployments simple. When your networking stack finishes deploying, Spacelift can automatically trigger your database stack with the VPC ID as an environment variable. Chain as many stacks as you need. It just works.
  • Policy enforcement is included and powerful. Even on the free tier, you get full access to our policy-as-code framework based on Open Policy Agent (OPA). You can write plan policies to validate Terraform changes, approval policies to require human review based on criteria you define, trigger policies to create complex workflows, and even custom policies for third-party integrations using custom inputs. We also include a policy library with ready-to-use examples and a policy workbench to help you develop and test policies faster.
  • Multi-tool support from the start. Spacelift natively supports Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Kubernetes, and Ansible. All with the same workflow, the same UI, the same policies. If your organization uses multiple IaC tools, you’re not managing separate platforms or patching together workflows. It’s all unified.
  • Workflow customization is unlimited. You can bring your own Docker images, add custom commands between workflow phases, integrate any third-party tool you want, and define custom policies for those tools. Need to run vulnerability scans? Cost analysis? Policy checks? Just add them to your workflow. There’s no artificial limitation on what you can integrate.
  • Drift detection and remediation are built in. Spacelift continuously monitors your infrastructure for drift on schedules you define. When drift is detected, you can automatically trigger reconciliation runs (respecting all your policies and approval workflows) or review changes manually. You get a unified view of all drifted resources across your entire organization, not just per-stack.
  • Spaces provide flexible access control. Spacelift Spaces let you create hierarchical organizational structures with granular permissions. You can give teams admin access to their own spaces without exposing the entire organization. This enables self-service infrastructure while maintaining security and governance.
  • We take support seriously. We pride ourselves on responsive, knowledgeable support. Our team understands infrastructure challenges because we live them. When you run into issues, you’re not talking to a generic support team reading scripts. You’re talking to people who know IaC inside and out.

We’ve also built a migration kit specifically to make moving from Terraform Cloud as painless as possible. It automates the process of auditing your current setup and creating equivalent Spacelift resources.

Wrapping up

Migrating off Terraform Cloud or Terraform Enterprise isn’t a decision to make lightly, but for many teams, it’s become necessary. Whether it’s the pricing model, technical limitations, or concerns about platform direction, there are valid reasons to explore alternatives.

The good news is that migration is manageable with the right planning and tooling. By carefully auditing your setup, backing up your state, and following a phased approach, you can move to a new platform with minimal disruption.

Spacelift was built specifically to address the frustrations teams experience with TFC and TFE. From predictable pricing and native dependency management to multi-tool support and powerful policy enforcement, we’ve focused on solving real problems. If you’re considering making the move, we’d love to talk. Book a demo with our team or try Spacelift for free. We’ll help you through the migration and show you what infrastructure management can look like when the platform actually works the way your team needs it to.

The best Terraform Cloud alternative

Spacelift is a Terraform Cloud alternative that works with Terraform, Terragrunt, and many other IaC frameworks. It offers a predictable pricing model and supports self-hosted on-prem workers, workflow customization, drift detection, and much more.

Learn more

The Practitioner’s Guide to Scaling Infrastructure as Code

Transform your IaC management to scale

securely, efficiently, and productively

into the future.

ebook global banner
Share your data and download the guide