Migrate from Scalr to Terrakube

How long does a migrate from Scalr to Terrakube project take, and who does it?

The move from Scalr to Terrakube is a workspace-by-workspace rebuild plus a state move, so the effort is set by how many workspaces you run, how many VCS links and variable sets they depend on, how many OPA policies you port, and how many Scalr agents you replace with Terrakube executors. No supplied source gives a typical duration for this work, so the reader should not plan around one until the inventory is finished. A renewal date or a per-run cost review usually sets the deadline, but the inventory sets the timeline. Terrakube is licensed under Apache 2.0 and runs either OpenTofu or Terraform, so the target CLI is a decision you make early rather than a blocker discovered late.

The work usually sits with the platform engineering team, which owns the workspaces, the backend configuration in each repository and the cutover. The security or compliance owner should review how state is stored, who holds access through Terrakube groups, and where any OPA policies are enforced, because those controls are often what the original Scalr setup was relied on to provide. Some organizations bring in an implementation partner for the inventory, the parallel runs and the evidence that the new platform behaves like the old one. Ask any partner for a written, fixed scope with named deliverables before work starts, and confirm who pays for hosting, executors and ongoing upgrades, since those costs continue after the migration ends.

Before you agree a schedule, ask your team to produce a written inventory: every workspace, its state backend, its VCS connection, its variables and secrets, its policy checks, and the agents it runs on. Then pick a small, low-risk workspace to move first and run a plan on both platforms until the output matches. For state, follow the OpenTofu migration steps of backing up state and code first, and check any configuration that reads another workspace's outputs, since those dependencies can force the move to happen in a particular order. Once the pilot is stable, the remaining workspaces can be grouped by team and risk. Your timeline is credible only when each group has a defined exit test.

What maps cleanly from Scalr to Terrakube, and what needs rework

This table sets each Scalr capability beside its documented Terrakube equivalent and marks whether the move is clean, needs rework, or is a gap to confirm. Read the migration note first for any row marked to confirm, because the supplied documentation does not establish parity for those features and you should not assume it.

Scalr capability	Terrakube equivalent	Migration note
Workspaces and state per workspace	Workspaces with remote backend and cloud block runs, state stored by Terrakube	Needs rework: recreate each workspace in Terrakube, then migrate state per workspace and verify with a plan before any apply
Remote backend and state access	Remote backend supports migrating state, and the cloud block needs Terraform 1.1 or later	Clean for Terraform 1.1 or later; earlier versions use the remote backend. Confirm the exact state import steps in the Terrakube documentation
CLI-driven runs	Runs started from the Terraform or OpenTofu CLI after terraform login against the Terrakube API hostname	Clean: update the backend or cloud block in each configuration and log in with the new hostname
VCS connections (GitHub, GitLab, Bitbucket, Azure DevOps)	Integrations with GitHub (cloud and Enterprise), GitLab (EE and CE), Bitbucket and Azure DevOps to retrieve code	Needs rework: recreate each VCS connection and confirm webhook and trigger behavior matches your Scalr setup
Identity and group-based permissions	Dex authentication with providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML; permissions on workspaces, modules and VCS connections assigned by group	Needs rework: map Scalr roles to Terrakube groups. Confirm that Scalr's role model, such as environment-level access, has an equivalent before you assume parity
OPA policy checks	OPA policy checks available through Terrakube extensions	Needs rework: port existing policies and confirm the extension's input format and how policy failures block an apply
Infracost cost estimates	Infracost available through Terrakube extensions	Needs rework: reconfigure the extension and confirm API keys and output handling in your environment
Private registry for modules and providers	Private registry for Terraform modules and providers	Clean for module and provider publishing. Confirm how Scalr's registry features, such as versioning rules and access controls, map to Terrakube
Agents	Terrakube executors that run plans and applies	Gap to confirm: agent pools, placement and networking are not documented in the supplied facts. Confirm executor placement and access to private networks with the Terrakube documentation
Environments and variables	Not documented in the supplied facts as a direct equivalent	Item to confirm: recreate environment grouping and variable sets in Terrakube and verify how sensitive values are stored and scoped

Which state, variables and VCS links move, and through which export path

A Scalr to Terrakube move touches five kinds of assets: state, variables, VCS connections, modules and providers, and identities with policy code. Each one has a different export path, and some cannot be copied at all, so plan each category separately before cutting over any workspace.

State files per workspace

State is the asset you cannot rebuild from code, so it moves first and is verified before anything else changes. Terrakube's remote backend supports migrating state, which gives you a target for each workspace. Confirm with Scalr the documented way to download the current state of each workspace on your plan, and confirm that the export includes every version you need for rollback. Take a backup of each state file and record its serial and checksum before and after the copy.

Variables and secrets

Plain variables can usually be exported and re-imported, but secret values often cannot be read back from Scalr once stored. Expect to re-enter most secrets from the owning team's secret store, such as a cloud secrets service or a dedicated vault. Build a variable inventory per workspace, mark which values are sensitive, and assign a named owner to each secret so cutover does not stall on a missing credential. Confirm with Scalr what its export returns for sensitive variables.

State encryption as a parallel decision

If you plan to protect state at rest after the move, decide it now rather than in a second change window. OpenTofu encrypts state and plan files for local storage and remote backends, with key providers such as AWS KMS, GCP KMS, OpenBao and Azure Vault. Choosing a key provider changes who can decrypt state during the migration, so agree on key ownership and rotation with the security team before the first workspace is re-pointed.

VCS connections and webhooks

Scalr workspaces link to repositories through VCS connections, and Terrakube retrieves code from GitHub, GitLab, Bitbucket and Azure DevOps. Recreate each connection under Terrakube's own credentials, then confirm which branch, working directory and trigger settings each workspace used. Webhooks and deploy keys belong to the repository owner, so schedule their changes with that team and test a no-op commit on each repository before removing the Scalr link.

Modules and providers in a private registry

Modules and providers published to Scalr's private registry do not move automatically. Terrakube provides a private registry for Terraform modules and providers, so republish each one with its versions and confirm that source addresses in the code resolve to the new host. Check which modules are consumed by other workspaces, because a rename or host change will break those callers first.

Identities, group permissions and policy code

Terrakube assigns permissions on workspaces, modules and VCS connections by group, using Dex with identity providers such as SAML or GitHub. Map each Scalr team role to a Terrakube group before importing workspaces, so access is not granted broadly during cutover. Export your OPA policies from Scalr and port them to Terrakube extensions, then run them against sample plans to confirm the results match.

The migration sequence, from inventory to Scalr decommission

This sequence moves each Scalr workspace to Terrakube in a controlled order, so state, variables, VCS links and policies are verified before any workspace stops running in Scalr. Each step closes with a written record that the next step depends on.

Build the workspace and dependency inventory
Export the list of every Scalr environment, workspace, variable set, VCS connection, agent pool and OPA policy, and record which workspace owns each one. Add a column for every workspace that reads another workspace's outputs through the terraform_remote_state data source, because those consumers need extra care when backends change. Assign an owner, a risk rating and a target cutover order to each row. The output is an inventory sheet that the platform team and each workspace owner have reviewed and signed off. Confirm the export options with Scalr support, since the available exports and API endpoints depend on your plan and version.
Stand up Terrakube and pilot one low-risk workspace
Deploy Terrakube in your own infrastructure using the Helm chart or Docker Compose method documented in its README, and connect it to your identity provider and VCS. Choose one low-risk workspace with a small state file and no terraform_remote_state consumers. Follow the OpenTofu migration approach: back up the state and code, install OpenTofu, initialize and verify the configuration, then test with a small, reversible change. The output is a pilot runbook with the exact commands, the backup location and the rollback steps, plus a record that a plan against the migrated state shows no unexpected changes.
Recreate environments, variables and VCS links
For each workspace in the agreed order, recreate its variables in Terrakube, including sensitive values that must be re-entered from your secrets store rather than copied from Scalr's interface. Map permissions to Terrakube groups through the identity provider, and connect each workspace to its repository through the supported VCS integrations. Port OPA policy checks to Terrakube extensions and confirm they produce the same pass and fail results on a known plan. The output is a configuration diff per workspace showing what was recreated and how each policy was verified.
Run both platforms in parallel and compare plans
Keep Scalr active for every workspace that has not yet cut over, and run plans for migrated workspaces in Terrakube without applying them. Compare the plan output from each platform against the same commit and the same state, and log every difference, including variable resolution, provider versions and policy results. Apply changes from one platform only for each workspace, so no resource is changed twice. The output is a comparison log with one entry per workspace, each marked as matching or explained, and an agreed rule for which platform applies.
Cut over each workspace's backend configuration
During a window agreed with the workspace owner, stop applies in Scalr, pull the current state through the remote backend or the state versions API, and update the backend or cloud block in the configuration to point at Terrakube. Run terraform login or the equivalent authentication against the Terrakube API hostname, then run a plan that should show no changes. Record who approved the cutover, the state version used, the commit and the result. The output is a cutover record for each workspace, and the workspace is not returned to Scalr without a documented reason.
Decommission Scalr and retire its agents
After every workspace has run successfully in Terrakube for a period your team sets, revoke Scalr API tokens, VCS app installations and service accounts, and remove Scalr agents from your hosts and pipelines. Export the Scalr audit and run history that your compliance obligations require, and store it in your records system before the account is closed. Confirm the export and retention terms in writing with Scalr before ending the subscription. The output is a decommission checklist signed by the platform owner and the security lead, with the audit export location recorded.

How to run Scalr and Terrakube in parallel without double applies

The core rule for a parallel run is that each workspace has exactly one owner of state at any moment. Until a workspace is cut over, Scalr remains the only system allowed to apply it, and Terrakube should only plan against a copy of its state. Once a workspace moves, Scalr's run triggers and VCS hooks for that workspace must be disabled before the first Terrakube apply, otherwise two systems can race to change the same resources. Confirm in your environment which Scalr workspaces have auto-apply enabled, which pull request or webhook triggers fire on merge, and who holds the credentials that could start a run in either platform. Record the owner and cutover time for each workspace in a migration tracker so there is never doubt about which side is authoritative.

Before any apply, compare plans from both systems. Run a plan in Scalr and a plan in Terrakube against the same commit and the same variable values, then diff the outputs. Differences usually come from variables or environment settings that were not recreated exactly, provider version pins, or workspace-specific data. Treat any unexpected create, update or destroy as a blocker. The cutover itself is general in shape: change the backend block in the configuration (or cloud block, where that applies) to point at Terrakube, run tofu init with state migration so the existing state is copied across, and then run a plan that should report no changes. Confirm the exact init flags and backend settings against the OpenTofu migration guide and the Terrakube CLI-driven workflow documentation for your OpenTofu and Terrakube versions.

The terraform_remote_state data source needs extra care. Consumer configurations read outputs from another workspace's state, so moving a producer workspace can break or silently change what its consumers read. Inventory every terraform_remote_state reference before cutover, then decide the order in which producers and consumers move, and whether consumers must point at the new backend in the same change window. Expect that a consumer may read a state that has just moved, and keep the old Scalr state readable until every consumer is confirmed. Ask your team to confirm which consumers exist, which are owned by other teams, and whether any of them run on a schedule that could read mid-cutover.

What drives migration cost and duration, and how to keep each down

This table lists the inputs that set the size of a Scalr to Terrakube move, why each one matters and what to do to keep it contained. Read it as a checklist for the written scope, since most of these drivers are known only after an inventory of your workspaces.

Driver	Why it matters	How to reduce it
Workspace count	Each workspace needs its state pulled, its backend switched and its runs verified, so the count sets most of the rebuild and cutover effort.	Retire stale workspaces before migration and group similar stacks into a shared template so they are rebuilt once.
Environments and variable sets	Scalr environments and shared variable sets must be recreated as Terrakube workspaces and variables, and secret values must be re-entered from a secure source.	Map environments to workspace naming early, move shared values once, and keep secrets in your existing secrets manager instead of copying them by hand.
VCS links and branch rules	Each repository connection and branch or path trigger has to be recreated against Terrakube's GitHub, GitLab, Bitbucket or Azure DevOps integration, and mismatches cause unexpected runs.	Inventory every trigger rule, consolidate duplicate repository links and test each trigger on a non-production branch before cutover.
Custom OPA policies	Policies written for Scalr must be ported to the OPA check that Terrakube extensions run, and each rule's behavior has to be proven equivalent.	Keep the policy set small, port the rules that gate production first and record expected pass and fail results for each.
Scalr agents and network placement	Agents running in private networks must be replaced by Terrakube executors that can reach the same cloud accounts, modules and private endpoints.	List each agent's network path and credentials, then size executors on the same network segments before switching any workspace.
terraform_remote_state dependencies	Configurations that read another stack's outputs through terraform_remote_state need coordinated backend changes, or a stack that moves first breaks its consumers.	Map every consumer and producer pair, move them in the same change window and follow OpenTofu's migration guidance for that case.
State encryption decisions	Choosing whether to use OpenTofu client-side state encryption with AWS KMS, GCP KMS, OpenBao or another provider adds key management work and affects who can read state.	Decide the key provider once for the platform, document key ownership and rotation, and add encryption after the first pilot succeeds.
Identity integration and group mapping	Dex must connect to your identity provider and Terrakube permissions are assigned by group, so unclear group design delays access sign-off.	Agree the group model for workspaces, modules and VCS connections before build, and reuse existing groups from your identity provider.
Target database, backup and high availability	Terrakube runs on a relational database that Liquibase supports, and its backup, restore and failover design sets both the one-time setup and the ongoing operating load.	Choose a database your team already operates, define backup and restore tests and confirm the high availability design in writing before implementation.
One-time work	Inventory, pilot, rebuild, cutover and training are paid once, but their size depends on the drivers above and on how many teams need training.	Ask for each phase as a separate line item with stated deliverables and exit criteria in the written scope.
Recurring work	Hosting, Terrakube and OpenTofu upgrades, on-call coverage and extension maintenance continue after cutover and are often underestimated.	Ask whether support or upgrades are a fixed retainer or billed as needed, and confirm who owns on-call for the platform.

What usually goes wrong when Terraform state moves between platforms

Moving workspaces from Scalr to Terrakube changes where state lives, who can start runs, and which checks fire. Most failures come from gaps that appear during that handover, not from the tools themselves. The six risks below are the ones to close before the first production run on the new platform.

Same workspace applied from two places

During cutover, the old Scalr workspace and the new Terrakube workspace can both be able to plan and apply against the same cloud resources. If a pipeline or engineer still runs against the old backend, two state files drift apart. Assign one owner per workspace and record the switch date. Disable the old workspace's run triggers and VCS connections before the new one takes its first apply. Confirm how Scalr handles locks during the freeze period with your own tests.

State moved without a verified backup

Pulling state out of any platform is a one-way step if the copy is wrong or incomplete. Before moving anything, download the current state, record its checksum, and keep the Scalr state version untouched until the Terrakube workspace has completed a no-change plan. Store the backup in encrypted storage you control. Confirm with Scalr's documentation how its state export works for your account, since the supplied facts cover HCP Terraform's state versions API, not Scalr's.

terraform_remote_state consumer breaks

Another workspace that reads outputs through terraform_remote_state points at the old backend. Once the producer moves, that consumer fails or silently reads stale values. Build a dependency map of every consumer before the move, including workspaces owned by other teams. OpenTofu's migration guide flags this case as needing additional care, so review that guide alongside your own map and update each consumer's backend configuration in the same change window.

Variables or secrets lost in re-entry

Scalr variables, including sensitive values, do not carry over automatically to a new platform. Teams often retype them by hand and miss a value, or paste secrets into a chat or ticket. Keep an inventory of every variable set, environment variable and sensitive value, noting its scope and owner. Re-enter secrets through Terrakube's variable handling and confirm with the Terrakube documentation how sensitive values are stored and masked in your version.

Policy and cost checks silently stop running

OPA policy checks and cost estimates in Scalr do not fire on Terrakube unless they are configured there. A workspace can apply successfully with no policy evaluation, and nobody notices until an audit. Terrakube extensions provide OPA policy checks and Infracost estimates, so map each Scalr policy to a Terrakube equivalent. Then run a deliberately non-compliant test change for each policy and confirm the run fails. Keep the test as a repeatable check.

Executor lacks network access

Scalr agents often run inside a network that already reaches private registries, module sources and cloud APIs. A Terrakube executor placed in a different subnet or container network may not reach the Terraform or OpenTofu provider registry, private module sources, state storage or the cloud control plane. Run a network test from the executor against each endpoint the workspaces need, including a provider download and a cloud API call, before scheduling the first migrated apply.

How the migration changes by team size and how heavily Scalr is used

A small team with a handful of workspaces that mostly run terraform plan and apply from a laptop or a CI job is usually the quickest case. The sequence is short: pull state for each workspace, recreate the environment and its variables in Terrakube, then point each configuration at the new backend. The main work item is the backend switch, since the CLI-driven workflow authenticates with terraform login against the Terrakube API hostname and uses the remote backend for states created by earlier versions.

Few environments: Recreate only the workspaces that are still in use, and archive the rest with their final state.
Variables by hand: Copy sensitive variables from Scalr through a controlled channel, not through chat or ticket comments.
Backend edit: Change each backend block once, then run a plan that should show no changes before anyone applies.
Cutover: Freeze applies in Scalr for a short window, migrate the state, and confirm a clean plan.

Before cutover, confirm that every workspace plans with no drift on Terrakube and that the CLI credentials on each engineer's machine point at the new hostname.

How much does a Scalr to Terrakube migration cost and how long does it take?

What does a Scalr to Terrakube migration cost?

The cost is set by the written scope, not by a list price. Terrakube's software is licensed under Apache 2.0, so there is no license fee for the platform itself. The costs that remain are the infrastructure to run Terrakube, the executors that replace Scalr agents, the database Terrakube uses (any relational database Liquibase supports, such as PostgreSQL), identity integration, and the people who do the work. Some costs are one-time, such as inventory, state transfer, environment rebuilding and cutover testing. Others recur, such as hosting, upgrades, backups and on-call support. Costs go up with the number of workspaces, the number of VCS connections, the complexity of OPA policies and the number of teams that need their own permissions. When you ask for a quote, request a line-item breakdown of one-time and recurring work, the assumptions behind the workspace count, and whether a retainer for upgrades is included.

How long does a Scalr to Terrakube migration take?

There is no fixed duration that applies to every organization. The timeline depends mostly on the inventory: how many workspaces you have, how many use remote state that other configurations read, how many depend on Scalr agents, how many use OPA policies and how many VCS connections need to be recreated. A small estate with clean, self-contained workspaces moves faster than one with shared state and many policy sets. The work also depends on your change windows and how many rounds of validation your teams require before cutover. Before agreeing a timeline, ask for a written inventory of workspaces, dependencies and policies, and for a schedule that shows which workspaces move in which phase and how each one is verified.

What does a migration need from our team?

The migration needs named people with access to each system involved. In practice that means administrator access to Scalr, so workspaces, environments, variables and VCS links can be exported and documented. It also means administrator rights on your version control platform, such as GitHub, GitLab, Bitbucket or Azure DevOps, to reconnect repositories and webhooks. Network access is needed between Terrakube, your cloud accounts, state storage and the VCS hosts. Identity owners must map Scalr roles to Terrakube groups, since Terrakube assigns workspace, module and VCS permissions by group and authenticates through Dex. Finally, each secret owner must confirm how credentials are rotated and which values can be re-entered in Terrakube. Agree these owners at the start, because delays in access are a common cause of schedule slip.

Can our own engineers do the migration without a partner?

Yes, a capable internal team can do it, and the path is well documented. OpenTofu's migration guide describes four steps: back up state and code, install OpenTofu, initialize and verify the configuration, and test with a small change, and it describes the process as designed to be safe and reversible. Terrakube's documentation covers the remote backend, the cloud block and the CLI-driven workflow, which needs Terraform v1.1 or later for the cloud block. The skills you need include Terraform or OpenTofu state handling, Terrakube administration on Kubernetes or Docker Compose, identity configuration, VCS integration and policy porting. The main risk is not the tooling but missing a dependency, such as a workspace that reads another workspace's outputs through terraform_remote_state. OpenTofu's guide flags that case for extra care. Ask yourself whether your team has time to run parallel validation before cutover.

Does Terrakube support OPA policy and cost checks?

Terrakube supports these checks through extensions. According to its README, extensions add tools such as OPA policy checks and Infracost cost estimates to runs, and the Terrakube API supports custom integrations. This means the checks you rely on in Scalr can usually be reproduced, but the policies themselves must be ported and tested. Confirm three things during scoping: which OPA policies exist and how they are triggered, whether the cost estimation output is used for approval gates, and whether any Scalr-specific policy features have no direct equivalent. Ask for a test run of each policy against sample plans before you rely on it for production approvals.

Does Terrakube replace our Scalr agents?

Terrakube's executors take the role that Scalr agents play in running plans and applies, but the mapping must be confirmed for your setup. Check where each agent runs, which network paths and credentials it uses, which tools and provider versions it needs, and whether any agent is pinned to a specific network segment. Terrakube runs OpenTofu or Terraform, so confirm the exact IaC version each workspace uses. Ask for a written mapping that lists each Scalr agent pool, the Terrakube executor that replaces it, the credentials it receives and the network rules that allow it to reach your cloud accounts and private endpoints.

What happens to our state if we decide to stop the migration?

Your state stays under your control if you back it up before any change and keep the Scalr copy until you decommission Scalr. The safe approach is to export current state from each workspace, store the copies in a location you control, and verify them against live infrastructure before any workspace switches backends. HCP Terraform exposes state through its API, and the same discipline applies when moving from Scalr: take a backup, record a checksum or version, and do not delete the source until the new backend has passed plans with no unexpected changes. If you pause, you can point each workspace back to its previous backend configuration. Ask for a rollback procedure per workspace as part of the written scope.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Scalr to Terrakube, we start with a written scope that maps each workspace, its state, variables, VCS links and policies before any cutover begins.

How we scope

Inventory every Scalr environment, workspace, variable set, VCS connection and OPA policy in a written scope document.
Agree in writing which workspaces move first, which stay on Scalr during parallel runs, and what counts as done.
Confirm with your team which Terraform or OpenTofu versions each workspace uses before choosing the backend configuration.
Engagements are fixed-scope, so deliverables and timelines are agreed before work starts. Ask for a written quote based on that scope.

How we build

Stand up Terrakube in your own cloud account or data center using its documented Helm chart or Docker Compose installation.
Pull state for each workspace through the source platform's state export, then verify checksums and state contents before import.
Recreate environments, variables, VCS links and group permissions in Terrakube, and port OPA checks into Terrakube extensions.
Replace Scalr agents with Terrakube executors and test each workspace with a small, reversible change before switching its backend.

How we hand over

Deliver runbooks covering backend configuration changes, state recovery steps and the rollback path for each workspace.
Document the mapping from every Scalr object to its Terrakube equivalent, including gaps that need a manual decision.
Walk your platform and security teams through access groups, identity provider setup and day-to-day run operations.
Provide evidence of migration testing and access controls that your internal reviewers or independent auditors can examine.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover, so the platform keeps current.
Plan Terrakube and OpenTofu upgrades as separate, scheduled changes with their own test runs and rollback notes.
Ask any provider, including DeployOpen, to confirm in writing who owns backups, key material and incident response after go-live.