Migrate from Terraform Enterprise to Terrakube: what the move involves
Moving from self-managed Terraform Enterprise to Terrakube is a platform swap plus a state move, carried out workspace by workspace. The platform team usually leads it, often with an implementation partner, because the work touches run infrastructure, state storage, identity and every repository that triggers runs. The replacement has two parts: the IaC CLI, which can be OpenTofu or Terraform under the Business Source License, and a run and state platform. Terrakube is the run platform here. It supports both the remote backend and the cloud block, so existing cloud or backend "remote" configurations can point at a Terrakube API hostname after a terraform login (or the equivalent OpenTofu login) against that host. Terrakube is licensed under Apache 2.0, which removes the license and patch cycle you carry today, but you still own installation, upgrades, database backups and the Dex identity setup.
The effort scales with two things you can count now: the number of workspaces and the size and age of their state. For each workspace, plan the state export through the state versions API, the recreation of variables, VCS connections and team permissions, and a verification plan-only run against the new backend before any apply. Confirm with Terrakube's maintainers or your own test environment which Terraform Enterprise objects it does not import, so you know what must be re-created by hand. Terraform Enterprise is quoted on custom pricing, so you cannot compare running costs from public figures. Ask your HashiCorp account team for a written quote covering your current subscription and support, then compare it against your own infrastructure, storage and staffing estimates.
Decide early whether the CLI moves to OpenTofu at the same time or later. Switching the binary while changing the backend doubles the number of variables in a cutover, so many teams separate the two and first prove the backend with the Terraform version they already run. If you do change the CLI, OpenTofu's migration guidance describes a safe and reversible sequence: back up state and code, install OpenTofu, initialize and verify the configuration, then test with a small change. Configurations that read other workspaces through the terraform_remote_state data source need extra care, so inventory them first. OpenTofu's state encryption, with key providers such as AWS KMS, is a decision to make before state lands in the new store, not after. Keep the Terraform Enterprise instance read-only until every workspace has run successfully on Terrakube, and keep its state downloads archived until your retention policy allows deletion.
Which Terraform Enterprise capabilities map to Terrakube, and which need rework
This table compares the main Terraform Enterprise capabilities with their Terrakube equivalents and marks each as clean, needs rework or gap. Use it to scope the migration before you touch any workspace, and treat every Terrakube entry as something to confirm in a test organization first. The main takeaway is that state, the CLI workflow and VCS retrieval move with the fewest changes, while policy, identity and run extensions need design work.
| Capability | Terrakube status | What changes and what to confirm |
|---|---|---|
| Organizations and workspaces | Clean | Terrakube models organizations and workspaces, so the structure can be recreated. Confirm naming, workspace settings and how each one maps to a configuration directory. |
| Remote runs and cloud block | Clean | Terrakube supports the cloud block and remote backend, so runs can start from the Terraform or OpenTofu CLI. Confirm that your Terraform version meets the cloud block requirement or use the remote backend for older versions. |
| State storage and migration | Needs rework | State is exported through the state versions API from Terraform Enterprise and imported into Terrakube. Verify checksums and plan a locked window for each workspace. |
| Terraform variables and variable sets | Needs rework | Variables and sensitive values must be re-entered or loaded by script. Confirm how Terrakube stores sensitive values and whether variable sets are supported in your version. |
| VCS connections | Needs rework | Terrakube reads code from GitHub, GitLab, Bitbucket and Azure DevOps. Each connection, webhook and branch trigger must be recreated and tested. |
| Private registry | Needs rework | Terrakube provides a private registry for modules and providers. Module sources and version constraints in configurations must be updated to the new host. |
| Teams and permissions | Needs rework | Terrakube assigns permissions on workspaces, modules and VCS connections by group. Map each Terraform Enterprise team to a group and confirm the permission levels line up. |
| SSO and identity | Gap | Terrakube uses Dex with providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML. Confirm that Dex can federate with your enterprise identity setup before cutover. |
| Sentinel policy checks | Gap | Sentinel policies do not port directly. Each policy must be rewritten as an Open Policy Agent check and validated against sample plans. |
| Run extensions and cost estimation | Needs rework | Terrakube extensions provide OPA policy checks and Infracost cost estimates. Confirm which Terraform Enterprise run tasks you use and rebuild each one as an extension or API integration. |
What exports cleanly and what must be re-created by hand
Terraform Enterprise holds state, but much of what surrounds a workspace lives as configuration in the platform. Plan for state to move through the API, and for variables, teams, VCS links, SSO and integrations to be rebuilt and checked in the target system.
State through the state versions API
Current state is the piece that must move intact. The state versions API exposes a JSON download for states created by Terraform 1.3 or later, which is the cleanest export path. Older state versions may only offer a raw download, so check which format each workspace's state uses before you start. Pull the state, confirm its serial and resource count against a fresh plan, and keep the export as a backup until the target has a successful run.
Older states need a separate check
Workspaces whose state was created before Terraform 1.3 do not all expose the same JSON download. Confirm in your own Terraform Enterprise version which download URLs each state version returns. Where only a raw download is available, verify it parses correctly and run a no-change plan in Terrakube before cutting over, since a damaged or mismatched state is the hardest failure to undo.
Variables and workspace settings
Workspace variables, including sensitive values, are stored in the platform and are often not readable through the API once set. Expect to re-enter sensitive variables from your secrets source, and record every non-sensitive variable and setting per workspace in a migration sheet. Confirm with your Terraform Enterprise administrator which variable fields the API returns in your version.
Organizations, teams and access
Organizations, teams, and their workspace permissions do not carry over as a bundle. Recreate the organization and workspaces in Terrakube, then map each Terraform Enterprise team to a group that Terrakube checks through Dex. Assign permissions on workspaces, modules and VCS connections by group, and confirm that no workspace is left with broader access than it had before.
VCS connections and integrations
Each VCS link to GitHub, GitLab, Bitbucket or Azure DevOps must be created again with new credentials and webhooks. Terrakube documents integrations with these four providers, including GitHub Enterprise and GitLab EE and CE, so confirm which variant you run. Also rebuild SSO through Dex, notification destinations, and any run tasks or extensions such as OPA policy checks, since these are configuration in the source platform rather than data.
Cross-workspace dependencies
Workspaces that read outputs through the terraform_remote_state data source depend on the backend location and workspace name. After migration, those references must point at the new backend, and the producing workspace must be migrated first. Map every consumer before cutover, because a renamed workspace breaks the consumer's next plan without any change to its code.
The migration sequence from inventory to decommission
This sequence moves each Terraform Enterprise workspace to Terrakube one at a time, keeping Terraform Enterprise authoritative until each workspace has proven itself, so that the team ends with a verified, backed-up record and a clean shutdown of the old platform.
Inventory every workspace and its dependencies
The platform owner lists every organization, workspace, state version, variable set, VCS connection, team permission and private registry module in Terraform Enterprise. The inventory also records every terraform_remote_state data source that reads another workspace's outputs, since those consumers break if a producer moves first. Ask your Terraform Enterprise administrator to confirm which workspaces use the cloud block and which use the remote backend, because the cutover step differs. The step is done when the inventory is reviewed by the workspace owners and every consumer has an assigned owner.
Stand up Terrakube and test it on a pilot workspace
The platform team installs Terrakube using the Helm chart or Docker Compose route described in its documentation, connects its database, and configures Dex with your identity provider. Choose one low-risk workspace with no downstream consumers and no sensitive variables. Recreate its organization, variables, VCS link and team access in Terrakube, then export its current state through the state versions API of Terraform Enterprise. The pilot is done when a plan from the Terraform CLI against Terrakube matches the Terraform Enterprise plan with no unexpected changes.
Decide on OpenTofu at the same time or later
Decide whether the pilot runs Terraform or OpenTofu. Running both changes in one move makes a failure harder to isolate, so many teams migrate the platform first and the CLI second. If you move to OpenTofu now, follow the migration overview's four steps: back up state and code, install OpenTofu, initialize and verify the configuration, then test with a small change. OpenTofu describes this process as designed to be safe and reversible. Record which version each workspace runs, because the done check is a clean init and plan under the chosen binary.
Run Terrakube in parallel with Terraform Enterprise
For each migrated workspace, Terrakube plans against the copied state while Terraform Enterprise stays authoritative and continues to apply. Compare each Terrakube plan with the Terraform Enterprise plan for the same commit, and investigate any difference in resources, variables or provider versions before proceeding. Also verify that terraform_remote_state consumers still read correct outputs from the Terrakube-managed producer. The parallel run is complete when several planned changes have matched and the workspace owners sign off in writing.
Cut over one workspace at a time
For each workspace, freeze applies in Terraform Enterprise, take a final state download, and confirm the state checksum matches the copy in Terrakube. Then update the cloud block or remote backend configuration to point at the Terrakube API hostname, and run terraform login against that hostname to store credentials. Run a plan first, then apply a small change so the new state path is proven. The cutover is done when the workspace shows a successful apply in Terrakube and the old Terraform Enterprise workspace is set to read-only for that configuration.
Retire Terraform Enterprise after verified backups
Once every workspace is cut over, confirm that state, configuration, variable inventories and run history are archived in storage you control. Keep the Terraform Enterprise instance read-only for an agreed retention period set by your compliance owner, and confirm that no pipelines or consumers still call its API. Only then remove its license, shut down the instance and revoke its tokens. The step is done when the archive has been restored to a test location and an independent reviewer confirms the record is complete.
What drives the effort and how to keep it down
This table lists the factors that most change how much work a Terraform Enterprise to Terrakube move takes, with a control for each. Read it before scoping, because the same workspace count can produce very different effort depending on dependencies, state and identity setup. Costs are split into one-time work and recurring platform costs, so the quote request can be compared line by line.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Workspace count | Each workspace needs its own state export, variable set, VCS link, team permissions and cutover check, so effort grows with the list. | Group workspaces by owning team and migrate in waves, starting with low-risk, non-shared stacks. |
| Cross-workspace terraform_remote_state dependencies | Workspaces that read another workspace's outputs must move in a sequence, and a changed backend can break a consumer that is still pointing at the old source. | Map the dependency graph before cutover, migrate producers first, and freeze consumer changes until both sides are verified. |
| State file size and age | Large or long-lived states take longer to download, validate and re-upload, and old states may hold resources no longer in code, which adds drift review. | Run a plan with no changes against each exported state, and clean up drift in the source before exporting. |
| VCS and identity complexity | Each VCS connection, group mapping and SSO setting must be recreated in Terrakube, and Dex group permissions do not copy over automatically. | Document every team-to-workspace permission before the move and test one login path per group in a non-production instance. |
| Same-time or later OpenTofu adoption | Moving the platform and the CLI together means two sets of changes in one window, while a later switch keeps the first cutover smaller. | Move to Terrakube on Terraform first if the team needs a small change, then switch the CLI to OpenTofu in a separate, reversible step. |
| Run extensions and policies to rewrite | OPA checks, cost estimates and custom scripts tied to Terraform Enterprise run tasks or Sentinel must be rebuilt and tested against sample plans. | Inventory every policy and run task, then rebuild the highest-risk ones first and keep a list of any control you have not yet reproduced. |
| One-time costs | Setup, Helm or Docker Compose configuration, exporting and re-creating objects, testing, and cutover planning are paid once per migration. | Ask the quote for a fixed scope with named workspaces, and separate setup from rebuild work so each can be reviewed. |
| Recurring costs | Terrakube hosting, the relational database, backups, upgrades and the platform staff who run them continue after cutover. | Ask the quote for ongoing support as a separate line, and confirm who owns patching, backup restore tests and Terrakube version upgrades. |
What usually goes wrong and how to prevent it
Most failed Terraform Enterprise to Terrakube cutovers do not fail on the first run. They fail because state moved while something else was still writing to it, or because a configuration outside the migration plan still depended on the old workspace. The cards below cover the risks that recur most and the check that catches each one before cutover.
State drift between export and cutover
A state file exported from Terraform Enterprise is a snapshot. If anyone applies to that workspace after the export, the copy in Terrakube is stale and the next plan will propose changes that reverse live work. Before cutover, freeze applies in the source workspace, export state again, and confirm the serial and lineage match what Terrakube holds. Run a plan in Terrakube that shows no changes before you re-enable any pipeline.
Second writer during parallel runs
Running Terrakube and Terraform Enterprise side by side is useful for verification, but two platforms that can apply to the same state will corrupt it or overwrite each other. Disable the VCS triggers, webhooks and scheduled runs in the old platform for every migrated workspace, and remove any personal CLI configuration that still points at the old cloud block. Record the owner of each workspace so that one person decides when the write path changes.
Lost variable sensitivity and secrets
Terraform Enterprise hides the values of sensitive variables after they are saved, so a plain export of variables may not return them. Teams often discover this only when a run fails for a missing database password or API token. Inventory every sensitive variable and its source (a password manager, a secrets manager or a CI secret), and re-enter or inject each one into Terrakube as a sensitive variable. Confirm that the values are masked in run logs before any apply.
Broken terraform_remote_state consumers
Configurations that read another workspace's outputs through the terraform_remote_state data source break when the producing workspace moves, because the backend address and access rules change. OpenTofu's migration guidance warns that these configurations typically need additional care. Map every consumer before the first cutover, decide whether it moves in the same wave as its producer, and update the backend settings and access permissions in Terrakube so reads succeed on the first plan.
Identity mapping errors after Dex setup
Terrakube uses Dex for sign-in and assigns workspace, module and VCS permissions by group. If the identity provider sends group names that differ from the ones you created, users either see no workspaces or see more than their role allows. Compare the group claims from a test login with the team list you recreate in Terrakube, and confirm that the owner of each workspace can still approve and apply before you remove the old team memberships.
Assuming Sentinel policies run unchanged
Sentinel policies in Terraform Enterprise do not execute in Terrakube. Any policy check that gates applies must be rewritten, typically in Rego for Open Policy Agent, and tested against sample plans before it is trusted. Until the replacement exists, decide whether the workspace can apply without that gate, and document the approval step that replaces it so auditors can see that no change went unchecked.
How the move differs by starting point
A single team with a handful of workspaces and one VCS connection usually has the smallest migration. Most of the effort is exporting state, re-creating a few variables and reconnecting one repository to Terrakube. Because the number of objects is small, a team can migrate workspace by workspace and keep Terraform Enterprise running until each one plans cleanly.
- State export: Download each workspace's current state through the state versions API, then confirm the serial and resource count match before switching.
- Variables: Recreate sensitive and environment variables by hand. Terraform Enterprise does not reveal stored secret values, so keep the originals in your own secrets store.
- VCS link: Create one connection to GitHub, GitLab, Bitbucket or Azure DevOps and point each workspace at the right branch.
- Backend switch: Update the
cloudblock orbackendconfiguration in each root module, then runterraform initand a plan with no changes expected. - Cutover: Choose whether to move to OpenTofu at the same time. Keeping the same CLI first makes it easier to isolate problems.
Confirm your Terraform Enterprise version and the CLI version pinned in each repository before you export, since state formats and cloud block behavior depend on them.
A multi-team estate with a shared private registry, team-scoped access and policy checks has more moving parts. The migration order matters because modules and providers in the private registry are consumed by many workspaces, and a change to a module source can break several teams at once. Plan the registry move and the access model before moving the first production workspace.
- Registry first: Recreate private modules and providers in Terrakube's built-in registry and update module sources and version constraints in a test branch.
- Teams and permissions: Map Terraform Enterprise teams to groups, then assign permissions on workspaces, modules and VCS connections by group.
- Identity: Connect Terrakube to your identity provider through Dex, and confirm group claims arrive as expected before granting access.
- Policy: Translate Sentinel policies into a second check, such as OPA in a Terrakube extension, and run both in parallel for a period.
- Shared state: Identify any workspace that reads another workspace's outputs, since those dependencies must move in a coordinated order.
Confirm how many workspaces share each module, which policy sets apply to which workspaces and whether your Terraform Enterprise database can be exported with the data you need.
An air-gapped or regulated deployment changes where the work happens. Terrakube is installed inside your network with a Helm chart or Docker Compose, so images, chart dependencies, providers and modules must come from inside the controlled boundary. Terraform Enterprise often runs in the same kind of environment, so this path is usually about replacing the platform without changing the trust model.
- Installation source: Mirror the Terrakube container images and Helm chart into your internal registry, and test a minikube or equivalent cluster before production.
- Database: Terrakube uses any relational database that Liquibase supports, such as PostgreSQL, MySQL, Oracle or SQL Server. Confirm which one your organization operates and who backs it up.
- Providers and modules: Mirror the OpenTofu Registry content you depend on, or host providers internally, since a disconnected network cannot fetch them on demand.
- Encryption: Decide how state and plan files are protected, including OpenTofu's client-side encryption with a KMS or OpenBao key provider where that fits your controls.
- Evidence: Record the change, the export checksums and each cutover decision for your assessors.
Confirm your Terraform Enterprise version, its database engine and version, and whether your change process requires a documented rollback before cutover.
Questions teams ask before moving off Terraform Enterprise
How much effort and cost does moving from Terraform Enterprise to Terrakube involve?
The effort depends on how many workspaces, variables, VCS connections and modules you run, and on how much of the existing setup is automated. The cost has two parts. One-time costs include planning, exporting and re-creating workspace settings, testing plans against the new platform and cutting over each workspace. Recurring costs include the infrastructure that runs Terrakube, the database it needs, state storage, backups, upgrades and the people who operate the platform. Your Terraform Enterprise quote is custom, so ask your account team for the license terms you would still owe during a parallel run. Ask any implementation partner for a fixed-scope quote that lists workspaces, deliverables and acceptance tests in writing before work starts.
How long does a Terraform Enterprise to Terrakube migration take?
The duration is driven mainly by workspace count, how interdependent the workspaces are, and how strictly you gate each cutover. Workspaces that share outputs through the terraform_remote_state data source need more care and should move in dependency order. Other drivers include the number of VCS connections to re-establish, the number of Sentinel policies to translate, whether you also move to OpenTofu, and how many environments must pass a plan review before production. A practical gating model is to move a non-production workspace first, confirm that a plan shows no unexpected changes, then move production workspaces in batches. Ask for a timeline tied to a workspace inventory rather than a flat estimate.
What does our internal team need to provide for the move?
Your team needs to supply the people who know the workspaces and the infrastructure they manage. That includes an inventory of workspaces, their owners, current variables and their sensitivity, VCS connections and the teams that hold access. Your platform team must provide the hosting target, such as Kubernetes or Docker infrastructure, a relational database that Terrakube supports, identity provider settings for Dex, and access to the cloud accounts where state and runs execute. Someone with approval authority must sign off on each cutover and on any changes to policy checks. Security and compliance owners should review where state and encryption keys will live before any state is moved.
Can we do the migration ourselves using the state versions API and Terrakube docs?
A capable platform team can do much of the work with the Terraform Enterprise state versions API and the Terrakube documentation. Export each workspace's current state, confirm it is a state created by a supported Terraform version, configure the cloud block or remote backend against the Terrakube API hostname, and run a no-change plan. The parts that usually take the most time are re-creating variables and their secret values, rebuilding teams and permissions, reconnecting VCS, and proving that every workspace plans cleanly. If your team lacks time or experience with state handling, a fixed-scope engagement from DeployOpen can plan, implement, harden, document and test the migration inside your own infrastructure. Confirm the exact export steps against the current vendor documentation before you start.
Do we have to switch to OpenTofu at the same time as moving to Terrakube?
No. Terrakube supports both Terraform and OpenTofu, so you can change the platform first and keep the Terraform CLI while you validate each workspace. Moving to OpenTofu later is still a supported path. OpenTofu's migration guidance describes four steps: back up state and code, install OpenTofu, initialize and verify the configuration, then test with a small change, and it describes the process as designed to be safe and reversible. Doing both changes at once doubles the number of variables in a cutover, so many teams separate them. If you move to OpenTofu, check any configuration that uses the terraform_remote_state data source first, because OpenTofu's guidance flags it for extra care. Also note that OpenTofu's compatibility with future Terraform releases is not guaranteed.
What happens to our Sentinel policies and private registry modules?
Sentinel policies do not move to Terrakube. Terrakube's policy path uses Open Policy Agent through its extensions, so each Sentinel rule needs to be reviewed and rewritten in Rego, then tested against sample plans before you enforce it. Plan the policy rewrite as its own workstream with named policy owners who approve the translated rules. For private registry modules, Terrakube provides its own private registry for Terraform modules and providers. You must re-publish or re-point each module, and update module sources and version constraints in your configurations. Public community providers can come from the OpenTofu Registry, which lists more than 3,900 providers and 23,600 modules. Confirm with your module owners which modules are private and which are pulled from public sources.
Will the migration keep our state and secrets under our own control?
Yes, if you host Terrakube and its state storage inside your own infrastructure. State is the highest-risk asset in this move because it can contain secrets and resource details. Export it through the state versions API using credentials with the least access needed, then store it in a backend you control and restrict access by group. If you move to OpenTofu, its state and plan encryption feature encrypts state at rest for local storage and remote backends, using key providers such as AWS KMS, GCP KMS, OpenBao, Azure Vault or PBKDF2. Decide your key provider before the first state import, and record who holds the keys. Security reviewers should also confirm how Terrakube's Dex-based identity and group permissions map to your existing access model.
What should we confirm before cancelling Terraform Enterprise?
Confirm that every workspace has a verified plan on Terrakube, that state has been exported and checked, and that variables, teams, VCS connections and policies all work as expected. Keep the Terraform Enterprise environment available until each workspace has run through at least one normal change cycle on the new platform, because rollback depends on it. Ask your vendor and your contract owner about notice periods, data retention and any final export windows before you give notice. Keep a dated record of each cutover, the approvers and the backup locations for your auditors. DeployOpen can prepare the controls and evidence for a compliance assessment, but independent auditors and certification bodies issue any audit report or attestation.
What to confirm with Terraform Enterprise and Terrakube before you start
Start by pinning down the facts about your current Terraform Enterprise installation, because they decide which export path and which Terrakube release you can use. Record your exact Terraform Enterprise version from your installation's admin console or release notes, and confirm the Terraform CLI version each workspace runs. Check that every workspace's state is stored in state versions that you can download, and confirm the state format: the state versions API documents a JSON state download URL only for states created by Terraform 1.3 or later, so older states need a separate plan. Verify these details against the HCP Terraform API: State versions reference and against your own admin tooling, not from memory.
Next, confirm the platform dependencies on the Terrakube side. Terrakube supports any relational database that Liquibase supports, such as PostgreSQL, MySQL, Oracle and SQL Server, so confirm which engine your platform team will run, whether it is in your support matrix and who holds the backup and restore duties for it. Map each identity provider group that currently grants access in Terraform Enterprise to a Dex connector and to the Terrakube groups that will hold permissions on workspaces, modules and VCS connections. List every VCS provider and its version (GitHub, GitLab, Bitbucket or Azure DevOps, cloud or self-managed), because Terrakube's integration depends on it. Ask the Terrakube project and your VCS administrators to confirm compatibility for those exact versions before you commit.
Finally, decide which Terrakube release you will pin. The latest release in the researched facts is 2.33.2, released on September 14, 2026, and the Terrakube GitHub releases page is the place to confirm whether a newer release exists on the day you start. Pin one version in your deployment manifests, test the upgrade path in a non-production cluster, and read the release notes for database schema changes. Decide at the same time whether you will move to OpenTofu now or after the cutover, and confirm that your planned OpenTofu release is compatible with the Terraform features your configurations use. Write these decisions down as the input to your written scope, since they set the order of the workspace cutover.
How DeployOpen scopes, runs and supports the migration
DeployOpen is a Chainscore Labs company that plans and implements self-hosted open-source platforms inside your own infrastructure. The cards below follow one engagement from written scope through cutover and ongoing support, so you can see what is agreed before any workspace moves.
Written scope before any workspace moves
Every engagement starts with a written scope listing the workspaces, state files, variable sets, VCS connections and teams in play. Work begins only after scope, deliverables and timelines are agreed in writing. Ask for the inventory method in the scope, including how workspaces that use the cloud block versus the remote backend are identified, and which ones are excluded.
Quote follows the scope
DeployOpen does not publish a price list. A quote follows from the written scope, so the number of workspaces, state size, the number of identity groups and VCS integrations you need carried over are the variables that shape it. Ask for the quote to separate one-time migration work from any recurring support you decide to add.
Build, integrate and harden the target
DeployOpen plans and installs Terrakube in your own cloud account, data center or air-gapped network, using the Helm chart or Docker Compose options documented by the project. Integration covers the relational database, Dex identity settings, VCS connections and the private registry. Hardening is agreed in the scope, and you should confirm which settings the platform team will own afterwards.
Cutover, rollback and state checks
Each workspace moves through a documented sequence: download state through the state versions API, verify it, switch the backend, then run a plan that should show no changes. Keep the old Terraform Enterprise workspace locked until the new runs succeed. The written plan should name who signs off each cutover and how a workspace returns to its previous backend if a plan shows unexpected changes.
Backups, upgrades and documentation
Engagements can include backup of the Terrakube database and state storage, a tested restore procedure, and written runbooks for operators. Upgrades of Terrakube and the OpenTofu CLI are handled as separate change items, so you can see what changes between releases. Confirm the backup frequency, retention and restore test cadence in the scope rather than assuming a default.
Ongoing support as a retainer
After cutover, support, upgrades and continuous testing can run under a retainer agreed separately from the migration scope. A retainer suits teams that lack an in-house platform owner for Terrakube or that need upgrades tracked against OpenTofu releases. Ask what response expectations are written into the retainer, and whether it covers the OpenTofu CLI version pinned in your repositories.
