How To: Migrate Terraform State Into Scalr
As users become more familiar with Terraform, they love the flexibility but run into issues around scalability.
Teams across the industry run Terraform for IaC deployments. People love the flexibility, but once they scale up they start running into problems.
For a DevOps administrator, the usual sticking point is central state storage. By the time you're scaling Terraform, you probably already have several state files sitting locally, in an S3 bucket, or in a remote operations backend. At some point the management, operational, and cost overhead pushes you toward better tooling.
Scalr handles the collaborative side of Terraform: state management, auditing, policy enforcement, and GitOps automation. Moving your state into it can sound like a chore, but the migration is straightforward. Here's how it works.
How do I migrate state into Scalr?
You migrate state by configuring your template to use Scalr as a remote backend. Wherever your state lives now (local, an S3 bucket, and so on), the Terraform CLI picks up the configuration change on terraform init and migrates the state to Scalr for you.
- If you are already using a remote backend you simply need to update the terraform{} block to be similar to the example below
- If you are migrating local state you need to add the complete terraform{} block similar to this example.
terraform {
backend "remote" {
hostname = "my-account.scalr.io"
organization = "my-environment" # the environment name from your Scalr account
workspaces {
name = "migrate_demo"
}
}
}Run terraform init to migrate the state and answer "yes" to the prompt. This will create the workspace and upload the state to Scalr.
terraform init
Initializing the backend...
Backend configuration changed!
Terraform has detected that the configuration specified for the backend
has changed. Terraform will now check for existing state in the backends.
Terraform detected that the backend type changed from "s3" to "remote".
Do you want to copy existing state to the new backend?
Pre-existing state was found while migrating the previous "s3" backend to the newly configured "remote" backend. No existing state was found in the newly configured "remote" backend. Do you want to copy this state to the new "remote" backend? Enter "yes" to copy and "no" to start with an empty state.
Enter a value: yes
Successfully configured the backend "remote"! Terraform will automatically use this backend unless the backend configuration changes.
Initializing provider plugins...
The following providers do not have any version constraints in configuration, so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking changes, it is recommended to add version = "..." constraints to the corresponding provider blocks in configuration, with the constraint strings suggested below.
* provider.aws: version = "~> 2.70"
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure. All Terraform commands should now work.
If you ever set or change modules or backend configuration for Terraform, rerun this command to reinitialize your working directory. If you forget, other commands will detect it and remind you to do so if necessary.In the Scalr UI you can see the workspace and the state outputs.
Want to give this a try for yourself? Sign up today! Check out the docs to learn more.
Terraform State & Backends: The Complete Guide
Learn how to set up and customize Terraform backend configs with terraform init. Step-by-step examples for remote state, workspaces, and CI/CD.