How to Migrate From Terraform Cloud (HCP Terraform) to Spacelift

When it comes to changing products, the biggest obstacle is often migration. Yes, the product looks amazing, but once you start thinking about all the work involved in migrating from the old to the new, you abandon the idea.

A painless migration would stop you from missing out. Think of how Apple enables painless device upgrades: You simply keep your old phone next to your new one for less than an hour, and everything migrates.

Terraform Cloud (TFC), now integrated into HashiCorp Cloud Platform (HCP) as HCP Terraform, switched to a RUM (Resources Under Management) pricing model. But this model is unsustainable for many customers, as it will be tough to predict what their bill will look like at the end of the month. You can read more about the changes here.

Migrating from Terraform Cloud is easier than enduring their new pricing model, so we developed a migration kit called liftoff to speed up the process.

What we will cover:

1. Why migrate from Terraform Cloud?
2. Overview of Spacelift features
3. Getting started with liftoff
4. How to migrate from Terraform Cloud

There are several reasons why you would want to migrate from Terraform Cloud:

1. Pricing

Terraform Cloud’s RUM pricing is unpredictable and will cost you a lot. Even if you sign a yearly deal for several resources, you will still end up paying for things TFC doesn’t manage. Pay-as-you-go usage is calculated hourly based on the peak number of managed resources in that hour, while committed plans require teams to estimate future usage.

2. Terraform-only management

With TFC, you can only manage Terraform and, to some extent, Terragrunt. You can’t customize the binary, nor can you use other tools such as Pulumi, CloudFormation, or OpenTofu. This means that you will need other products to manage other parts of your infrastructure.

3. No dependencies workflow

With TFC, you can’t create dependencies between your workspaces, nor can you natively share outputs between them, making environment promotion impossible to implement.

4. Limits for policies and run tasks in lower tiers

In the lower pricing tiers, you can create one policy set with five policies in it, and only one of these policies can be mandatory. Similarly, you can integrate only one run task for 10 workspaces.

This is highly limiting, and you won’t be able to do the job with these kinds of limits, forcing you to switch to the next tier.

5. Don’t have full control over your workflow or over the tools you are integrating

With TFC, you can’t fully control what happens between all runner phases, and you are limited to integrating only the third-party tools that are supported by run tasks.

6. No-code provisioning is limited to modules

No-code provisioning is a really helpful feature for achieving self-service infrastructure. However, TFC limits the self-service aspect only to your modules, which makes the whole aspect kind of limiting.

Usually, in your automations, you use multiple modules in a single configuration, which means you work around this issue by creating a “module” of modules, which in Terraform isn’t a best practice.

This will also force you to push the “module” of modules to your registry, making things even more complicated and confusing, especially for new people in your organization.

7. HashiCorp support

Many people are complaining about the level of support they receive from HashiCorp whenever they encounter issues. You can read more about their support issues in this Reddit thread.

8. HashiCorp license changes

HashiCorp’s move to BSL, followed by its acquisition by IBM, has also increased uncertainty around Terraform Cloud (TFC).

If HashiCorp’s license change is part of why you are leaving, the move is also a good moment to switch from Terraform to OpenTofu, the open-source fork. 

The Migration Kit generates Terraform or OpenTofu code, and you pick the workflow tool when you create the stack, so switching does not add a separate migration. Spacelift runs OpenTofu natively, so there is no penalty for making the change. See our OpenTofu page for the details.

Read more: Why You Should Migrate From Terraform Cloud/Enterprise

Spacelift is the infrastructure orchestration platform for the AI-accelerated software era, supporting Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Kubernetes, and Ansible. The platform’s pricing is predictable and based on concurrency, allowing you to correctly appreciate how your bill would look at the end of the month.

Being a multi-infrastructure orchestration platform allows you to integrate multiple tools into the same workflow by creating dependencies and sharing outputs between configuration stacks, making it easy to achieve environment promotion and making each configuration item small to easily isolate where issues are actually coming from.

Spacelift uses OPA for policy as code and lets you define policies to control various aspects of the platform, from what resources you can create, what parameters those resources may have, how many approvals you need for a run, where to send notifications, what happens when a PR is open, and more.

For self-service infrastructure, Spacelift offers Templates and Blueprints, which can configure every aspect of your stack, starting from what repo to use, which integrations to attach (cloud/policies/contexts) to defining input variables that will be available in a form for people to add when they are running the template or blueprint.

Beyond traditional infrastructure-as-code workflows, Spacelift Intelligence adds an AI-powered layer for natural-language provisioning, diagnostics, and operational insights, helping teams move faster without sacrificing governance or visibility.

liftoff is Spacelift’s new migration tool that helps you move infrastructure-as-code estates from Terraform Cloud or Terraform Enterprise to Spacelift, with more sources on the roadmap.

With liftoff, you pull your source estate into a local store, audit the selected resources, and then transform those targets into OpenTofu code that uses the Spacelift provider. This configuration is then published to a Spacelift admin stack, which creates the equivalent resources in Spacelift. The data unavailable through normal read-only discovery will also be captured, and Lifoff will push the state and sensitive values to the migrated stacks.

liftoff has several useful properties:

• It’s distributed as a single static binary (you don’t need any Docker container)
• Discovery is read-only and safe to re-run
• Migrations can be divided into batches
• Generated OpenTofu code can be reviewed before it is applied
• All steps are idempotent, meaning that if something gets interrupted or fails, you can rerun the operations safely
• Source mutations are explicit and limited to the capabilities you approve 

Liftoff can be used in three ways:

• Through the CLI with an AI coding agent, which is also the recommended way
• Through the beta browser interface
• Directly through the CLI by following the documentation yourself

Before starting to use Liftoff, there are some prerequisites you have to follow:

1. You need a Spacelift account and an API key with root-space admin access
2. You’ll need an Admin user token for Terraform Cloud or Terraform Enterprise
3. A Spacelift VCS integration that can access every repository you need
4. At least one available Spacelift Worker
5. A VCS token for your private modules

To create a Spacelift API key, you can go to Settings → API keys and generate one:

For Terraform Cloud, you need to go to Account Settings, then choose Tokens, and in the end, create an API Token:

The migration follows these steps:

1. Set up and Configure: What you need before you start (workspace initialization, picking a source, setting credentials, and validating the connections before running anything)
2. Discover: Pulls the whole estate into a local store, read-only
3. Batch: Lists what’s in the estate and stages the units to migrate in this batch
4. Audit: What it found over the stage set (you might have to repair some things yourself or the AI agent)
5. Generate: Renders the OpenTofu configuration for this batch
6. Publish: Hands the configuration to Spacelift as an Admin stack and applies it
7. Mutate: Captures the secret values
8. Finalize: Marks the batch as migrated, then loops back to the Discover stage for the next batch

You can follow the docs if you want to go step by step on how to perform the migration, or, better yet, you can use an AI agent like Claude Code or Codex to do it for you, which is the recommended way.

You can easily copy the docs with a single button, feed them to your agent, and it will start the migration process for you.

By using an AI agent, it will figure out how to install Liftoff for you and go step by step, asking for your input.

For example, at the end of the Publish step, a proof token will be printed for the plan it just showed. Your AI Agent won’t be able to do anything with it, so in order to confirm the run, you will need to open a terminal and run this command (don’t worry, the agent will tell you exactly what this command is):

liftoff publish --confirm --proof-token <token from the plan>

Check out this video for an example migration from TFC to Spacelift:

Most of what you have in Terraform Cloud has a direct equivalent in Spacelift, and the liftoff maps the bulk of it for you. If you are mapping things by hand, or you just want to know where each piece lands, use the table below.

Terraform Cloud (HCP Terraform)	Spacelift	Notes
Organization	Account (with a root Space)	Top-level container. Spacelift nests Spaces beneath it.
Project	Space	Spaces form a tree and inherit resources from parent to child, unlike flat TFC projects.
Workspace	Stack	A stack ties together a repo, branch, directory, and tool, and can run Terraform, OpenTofu, Pulumi, CloudFormation, Kubernetes, or Ansible.
Workspace variables	Stack environment	Set as environment variables, TF_VAR_ variables, or mounted files on the stack.
Variable sets	Contexts	Reusable collections of variables and files you attach to many stacks.
Sentinel or OPA policy sets	OPA policies	Written in Rego and applied across the lifecycle: login, access, push, plan, approval, and notifications.
Run triggers	Stack dependencies	Create dependencies between stacks and share outputs between them, which makes environment promotion straightforward.
Run tasks	Workflow hooks	The closest equivalent. Control what runs before and after each phase, and bring your own runner image.
No-code provisioning	Blueprints and Templates	Self-service forms that provision governed infrastructure without writing Terraform.
Private module registry	Module registry	Publish and version modules for your teams.
Agents and agent pools	Worker pools	Use Spacelift-managed workers, or self-hosted workers in your own account, including on-premises or air-gapped setups.
Teams and permissions	Spaces with RBAC roles	Combine Spaces with role bindings, plus login and access policies, to control who can do what.
Remote state	Managed state	Spacelift stores and manages the Terraform state for each stack.

A few of these are not one-to-one. Run tasks become workflow hooks, which give you more control over each phase than run tasks do. And sensitive variable values cannot be read back out of Terraform Cloud, so you set those in Spacelift after the stacks exist (see step 11).

This automation makes it easier to migrate from one vendor to Spacelift by getting the existing configuration and state and mapping it to Spacelift resources. We know that Terraform Cloud’s new pricing model is causing problems, so we really wanted to build something that will make it quicker for you to migrate to a product that offers more for less.

To learn more about the advantages of migrating from Terraform Cloud to Spacelift, check out our Terraform Cloud alternative page.

Liftoff helps you automate this migration, and by leveraging an AI agent, you’ll move faster while staying in control, since the agent is instructed not to make any mutations without your approval. If you want to learn more about Spacelift or need help with the migration, book a demo with one of our engineers.