How StackToIT works

One command

Point StackToIT at a Terraform or OpenTofu root module, or a VMware RVTools export. The package is written beside the source.

stacktoit assess ./terraform

# writes terraform-stacktoit/
#   index.html  assessment.json  decisions.json
#   target-plan.json  execution-plan.json
#   terraform/  execution/  architecture/ ...

Inside the engine

• 1 · Input resolution

  Root modules, registry and local modules, variables and expansions are resolved into the resources Terraform would create. Missing modules and providers come from their public registries; offline mode sends no request at all.

• 2 · Dependency graph

  Resources and their references become migration units with dependencies and waves, so the plan moves things in the order they rely on each other.

• 3 · Rule evaluation

  A versioned rule base assigns every unit a migration class, a STACKIT target, a confidence and a reason, and accounts for every attribute that is set.

• 4 · Target generation

  STACKIT Terraform, target architecture diagrams and application manifests are written from the decided targets, with a trace to each source resource.

• 5 · Planning

  An ordered execution plan covers prerequisites, data movement, cutover, verification and retirement, with priced cost lines from public price lists.

• 6 · Decisions

  Every question the code cannot answer becomes an entry in the decision register. Answer it in the templates, and the next run builds on your answers.

Built for enterprise workflows

• Runs where your code lives

  On a workstation or in CI. Your code is read locally, and no cloud credentials are needed.

• Reproducible by design

  The same input and rule version give the same result, so runs can be compared and reviewed like code.

• Verifiable output

  A manifest lists the files of the package, and stacktoit verify checks the package and its internal consistency.

What a run reports

From the console summary of the published AWS Retail Store run.

• Source and graph

  105 files read, 282 resources from 23 module calls (13 external, 10 local), and 109 dependencies between 44 migration units.

• Conditional units

  8 more units use a count or for_each that OpenTofu decides only at plan time. The run lists them as conditional instead of guessing whether they exist.

• Switched-off units

  41 further units are switched off by the source’s own settings. The console summary lists them apart from the units in a wave.

• Run record

  Every run records the tool version, the rule base version (0.385.0 in the published run), the source digest and a run id, so two runs can be compared.

• Price date

  Cost lines read a local price cache and name its retrieval date, 2026-10-26 in the published run.

Where your architects start reading

1. 01

   index.html

   The full assessment, unit by unit, with its readiness summary and the next action.

2. 02

   executive/decisions.md

   The decision register: each record with its options, its owner role and the phase it is due in.

3. 03

   migration/

   Work packages, waves, the data-movement plan and the list of prerequisites.

4. 04

   execution/verify/checks.md

   The checks before and after each step, generated from the execution plan.

Questions engineers ask

Sources

• STACKIT Docs: Terraform provider
• STACKIT Docs: Developer Tools
• STACKIT Docs: Products overview