Tools for migrating to STACKIT

Four jobs, four kinds of tools

• Discover and assess

  Know what runs today, how it depends on each other and what each part becomes on STACKIT. StackToIT does this from infrastructure code and RVTools exports; discovery platforms do it from the running estate.

• Design and build the target

  Describe the STACKIT infrastructure as code and create it. The STACKIT Terraform Provider, the Pulumi provider, the CLI and the SDKs are the platform's own tools for this.

• Move workloads and data

  Replicate virtual machines, redeploy or restore Kubernetes workloads, copy buckets and migrate databases. Each has its own tool, chosen per workload.

• Operate

  After the cutover, STACKIT's platform services and your existing delivery and monitoring practice take over. The migration tools are no longer in the loop.

Which tool does what

Phases follow the STACKIT Cloud Framework: assess, design and mobilize, migrate, run. One row per tool or tool family, with the job it is actually built for.

All products belong to their respective vendors and projects. Listing them here states what they do; it implies no partnership or integration with StackToIT.

Assess and plan: StackToIT, discovery platforms and the STACKIT framework

• StackToIT for estates described in code

  Input is a Terraform or OpenTofu root module or an RVTools export. Output is a package: every resource with class, STACKIT target and reason, Terraform drafts for supported units, diagrams, an ordered plan and the open decisions. It runs locally, needs no cloud credentials and changes nothing in any cloud.

• Discovery platforms for the undocumented estate

  Device42, Txture and Flexera One inventory what is running, map dependencies and give portfolio and cost views. They do not know STACKIT as a target and write no STACKIT Terraform. They are the right start when little infrastructure is in code.

• The STACKIT Cloud Framework for method

  STACKIT's framework describes the assess phase as rapid discovery, a readiness assessment across technical, process, people, financial and governance dimensions, and workshops. It names no assessment tool; it sets the questions a tool has to answer.

• How they fit together

  Discovery gives the complete inventory; StackToIT gives the STACKIT-specific answer for the coded part of it; the framework's readiness assessment covers organisation and governance. Together they produce the baseline the design phase needs.

Build the target: STACKIT's own tools

• Terraform Provider and OpenTofu

  The standard way to create STACKIT infrastructure from code. StackToIT's drafts are written against a pinned provider version and validated statically with OpenTofu, so your platform team reviews provider code it already knows.

• Pulumi provider

  STACKIT's Pulumi provider covers IaaS and Resource Manager services from Node.js and is labelled alpha in the official documentation. For a complete estate the Terraform Provider is the reference today.

• CLI and SDKs

  The CLI covers projects, service accounts and resources for day-to-day work and scripts. The SDKs for Go, Python and Java wrap the STACKIT APIs for your own tooling.

Move workloads and data: one tool per workload

• Virtual machines

  Hystax Acura replicates running machines into STACKIT with unlimited test migrations and a final sync at cutover; it also serves disaster recovery. Coriolis does agentless replication between platforms. The STACKIT Cloud Framework names both for relocating VMs.

• Kubernetes

  Velero backs up cluster resources and persistent volumes and restores them on the new cluster. Where workloads are already deployed from Git, Argo CD or Flux redeploy them to SKE and only the data needs a separate path.

• Object storage

  rclone copies and synchronises buckets between S3-compatible services such as Amazon S3 and STACKIT Object Storage, and reads Azure Blob Storage and Google Cloud Storage through its own native backends, with checksums and resumable runs.

• Databases

  PostgreSQL moves to PostgreSQL Flex with pg_dump and pg_restore, or with logical replication for a short cutover. credativ's open-source migrator is an option when a proprietary engine has to become PostgreSQL. Engines without a managed STACKIT equivalent are an architecture decision first, as the assessment shows.

How to choose

• Start from the inventory

  If the estate is in Terraform or OpenTofu, run StackToIT first: it tells you per resource what moves, what changes and what must be decided. If it is not, start with discovery.

• Pick per workload

  VMs, Kubernetes, objects and databases each have a proven move tool. The execution plan names the step; the tool is your choice.

• Keep the target in code

  Whatever moves the data, the STACKIT side should exist as Terraform or Pulumi first. That is what makes the migration repeatable and reviewable.

Questions about tool choice

Sources

• STACKIT Cloud Framework: Migration overview
• STACKIT Cloud Framework: Assess
• STACKIT Cloud Framework: Relocate (Coriolis, Hystax Acura)
• STACKIT Docs: Terraform Provider
• STACKIT Docs: Pulumi
• STACKIT Docs: STACKIT CLI
• STACKIT Docs: Go SDK
• Hystax: live cloud migration to STACKIT
• Cloudbase Solutions: Coriolis
• Velero documentation
• Argo CD documentation
• Flux documentation
• rclone documentation
• PostgreSQL: pg_dump
• credativ-pg-migrator on GitHub
• Device42
• Txture
• Flexera One