How to easily migrate from Terraform Cloud to Scalr

The recent pricing changes to Terraform Cloud, along with the Terraform license change from Mozilla to a business source license, have driven a lot of discussion about migrating off Terraform Cloud. This post covers what you need to decide whether to move, and how to do it if you go ahead.

Migrating from one piece of software to another is never trivial, and it's harder when that software manages all of your cloud infrastructure. Usually you run a cost-benefit analysis to see whether the effort is worth the savings. We try to be transparent and fair at Scalr, so we make it easy to move in and just as easy to move out. There are two ways to migrate: with our Terraform module, or by updating your Terraform backend or code block by hand.

Cost is the other thing to weigh against the migration effort. At Scalr, the only thing we charge for is the Terraform run, nothing else. Terraform Cloud has various pricing tiers, which can make it hard to compare apples to apples, so we've built a script (see below) that calls the Terraform Cloud API to pull your Terraform run count.

The pricing model itself matters here too. Concurrency-based pricing, which some alternatives use, sells a fixed number of parallel run slots. There's no setting that works for everyone. Too few slots and engineers queue up during a release or an incident. Too many and you pay for capacity that sits idle. Usage-based, per-run pricing only charges for runs that actually executed, so there's no slot count to forecast and no cap that bites during peak load.

Similarities and Differences Between Scalr and Terraform Cloud

Before switching from Terraform Cloud, it helps to know how much work the migration takes. Scalr is the only other Terraform remote operations backend in the market, which means the migration is fairly straightforward and you won't lose the ability to use the Terraform CLI. We wrote a separate post on where Terraform Cloud and Scalr line up and where they differ.

A comparison of capabilities on specific plans for Scalr and Terraform Cloud

Run Count

The first thing to note regarding pricing is that Scalr counts a Terraform plan and a Terraform apply as a run. There are many Terraform runs you are not charged for in the event of an error, for example, any errors at the Terraform init phase. You can find out more about that here.

We have created a script that helps you estimate the number of Terraform runs that you can expect in Scalr. The script will use a Terraform Cloud API token to call the API and pull the number of total runs you have ever executed in Terraform Cloud. Unfortunately, there is not a date filter in the Terraform Cloud API so you'll have to do some estimation on how many runs were used per month or year. Based on the run count that is pulled from Terraform Cloud, you can now estimate your cost in Scalr with our pricing calculator.

Migration Decisions

Once you have decided to start a migration, you'll then want to decide what you want to migrate. Depending on when you started using Terraform Cloud, you may have a single organization with many Terraform Cloud workspaces or many organizations with many workspaces. The big decision to make is whether you are happy with your existing structure or if you want to take the opportunity to redesign the structure to potentially help with workspace isolation. Also, this is a good time to take a look at the existing Terraform Cloud workspaces to determine if they are still needed and if you want to create a new workspace in Scalr.

The Terraform state file has to move, so that part isn't a question. Terraform variables and environment variables are, though.

Then there's who does the migration. For smaller teams, it's often practical for a cloud infrastructure team to move all of the existing state files over with the module. In larger organizations, it can make more sense to let workspace owners do it at their own pace.

During a phased migration like this, the platform team can watch progress from Scalr's account-level fleet reports. These break down resources, modules, providers, Terraform and OpenTofu versions, drift, and stale workspaces across every workspace, plus queued runs and pending approvals. Scalr is a drop-in Terraform Cloud alternative, so every workspace maps directly from its TFC counterpart and reads as native Terraform or OpenTofu objects. That makes it easy to see which teams have moved over, spot a team that is stuck, and step in to raise a quota, fix a policy, or unblock a run.

If you are going to have a slower migration, Scalr's Free plan covers 50 runs each month at no cost, and the Business plan starts at $99/month — so you can swap workspaces out of Terraform Cloud and into Scalr at your own pace and not have to worry about high costs.

Terraform Migration Module

If you already run Terraform for everything else, you can use it to migrate from Terraform Cloud to Scalr too. Our migration module uses Terraform Cloud and Scalr API tokens to move the following objects:

• A Terraform Cloud organization will become a Scalr environment keeping the same organization name.
• A Terraform Cloud workspace will become a Scalr workspace keeping the same workspace name.
• Variables, both Terraform and environment variables, will be converted to Terraform and Scalr shell variables.
• The existing state file will move from a Terraform Cloud workspace to a Scalr workspace.

When executing the Terraform module referenced above, the module will create new workspaces and environments in Scalr, there is no need to pre-create these. You will also have the option to do a mass migration at once or choose to do specific workspaces as needed.

Screenshot of the example console output

General Terraform Migration from any Remote Backend

If you'd rather not use the module, the Terraform CLI handles the same job in a few steps. Before you start, stop all operations in Terraform Cloud so nothing updates the existing state while you migrate.

You'll also need to make sure that you have the Terraform CLI installed on your local machines or wherever you intend to run the Terraform commands.

First, you'll want to use the pull command to pull down the state from Terraform Cloud to your local machine. To do this, you'll need to ensure you have an API token for Terraform Cloud:

terraform state pull > terraform.state

Next, get the API token from Scalr using the Terraform CLI and Terraform login command:

terraform login <account-name>.scalr.io

Update the Terraform backend configuration and add Scalr as the new cloud backend. Make sure to update the fields below. The Scalr environment ID can be seen on the environment dashboard.

Execute terraform init to initialize Scalr as the backend.

Run terraform state push terraform.state to push the existing state into the Scalr workspaces. Once you log into Scalr, you will see the Terraform state in the Scalr workspace.

Note: This same process can be used to migrate local state files that do not use Terraform Cloud as a backend. In this case, you simply need to add Scalr as the backend to your Terraform code and run Terraform init to create the workspace and upload the state.

Summary

Picking a replacement for Terraform Cloud happens in stages. Start by confirming the tool is right for you and getting a feel for the effort and the practices involved before you commit. A big part of that is knowing whether your Terraform code has to change and how much your day-to-day operations shift. With Scalr, a Terraform Cloud workspace is the same concept as a Scalr workspace, so there's little to relearn.

Once that's clear, you can start the state migration, either with the Terraform CLI on a local machine or with the Scalr Terraform module to automate it.

Interested in trying out Scalr? Sign up today!