VMWARE → STACKIT · CHECKLIST
VMware to STACKIT migration checklist
Work through six phases, discovery, design, build, data, cutover and after, and tick a check only when you can name the file that holds its answer. The files named here are those a StackToIT run writes from an RVTools export; the examples come from a nine-VM demo estate assessed on 4 November 2026.
1. Discovery
What you have, before anyone designs anything.
Export every sheet
RVTools sheets vInfo, vDisk, vNetwork, vSnapshot and vMemory. A missing sheet makes the run warn and treat snapshots or reservations as unknown, not as none. Answer: engineering/architect-report.md, source warnings.
The sheets joined completely
Rows of vDisk, vNetwork, vSnapshot and vMemory should match VMs. Answer: assessment.json, summary, inventory_join (rows and matched per sheet).
Applications are named
Group VMs into applications with an applications file and pass it with --applications. Units no selector names stay UNASSIGNED. Answer: migration/applications.csv.
Guest operating systems reviewed
Read the configuration-file OS and the OS VMware Tools reports; the end-of-support warning reads only the first. Answer: findings in engineering/architect-report.md.
Snapshots listed and consolidated
The run says only the current state of a VM is migrated. Consolidate before export. Answer: snapshot finding per VM; the Broadcom page describes consolidation.
Shared and raw disks found
Look for Raw and Sharing mode in vDisk. Such VMs are classified MANUAL_REVIEW. Answer: terraform/README.md, Left for the architect.
Database VMs listed by people
The run does not detect database software. Answer: your DBAs and the Annotation column.
2. Design
The decisions the export cannot make for you.
Region chosen
Answer the target.region request. Answer: review/inputs.yaml; the run counts it as blocking until answered.
Network prefixes set
One CIDR per port group. The export has addresses, no masks. Answer: review/target-values.tfvars, with the addresses seen listed per network.
Network names confirmed
VLAN numbers survive only inside names. Answer: work package for the Platform Architect in execution/manual/actions.md.
Addresses kept or changed
An interface keeps its address after creation. Answer: open setting ip-address per VM in assurance/critical-semantics.json.
Machine type per VM
Catalogue names; Windows needs a family marked compatible. Answer: variables.tf, one machine type variable per server.
Availability zone chosen
The source datacenter is not mapped. Answer: work package for the Security Architect.
Security groups designed
Inbound is closed by default and nothing of port-group policy is in RVTools. Answer: your own design; the draft sets none.
Licence route for Windows
Included image or your own image and licences. Answer: Windows guest finding per VM and the STACKIT licensing guide.
Power state after cutover
The draft sets no desired status, so a powered-off VM would start. Answer: open setting power-state per VM.
Two checklists the run already writes
Left: the Before wave 1 section of migration/technical-sequencing.md. Right: the first lines of execution/verify/checks.md, which lists what must hold before each step.
## Before wave 1
- [ ] Architect has reviewed every MANUAL_REVIEW, REDESIGN and BLOCKED unit in engineering/architect-report.md.
- [ ] STACKIT organisation, folders and projects are laid out (one project per environment is the usual start).
- [ ] Data-transfer method and cutover window agreed per data unit (databases, buckets, caches).## Before each step
- [ ] `TF/stackit_network.network_PG_Shop_App` · `variable-supplied` `variable=network_PG_Shop_App_ipv4_nameservers` — The variable `network_PG_Shop_App_ipv4_nameservers` has a value.
- [ ] `TF/stackit_network.network_PG_Shop_App` · `variable-supplied` `variable=network_PG_Shop_App_ipv4_prefix` — The variable `network_PG_Shop_App_ipv4_prefix` has a value.
- [ ] `TF/stackit_network.network_PG_Shop_App` · `variable-supplied` `variable=project_id` — The variable `project_id` has a value.Per step, not per project
The checks file holds one line per variable per step, so a missing value is found before apply, not during it.
Nothing has run
Both files are proposals. StackToIT reads and writes files and changes nothing in any cloud.
3. Build
From the draft to servers in a test project.
Services enabled in the project
The README lists the STACKIT services to enable first; for these drafts it names IaaS. Answer: terraform/README.md.
Provider authentication decided
The README recommends workload identity federation over long-lived keys. Answer: Target security checklist in terraform/README.md.
State backend chosen
The draft declares none. The README warns not to rely on locking with an S3 backend on Object Storage. Answer: same checklist.
All variables have values
28 in the demo run. Answer: terraform/variables.tf and review/target-values.tfvars.
Images prepared
STACKIT imports raw, qcow2 and iso; the custom image page gives a maximum image size of 70 GB. The reason the run gives for each rehosted VM says that VMware Tools and the vmxnet3 and PVSCSI drivers are replaced by the drivers the STACKIT image needs. Answer: engineering/architect-report.md, and the image ID variable per server.
Templates handled
A template is REPLATFORM and has no image block. Answer: terraform/README.md, Left for the architect.
Plan reads clean in a test project
Run tofu init, validate and plan there. StackToIT never runs apply. Answer: your plan output.
4. Data
StackToIT never moves data; these checks are yours.
Volume list reviewed
Each extra disk becomes a volume; the block comment says its data is copied after creation. Answer: terraform/compute.tf. Data volumes range from 1 GB to 16 TB each.
Copy method chosen per volume
Disk copy, dump and restore, backup import or replication. Answer: migration/data-movement.md states data on VM disks is not assessed.
Downtime tolerance recorded
RTO, RPO and downtime tolerance as the owner states them. Answer: applications file and migration/applications.csv.
Raw mappings copied
A raw LUN is not in the image. Answer: the run's reason on the unit; plan a block- or application-level copy.
Backup designed
The export holds no backup resource. Answer: assurance/operational-readiness.md, Backup job row.
5. Cutover
The order and the way back.
Wave order agreed
Networks first, then servers. Answer: migration/technical-sequencing.md; it calls waves a starting point.
Cutover facts read
The run lists the DNS records and certificates it could see and says plainly when it saw none. Names and addresses outside the source are yours. Answer: Cutover section of the same file.
Every open critical setting closed or accepted
136 in the demo run. Answer: decisions.json and review/decisions.yaml.
Rollback written per manual step
The plan states that it does not know how a manual step is undone. Answer: Rollback lines in execution/manual/actions.md.
Source VMs kept intact
Stop them, do not delete them, until the owner signs off. This is practice, not a run output.
6. After
Closing the loop.
Checks after each step passed
Answer: execution/verify/checks.md.
Decisions recorded
Accepted decisions need supporting details and evidence. Answer: review/decisions.yaml, then run again.
Assessment re-run
The next run reads your answers and regenerates the draft. Compare the counts of open items.
Source retired
Remove snapshots and VMs after sign-off, and update the inventory. This is practice, not a run output.
What a missing sheet looks like
From the architect report of a run whose export lacked two sheets.
- **warning** RVTOOLS_SHEET_MISSING: the export has no vSnapshot sheet (SHEET_MISSING): the snapshot count and size of the 7 VMs are not known, so they are unknown (not none) for every VM
- **warning** RVTOOLS_SHEET_MISSING: the export has no vMemory sheet (SHEET_MISSING): the memory reservation of the 7 VMs are not known, so they are unknown (not none) for every VMUnknown is not none
The warning states that the values are unknown for every VM. Export the sheets and run again.
Sooner is cheaper
Discovery gaps found in phase 1 cost one export; found at cutover they cost a window.
Questions about the checklist
Do I need StackToIT to use this checklist?
No. The checks are general, and the file names tell you where a StackToIT run keeps the answer. Without a run, answer them from vCenter, your CMDB and the owners.
Which checks block the draft?
In the first demo run one request blocked it, the target region; once the region was answered, the second run counted no blocking request. Everything else leaves the draft in place with open settings listed.
Can the checklist be ticked automatically?
No. execution/verify/checks.md lists what to verify, and a person ticks it. StackToIT carries out no step.
What is not covered?
Application behaviour, data contents, firewall rules and licensing contracts. RVTools describes infrastructure only.
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.