Spacelift Migration Kit — FAQ

Last updated: March 9, 2026

A reference document capturing common questions and answers related to migrating to Spacelift using the Migration Kit.

Migration Scope

Q: What does a typical migration from TFC to Spacelift cover?

A: A standard migration covers four main areas:

  • HashiCorp modules → Spacelift module registry

  • TFC projects → Spacelift spaces

  • TFC workspaces → Spacelift stacks

  • Variables (both encrypted and plain text)

Migration Kit

Q: Does the migration kit support partial migrations?

A: Yes. The migration kit supports filtering, allowing teams to migrate a subset of workspaces at a time rather than requiring a full cutover all at once.

Q: What is the recommended cutover strategy when using the migration kit?

A: The recommended approach is:

  1. Migrate stack definitions first

  2. Upload the latest state files from TFC into Spacelift

  3. Optionally lock states in both TFC and Spacelift during the transition to prevent concurrent runs

HashiCorp Registry Access During Migration

Q: Is it necessary to immediately refactor all module sources to point to Spacelift's registry?

A: No. During migration, Spacelift can be configured with a TFC token to temporarily pull modules directly from the HashiCorp private registry. This avoids requiring immediate code changes and allows a more gradual transition.

Azure Integration

Q: Can existing Azure service principals and federated credentials be reused in Spacelift?

A: Yes. Spacelift's Azure integration supports existing service principals and federated credentials natively, eliminating the need to create separate variable sets solely for Azure authentication.

Terraform Versions & OpenTofu

Q: How should workspaces running BSL Terraform versions (post 1.5.7) be handled?

A: Workspaces on BSL Terraform versions require custom runner images to continue using those versions. The recommended path is to migrate all workspaces to OpenTofu for uniformity and access to newer provider versions without BSL licensing constraints.

Non-VCS Workspaces

Q: How are workspaces not connected to a VCS repo (CLI-driven runs) handled in Spacelift?

A: Spacelift follows a strict GitOps model — every stack must be mapped to a repository. Non-VCS workspaces will need to be connected to a repo, even if it is used only for configuration purposes.

Deployment & Infrastructure

Q: Where does Spacelift SaaS run, and how do private workers fit in?

A: Spacelift's SaaS control plane runs in AWS US East 2. Private workers run within the customer's own infrastructure environment. The Business tier includes 3 private workers, with drift detection consuming one of those slots.

Q: What are the payment terms for Spacelift?

A: Annual upfront payment.

Support & Timeline

Q: What level of support does Spacelift provide during migration?

A: Spacelift offers hands-on migration support including working sessions, dry runs, and direct access to the SE team throughout the process.

Q: How long does a migration typically take?

A: Timeline varies depending on the number of workspaces and their complexity. Spacelift works with customers to scope a timeline during initial working sessions.