MIGRATION TOOL FOR STACKIT
The migration tool for STACKIT
StackToIT is a rule-based migration tool for cloud infrastructure on its way to STACKIT. It analyzes existing estates, identifies technical dependencies and the architecture decisions they need, and writes traceable target architectures and Terraform drafts for supported resources. It runs as a command-line tool on your own machine.
What the tool analyzes
A migration to STACKIT starts with knowing what you run today. StackToIT builds that picture from the files that define the estate, not from console screenshots.
Infrastructure code
Terraform and OpenTofu root modules for AWS, Microsoft Azure, Google Cloud, Huawei Cloud, Alibaba Cloud and Oracle Cloud, including registry and local modules, variables and count or for_each expansions.
VMware inventories
RVTools exports as .xlsx or CSV: virtual machines, templates, disks and port groups, read without an agent in your estate.
Dependencies
Resources and the references between them become migration units with dependency order and waves, so the plan moves things in an order that works.
Configuration that matters
Sizes, versions, access settings and data-bearing services are read per resource, because they decide the STACKIT target and the work the move takes.
One command, one migration package
Point StackToIT at a Terraform or OpenTofu root module or an RVTools export. The package is written beside the source and stays on your machine.
stacktoit assess ./terraform
# writes terraform-stacktoit/
# index.html assessment.json decisions.json
# target-plan.json execution-plan.json
# terraform/ execution/ architecture/ ...Local
Your code is read where it lies. No upload, no cloud credentials, no agent.
Deterministic
Versioned engineering rules give the same input the same result. No generative AI decides anything.
Traceable
Every result names its reason and its source, for Terraform down to file and line.
Read-only toward clouds
The tool creates, changes and deletes nothing in any cloud. Your pipeline applies what your architects approve.
From source estate to STACKIT in four steps
Read
The source is resolved into concrete resources with their modules, variables and references.
Model
Resources become migration units in dependency order, grouped into waves.
Decide
A versioned rule base gives each unit a migration class, a STACKIT target, a confidence and the reason. Open questions become named decisions with owners.
Deliver
STACKIT Terraform, architecture diagrams, an ordered execution plan, data movement steps and the decision register are written as files you review, version and keep.
Where StackToIT sits among the tools for a STACKIT migration
Today a migration runs through several tools. In the current release StackToIT covers assessment, target design and planning; STACKIT's own tools build the target, and specialised tools move data and workloads. The full picture is in the tool overview linked below.
| Tool | Job in the migration | Phase |
|---|---|---|
| StackToIT | Assess the source estate, map every resource to STACKIT, draft Terraform, plan the move, record decisions | Assess and plan |
| STACKIT Terraform Provider with Terraform or OpenTofu | Create and change the target infrastructure from code, including the drafts StackToIT writes | Build and run |
| STACKIT CLI and SDKs | Manage projects, service accounts and resources by hand or by script | Build and run |
| Velero | Back up and restore Kubernetes resources and volumes between clusters | Move workloads |
| rclone | Copy buckets between S3-compatible object storages | Move data |
| VM replication tools such as Coriolis | Replicate virtual machines into STACKIT with test runs and cutover | Move workloads |
| Discovery platforms such as Device42, Txture or Flexera One | Inventory estates that are not described in code, with dependencies and portfolio views | Discover |
Independent products of their respective vendors. StackToIT is not affiliated with them or with STACKIT.
What the tool delivers
Migration assessment
Every resource with its migration class, STACKIT target, confidence and reason, as an interactive report and as machine-readable assessment data.
STACKIT Terraform draft
Provider code for the supported units, statically validated with OpenTofu against a pinned STACKIT provider version, ready for your platform team to review.
Target architecture and plan
Architecture diagrams, an ordered execution plan with prerequisites, data movement, cutover and verification steps, and priced cost lines from public price lists.
Data migration plan
Every stateful unit of the estate with its target, the candidate methods documented for it, prerequisites, checks, cutover and rollback steps. What the source does not state, such as data size or tolerated downtime, is listed as unknown, not assumed.
Decision register
The architecture questions the code cannot answer, each with an owner, plus answer templates the next run reads.
Decisions, answers and the next run
A migration is decided in rounds. StackToIT keeps those rounds in files, so your existing review practice applies.
Answers are files
Design inputs and decision reviews are YAML files you keep outside the generated folder, for example in your own repository, and pass to the next assessment.
The next run re-evaluates
Applied answers change the draft and the plan; reviews that no longer match the source or the decision basis are reported as stale instead of silently kept.
Pipelines can call it
JSON Lines output and a strict mode that fails on partial or unverified results let an engineering pipeline run the assessment and keep the artifacts.
Proven on a real AWS estate
The AWS Retail Store Sample App, a public Terraform project from AWS, assessed by StackToIT and published in full, exactly as the run wrote it.
View Case Study- 282
- Terraform resource declarations analyzed
- 44
- migration units identified
- 38
- target units generated, from 52 considered
- 331
- plan steps written
Questions about the tool
What is a migration tool for STACKIT?
Software that turns an existing cloud or VMware estate into a reviewable plan for STACKIT: which resource goes where, what changes, in which order, and what still has to be decided. StackToIT does this from infrastructure code and RVTools exports and writes STACKIT Terraform drafts for supported resources.
Is StackToIT a tool from STACKIT?
No. StackToIT is an independent product operated by woppTech. STACKIT provides the target platform and its own developer tools such as the Terraform Provider, the CLI and the SDKs.
How does StackToIT differ from the STACKIT Terraform Provider and CLI?
The provider and the CLI create and manage STACKIT resources. StackToIT works one step earlier: it reads your current estate, decides the STACKIT target for every resource and writes the Terraform draft and plan that your team then applies with the provider.
Does StackToIT move data or virtual machines?
In the current release StackToIT plans the move and names every step, including data movement and cutover, and writes nothing into any cloud. Data copies and VM replication are carried out with the dedicated tools listed in the tool overview, run by your team against the plan.
Which source platforms does the tool support?
Terraform and OpenTofu estates on AWS, Microsoft Azure, Google Cloud, Huawei Cloud, Alibaba Cloud and Oracle Cloud, and VMware estates exported with RVTools.
Can we run StackToIT in our own pipeline?
Yes. It is a command-line tool for macOS and Linux that needs no cloud credentials, writes JSON Lines output and returns a non-zero exit code in strict mode when results are partial or unverified.
Sources
Your next move: STACKIT.
Tell us about your estate. We show you what StackToIT delivers for it: target architecture, Terraform artifacts and a structured migration plan.
Leave your contact details and our specialists will get in touch.
Prefer to write yourself? connect@stacktoit.com
Thank you.
Your request has reached us. Our specialists will get in touch.