How to migrate from Spacelift to Terrakube without a big-bang cutover
A Spacelift to Terrakube migration is a stack-by-stack move: state, configuration, run triggers, policy and identity are rebuilt in Terrakube while most OpenTofu or Terraform code stays as it is. If your renewal, a pricing change, a data residency rule or lock-in is pushing you to move, plan for each stack to be moved, verified and cut over on its own schedule rather than switching the whole estate on one date. Most teams do this with their platform engineers in charge and an implementation partner handling inventory, policy translation and cutover checks. The effort and risk depend less on the number of workspaces than on how many stacks depend on Spacelift private workers, custom runner images, contexts shared across stacks, and Rego policies attached to plan, apply or trigger points.
Start with an inventory that records, for every stack, its state location, its variables and contexts, its VCS source and branch, its trigger policies and whether it runs on a private worker. Export state first. The safest route is to run terraform state pull (or the OpenTofu equivalent) in a Spacelift task and write the file to a bucket you control, then confirm the file is complete before anything else changes. Use the state versions API for a cross-check where the state format allows it. Keep the Spacelift stack running in read-only or plan-only mode until the Terrakube workspace plans clean against the migrated state, because the first plan in the new home is the real acceptance test. Expect the Rego translation to take the longest, since Terrakube's OPA-based extension checks are not a line-by-line port of Spacelift policy hooks, so each policy needs to be re-expressed and tested against sample plan inputs. Confirm exact extension behavior with the Terrakube maintainers and your own test runs. Use the Terrakube documentation to confirm current workspace, VCS and executor settings before you rely on them.
Which Spacelift capabilities map to Terrakube and which need rework
This table compares the main Spacelift capabilities a team relies on with their closest Terrakube equivalent and rates each as clean, needs rework or gap. Read it before exporting anything: the rework rows are where stack definitions, policies and access rules have to be rebuilt by hand, and the gap rows are where a separate tool or process has to take over.
| Spacelift capability | Terrakube equivalent | Migration notes |
|---|---|---|
| Stacks | Workspaces, with the CLI-driven workflow or VCS connection | Needs rework. Each stack becomes a workspace, and settings such as working directory, branch and trigger rules must be recreated and checked one by one. |
| Managed state | Remote state held by Terrakube's remote backend, with state migration supported | Clean for Terraform or OpenTofu states. Pull state from each Spacelift stack first, then confirm each workspace plans with no changes before cutover. |
| VCS-triggered runs | VCS connections to GitHub, GitLab, Bitbucket and Azure DevOps | Needs rework. Repository connections and branch triggers are recreated per workspace, and webhooks must point at the new host. |
| Private workers | Terrakube executors running on your Kubernetes or Docker host | Needs rework. Worker pools are replaced by executors that you size, patch and monitor yourself. Confirm how your network access to private resources carries over. |
| Contexts and environment variables | Workspace variables, with sensitive values stored in Terrakube | Needs rework. Contexts are not one-to-one with workspaces, so shared values must be duplicated or referenced. Re-enter secrets from your secrets manager, not from exports. |
| Rego policies | OPA policy checks through Terrakube extensions | Needs rework. Rego files usually carry over, but the hook points, plan inputs and pass or fail behavior must be retested for each policy. |
| Identity and group access | Dex authentication with groups assigned to workspaces, modules and VCS connections | Needs rework. Map Spacelift spaces and roles to Terrakube groups, then confirm access on a test workspace before wider rollout. |
| Private module registry | Private registry for Terraform modules and providers | Clean for modules that are already in version control. Republish each module and update source references in configurations. |
| Drift detection and scheduled runs | Confirm current Terrakube scheduling and drift options in the documentation | Gap until confirmed. Do not assume a parity feature. Plan a scheduled plan job with your CI system as a fallback. |
| Spacelift features beyond Terraform, such as Pulumi or Ansible | Terrakube runs Terraform and OpenTofu only | Gap. Pulumi and Ansible stacks need another runner, such as the Pulumi CLI with its own backend or AWX or Semaphore UI. |
Getting state out of Spacelift and into Terrakube safely
State is the step that decides whether the move is safe, so settle the export method before anything else. The usual route is a Spacelift task that runs terraform state pull (or the OpenTofu equivalent) against each stack and writes the JSON to a bucket you control. The other route is enabling external state access so the new platform can read the state directly. Spacelift's export paths differ from HCP Terraform's state versions API, which exposes a JSON state download URL for states created by Terraform 1.3 or later, so confirm the exact method, its permissions and any retention limits against current Spacelift documentation before you rely on it. Once the state is in hand, import it into Terrakube through the remote backend, which supports state migration for configurations that already use it, and check the workspace's state against the stack's last applied version.
Before the export, freeze writes. Disable or pause tracked runs on each stack and tell the teams that own them that no applies should start until cutover is signed off. Then confirm that no run is holding the state lock, because a pull taken during an active apply can capture a half-written state. Keep a dated, immutable copy of every exported state file and of the stack configuration, stored separately from the new Terrakube backend, so you can roll back if the import misbehaves. Record the state serial and checksum in your cutover log so the copy in the new home can be matched to the original.
Treat the cutover as finished only when the new workspace plans clean. Run a plan in Terrakube against the same code and variables and expect no changes. A non-empty plan usually means a missing variable, a provider version mismatch or a state that did not import fully, and it must be explained before the old stack is removed. Keep the old Spacelift stack disabled, not deleted, until a few normal change cycles have passed without drift. If the team wants client-side encryption of state and plan files, OpenTofu supports key providers such as AWS KMS, GCP KMS and OpenBao, which you should configure and test before the first remote write, since keys and access policies are hard to change later.
What data and integrations to move, and what to rebuild by hand
Spacelift holds more than state. Stacks, variables, contexts, VCS links, group permissions and notifications each leave the platform differently, and Terrakube does not offer a one-click import for any of them. Work through the cards in order, export what you can, and record every setting you rebuild so each stack can be checked against its old behavior before cutover.
State files and their backups
State is the component you cannot afford to lose or mis-copy. Pull each stack's current state with a Spacelift task running terraform state pull or tofu state pull, or enable external state access if your plan allows it, and store the output in a bucket you control with versioning turned on. Keep the Spacelift copy and any prior versions until every stack plans clean in Terrakube. Confirm with the platform owner which state backend Terrakube will use and whether encryption at rest for state needs a key provider you have already approved. Expect terraform_remote_state consumers to need extra care, because OpenTofu's migration guide flags that case separately.
Stack variables and secrets
Spacelift stack environment variables and secret values are not something you should expect to export in readable form. Inventory each stack's variables, classify them as plain configuration or secret, and recreate them as Terrakube workspace variables, marking sensitive values as such. Secrets should come from your own secrets manager where possible, not be copied from a dashboard export. Ask the platform owner who holds the cloud credentials used by runs and whether they will be rotated during cutover, so the new executors authenticate with identities you can audit.
Contexts and shared configuration
Spacelift contexts bundle variables, hooks and attachments that several stacks share. Terrakube has no direct equivalent to copy from, so map each context to the variable sets or repeated workspace settings you will maintain in its place. List every stack that attaches each context, because a change made once in Spacelift currently reaches all of them, and you must reproduce that fan-out deliberately. Confirm with the platform owner which hooks and before-run or after-run scripts are actually in use, since they need their own rebuild path.
VCS connections to your Git host
Terrakube reads Terraform and OpenTofu code from GitHub (cloud and Enterprise), GitLab (EE and CE), Bitbucket and Azure DevOps. Each Spacelift VCS integration, including the GitHub app or token it uses, must be recreated against the same repositories and branches, and webhooks must point at the Terrakube API. Record which branch and path each stack tracks and which runs trigger on pull requests versus merges. Confirm with the Git administrator who controls app installation and token scope before cutover, so no stack loses its trigger while it moves.
Identity and group permissions through Dex
Spacelift access is typically granted through its own roles and spaces, which do not carry over as-is. Terrakube authenticates users through Dex with providers such as SAML, Azure Active Directory, Amazon Cognito or GitHub, and assigns permissions on workspaces, modules and VCS connections by group. Map each Spacelift space and role to a group in your identity provider, then grant workspace access to that group rather than to individuals. Confirm with your identity team which Dex connector fits your directory and how group claims will reach Terrakube.
Notifications and external webhooks
Spacelift can notify Slack, email and other destinations and call external webhooks on run events. Export the list of notification targets and webhook URLs from your Spacelift settings, then decide which ones Terrakube reaches through its API, an extension, or your own integration. Check that approval gates, failed-run alerts and drift notices still reach the same people. Confirm with the platform owner whether any downstream system parses Spacelift run payloads, because those formats will not match Terrakube's.
The migration sequence from inventory to decommission
This sequence moves each Spacelift stack to Terrakube one at a time, with a clean plan and a recorded sign-off before every cutover. It ends with an archived Spacelift configuration that your team can restore if a question comes up later.
Inventory every stack and its dependencies
Platform engineering lists every Spacelift stack with its repository, branch, OpenTofu or Terraform version, state location, attached contexts, policies, trigger rules, workers and VCS connection. The list also flags any stack that reads another stack's outputs through the terraform_remote_state data source, because OpenTofu's migration guide notes these configurations need additional care. The output is an inventory register with one row per stack and a dependency map. The step is done when the security and application owners have each reviewed the rows for their systems.
Pilot one low-risk stack
Choose a stack with a small blast radius, such as a non-production networking or tagging module. Export its state using a Spacelift task or external state access, back up the code and state, then recreate the workspace, variables and VCS connection in Terrakube. Run a plan and confirm it reports no changes before any apply. The output is a pilot sign-off record that lists the plan result, the variables checked and any gaps found, such as Rego policies that were not translated.
Run both platforms in parallel
For each stack still on Spacelift, point the Terrakube workspace at the same commit and let both platforms plan it. Restrict apply to one platform, normally Spacelift until cutover, and compare plan output for each run. Differences usually come from variables, provider versions, contexts or policy checks that do not match. The output is a parallel-run log per stack. The step is done when a planned number of consecutive plans match in both systems, a threshold your team sets in its own cutover policy.
Translate policies and approvals
Rewrite each Spacelift Rego policy as an OPA check that Terrakube runs through its extensions, then test the new checks against the same plans that Spacelift evaluated. Recreate approval rules and group permissions in Terrakube, since it assigns access on workspaces, modules and VCS connections by group. The output is a policy mapping table that shows each original Spacelift policy, its Terrakube equivalent and the test evidence. Security reviewers should sign off on any policy that cannot be reproduced exactly.
Cut over stacks in dependency order
Move stacks that others depend on last, and start with the leaves of the dependency map. For each stack, freeze changes in Spacelift, confirm the state in the new backend matches the exported state, switch the trigger to Terrakube, and run one small, reversible change to prove the apply path. Keep the Spacelift stack disabled but intact until the stack is verified. The output is a cutover checklist per stack, signed by the stack owner, with the commit, the state checksum and the test change recorded.
Retire Spacelift after a retention window
Once every stack has run cleanly in Terrakube through the agreed observation period, disable Spacelift triggers and revoke worker access. Export the final stack settings, contexts, policies and audit history into your own archive before the subscription ends. Confirm with your procurement and legal teams what data Spacelift retains after termination. The output is an archived Spacelift configuration bundle and a decommission record that names who approved the shutdown.
How the migration changes with stack count and starting point
A small team with a handful of stacks that run on Spacelift's shared workers usually has the shortest path. Each stack is a small, separate piece of work, so you can move one at a time and keep the others running in Spacelift until each plans clean in Terrakube. Most of the effort goes into rebuilding variables and VCS connections by hand, because there is little shared configuration to reuse.
- Stack list: Record each stack's repository, branch, working directory, runtime and trigger settings before you create anything.
- Variables and secrets: Copy environment variables and sensitive values into Terrakube workspaces, and confirm where each secret is stored today.
- State export: Pull each state with a Spacelift task or external state access, then store it in a bucket you control.
- Single-person risk: With few people holding context, document every manual step so a second person can repeat it.
- Policy: Check whether any stack depends on Spacelift policies, and if so, decide whether to translate them or drop them.
Before you start, confirm the Terraform or OpenTofu version each stack pins, so the CLI you install matches what the state expects.
A platform team with many stacks that share contexts, such as common provider credentials, backend settings and policy attachments, faces a migration that is mostly about reconstructing shared structure. Terrakube has workspaces and groups rather than Spacelift's contexts, so you need a mapping from each shared context to the Terrakube variables, workspace settings or group permissions that will replace it. Errors here spread across every stack that inherits the context.
- Context map: List every context, which stacks attach it and which values it sets, then decide how each maps to Terrakube.
- Permissions: Terrakube assigns access by group on workspaces, modules and VCS connections, so design the group model before you migrate teams.
- Dependencies: Find stacks that read other stacks' outputs, including any use of the terraform_remote_state data source, and sequence those moves together.
- Cutover order: Move low-impact stacks first and keep shared dependencies in Spacelift until their consumers are ready.
- Parallel running: Expect a period when both platforms hold live state for different stacks, and make sure only one platform applies each stack.
Ask your Terrakube provider or internal team to confirm how the group and workspace model covers your existing contexts before you commit to a mapping.
An estate that runs Spacelift private workers inside its own cloud account already has network access, credentials and runtime controls in place. Moving to Terrakube replaces those workers with Terrakube executors, so the work is less about the code and more about reproducing network paths, instance identity and secret access in the new runtime. Plan changes and applies that reach private endpoints will fail first if the executors cannot see the same resources.
- Worker inventory: Record each worker pool, its network location, its IAM or service identity and the resources it reaches.
- Executor placement: Confirm that Terrakube executors can run in the same network segment and reach the same endpoints, including private registries and internal APIs.
- Credentials: Replace worker-attached roles with the identity model your executors will use, and check that least-privilege scopes carry over.
- Audit trail: Map where Spacelift logs for these runs are kept, so you know what evidence to preserve during the move.
- Change windows: Schedule cutovers for stacks that touch shared network or identity resources during planned maintenance.
Before you cut over, ask your infrastructure team to confirm that the executor image, its egress rules and its secret sources match what the private workers used.
A team that runs the Terraform CLI today must decide whether to move to OpenTofu at the same time as moving platforms. Terrakube supports both the remote backend and the cloud block for Terraform and OpenTofu, so the platform move does not force the CLI decision, but combining both changes doubles the number of things that can break. Terraform 1.6.0 and later are under the Business Source License, while OpenTofu is MPL-2.0 and its compatibility with future Terraform releases is not guaranteed.
- Version pins: Inventory the Terraform version each stack uses and any provider or module constraints that depend on it.
- Decision point: Choose whether to change the CLI in a separate phase, before the platform move, so each change can be tested alone.
- State compatibility: Confirm that the state format your stacks produce loads cleanly in the CLI you choose.
- Encryption: If you adopt OpenTofu, plan how state and plan encryption will be configured with your key provider.
- Feature use: Check whether any stack relies on features that exist in one tool and not the other.
Verify each stack with a plan that shows no unexpected changes before you use the same CLI for applies in Terrakube.
What drives the cost and duration of the move
This table lists the factors that change how much work the move takes and what it costs to run afterward, and what to do about each one. Cost comes from internal staff time, hosting and database for Terrakube, and any partner scope, so read each row as a question to answer in your own inventory before you request a quote.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Number and size of stacks | Each stack needs its state exported, its variables and contexts recreated, and a clean plan confirmed in Terrakube. Effort scales with the count, and large stacks take longer to verify. | Inventory every stack, group them by owner and blast radius, and migrate low-risk stacks first to build a repeatable runbook. |
| Dependency depth between stacks | Stacks that read outputs from other stacks through terraform_remote_state need coordinated cutover. OpenTofu's migration guide flags this case for extra care. | Map the dependency graph before scheduling. Move upstream stacks together with their consumers, or temporarily keep shared state reachable from both platforms. |
| Rego policy count and complexity | Spacelift policies written in Rego must be translated or re-attached as Terrakube extensions for OPA checks. Complex rules with many inputs need more testing. | Export and classify policies by type (plan, approval, trigger). Retire unused rules and test each translated policy against recent plans. |
| Private worker count and network placement | Private workers often reach internal networks, registries or cloud accounts. Terrakube executors need equivalent network paths, credentials and sizing. | Document which workers reach which networks. Deploy executors in the same network zones and verify connectivity per stack before cutover. |
| VCS provider and webhook setup | Terrakube connects to GitHub, GitLab, Bitbucket or Azure DevOps. Each VCS connection, webhook and permission must be recreated and tested. | Confirm the supported VCS integration for each provider in your environment. Group repositories by provider and migrate one provider at a time. |
| Identity integration | Terrakube uses Dex with providers such as Azure Active Directory, Amazon Cognito, GitHub or SAML, and assigns permissions by group. Group mapping errors block users from workspaces. | Map existing Spacelift roles to Terrakube groups in writing before migration. Confirm the identity provider setup with your identity team early. |
| State size and backup handling | Larger state files take longer to export and verify. Migration copies of state contain secrets and must be encrypted and access-controlled. | Take a verified backup of each state before any change. Store exports in an encrypted bucket with restricted access, and consider OpenTofu state encryption for the new home. |
| Terrakube database and hosting choices | Terrakube runs on any database Liquibase supports, such as PostgreSQL, and installs with a Helm chart or Docker Compose. Hosting, backup and high availability choices shape ongoing cost. | Choose the database and install method your platform team already operates. Test restore procedures and size the environment from a pilot stack set. |
| Ongoing operations staffing | After cutover, someone must patch Terrakube, upgrade OpenTofu, rotate credentials and support teams. This recurring effort replaces a subscription that handled these tasks. | Name owners for upgrades and on-call before cutover. Ask any implementation partner to quote run, upgrade and support work separately from migration work. |
What usually goes wrong and how to prevent it
Most failed Spacelift to Terrakube moves do not fail loudly. They fail through stale state, drifting tool versions, settings that never made it across, and decommissioning steps taken before the new runs have proven themselves. Each card below names one failure and the check that catches it before it reaches production.
State exported without a lock
If you pull state out of Spacelift while a run is still active, the copy you export may be stale by the time you cut over. A run that finishes later on the old stack can write newer state that your Terrakube workspace never sees, and the next apply on either side can overwrite the other's changes. Before exporting, pause triggers on every stack, confirm no run is in progress, and record the state serial. Compare that serial with the serial in Terrakube before the first plan.
Version drift between tools
Plans can differ between Spacelift and Terrakube when the OpenTofu or Terraform binary, or a provider version, is not the same on both sides. Spacelift may pin one runtime version per stack while your Terrakube executors default to another. Pin the OpenTofu version and provider lock files in every workspace, and read the OpenTofu and Terrakube release notes before choosing a version. Confirm the target version with the OpenTofu release page before you pin it.
Missing contexts and variables
Spacelift contexts, stack environment variables and mounted files do not carry over automatically. A plan can still succeed when a variable is missing if it has a default, so the error only appears as a changed resource set. Build an inventory of every context attached to each stack, then recreate those values as Terrakube workspace variables. Run a plan on each workspace and compare the resource count against the last Spacelift plan for that stack.
Policies that behave differently
Rego policies written for Spacelift's policy hooks do not run unchanged in Terrakube. Terrakube runs policy checks through its OPA extension, which receives the plan in its own input structure, so a rule that reads a field Spacelift exposed may pass silently or fail for the wrong reason. Test each translated policy against plans of known good and known bad changes before enabling it on a live workspace. Document which policies were rewritten so auditors can trace the change.
VCS and group permissions block runs
Terrakube retrieves code through GitHub, GitLab, Bitbucket or Azure DevOps connections and assigns access to workspaces and VCS connections by group. A Terrakube workspace can be created correctly and still fail on its first run because the connection token lacks read access, the webhook is not registered, or the identity group has no permission on that workspace. Test each repository with a no-op plan, verify webhook delivery, and confirm the service account's scopes in the source system before cutting over.
Decommissioning too early
Removing Spacelift stacks, private workers and credentials before the Terrakube workspaces have run cleanly removes the rollback path. Keep each Spacelift stack read-only and its last state version retained until the new workspace has applied at least one real change and a clean plan. Set the decommission date in writing with the people who own each stack. Retain the exported state copy in your own bucket under the same access controls as the original.
Questions buyers ask before moving from Spacelift to Terrakube
How much does a migration from Spacelift to Terrakube cost?
The cost is mostly labor and infrastructure, not software, because Terrakube is Apache 2.0 licensed and free to use. The one-time costs are the migration work itself (inventory, state export, workspace recreation, policy translation, parallel runs and cutover) and any consulting or internal engineering time. The recurring costs are the servers or Kubernetes capacity, the relational database that Liquibase supports such as PostgreSQL, executor capacity, backups, monitoring and the people who operate the platform. The main drivers are the number of stacks, how many stacks depend on each other, how much custom Rego policy and integration logic exists, and how many VCS connections and cloud accounts are involved. Ask any quote for a fixed scope that lists each stack, each policy set and each integration, plus a separate line for ongoing operations.
How long does moving from Spacelift to Terrakube take?
The timeline depends on the number of stacks, the number of dependencies between them, and how much policy and integration logic has to be rebuilt. Stacks with simple state and no shared outputs move faster than stacks that feed other stacks or rely on custom hooks. Terrakube's own installation, identity integration and executor setup run before any stack moves, so the platform build sets the floor for the schedule. Cutover is done stack by stack, so the schedule also depends on how many change windows your teams can accept. Ask for a written scope with a phase plan, the stacks grouped by wave, and agreed acceptance criteria for each wave before work starts.
Can our own platform team migrate from Spacelift without outside help?
A team that already runs Kubernetes or Docker, manages a relational database and has experience with OpenTofu or Terraform can do the migration internally, and many teams do. The harder parts are usually not the CLI: they are translating Rego policies into OPA checks used by Terrakube extensions, rebuilding contexts and variable scopes, reconnecting VCS connections with group-based permissions, and proving that each workspace plans clean in its new home. Be honest about capacity during the migration, because the same engineers usually run both platforms. If internal capacity is limited, a fixed-scope engagement can cover the parts you do not want to staff.
What do we need to provide for the migration to succeed?
The work needs access and decisions from your side before any stack moves. You will need an inventory of stacks, contexts, policies, VCS connections and cloud accounts, and read access to the Spacelift stacks so state can be exported with a task or external state access. You will need administrator rights in the cloud accounts that host Terrakube and the state storage, and an identity administrator who can connect Dex to your identity provider and assign group permissions. Plan a change window for each stack, a rollback decision owner, and a named person to approve state moves. Confirm these items in writing before the scope is signed.
Can we run Spacelift and Terrakube in parallel during the move?
Yes, the usual approach is to run both platforms side by side and move stacks in waves, but each stack must be owned by only one platform at a time. Two platforms applying to the same state can corrupt it, so the cutover for each stack should disable applies in the old system before the new one takes over. A stack can be verified in Terrakube with a plan that shows no changes before you switch its VCS trigger. Keep the exported state and the original configuration until the stack has run cleanly for an agreed period. Confirm the freeze and rollback steps with your change board.
Does Terrakube need the same OpenTofu or Terraform version as Spacelift?
Terrakube runs the IaC version you configure, so the goal is to keep versions consistent before and after the move. Record the OpenTofu or Terraform version each stack uses in Spacelift, then pin the same version in Terrakube before any change is made. The cloud block needs Terraform v1.1 or later, and earlier versions can use the remote backend, which also supports migrating state. Remember that OpenTofu states it aims for feature parity with Terraform, but future compatibility is not guaranteed, so decide deliberately whether you move to OpenTofu as part of the same project. Confirm the exact versions and any state encryption settings with your test runs.
What happens to our Rego policies when we move to Terrakube?
Spacelift policies written in Rego cannot be copied across as they are, because each platform exposes different inputs and decision points. Terrakube supports policy checks through its extensions, including OPA, so the work is to map each Spacelift policy (plan, approval, trigger and access) to an equivalent check and test it against recorded plan files. Some Spacelift policy types may have no direct equivalent, so the gap list should be agreed before cutover and the controls that depended on those policies need compensating steps. Ask for a policy inventory, a test set of plans with expected results, and sign-off from the people who own the controls.
What support is included after cutover from Spacelift?
Support after cutover depends on the written scope. A migration project normally ends with handover documentation, runbooks, a verified backup and restore procedure, and a list of open items. Ongoing support, upgrades and continuous testing are available as retainers, and they cover tasks such as applying Terrakube and database upgrades, monitoring, backup checks and policy changes. Ask whether the scope includes a hypercare period after the last stack moves, who is on call, how incidents are triaged, and how upgrades to Terrakube releases are tested before they reach production.
How DeployOpen scopes, runs and supports the Terrakube migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Spacelift to Terrakube move, we start from a written scope that lists which stacks move, in what order, and how each one is verified before cutover.
How we scope
- Inventory every Spacelift stack, its state location, contexts, variables, policies and VCS connections before any work starts
- Agree in writing which stacks move, which stay on Spacelift during overlap, and the cutover order
- Confirm the target hosting, database, identity provider and executor setup with your platform team
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins
How we build
- Deploy Terrakube into your environment using its documented Helm chart or Docker Compose options
- Recreate workspaces, variables, VCS connections and group permissions, then translate Rego policies into the OPA checks Terrakube runs
- Export state through the method your scope confirms, and check that each workspace plans clean in its new home
- Test each stack with a small change before it is marked ready for cutover
How we hand over
- Document the target architecture, workspace inventory, access model and rollback steps for each migrated stack
- Provide a cutover record per stack showing the plan output comparison and the state checksum used
- Walk your operators through daily runs, state recovery and upgrades on the Terrakube release line you choose
- Deliver the written handover package before the scope is closed
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the migration closes
- Plan Terrakube upgrades and backups for the database and state store as a recurring task
- Ask your team to confirm internal ownership of the platform, since support scope depends on who operates it day to day
- Keep the Spacelift subscription in place until your written cutover plan says each stack is retired
