VMWARE VMS → STACKIT COMPUTE ENGINE
Planning the VMware VM migration to STACKIT
StackToIT turns the RVTools export into a migration plan you can schedule: each VM keeps its CPU, memory and disk sizes as the basis of its STACKIT server, networks come before the servers that use them, and the review work is grouped into work packages with an owner role each.
A database VM, planned as a STACKIT server
A small RVTools export written for this page and assessed by StackToIT on 4 November 2026. Left: the input. Right: the resource blocks of the STACKIT Terraform the engine wrote; the review comments above each block in the file are left out here.
VM,Disk,Capacity MiB,Raw,Disk Mode,Sharing mode,Thin,Controller,Shared Bus,VM UUID
shop-web01,Hard disk 1,61440,False,persistent,sharingNone,True,SCSI controller 0,noSharing,4202-bbbb-0001
shop-web02,Hard disk 1,61440,False,persistent,sharingNone,True,SCSI controller 0,noSharing,4202-bbbb-0002
shop-api01,Hard disk 1,61440,False,persistent,sharingNone,True,SCSI controller 0,noSharing,4202-bbbb-0003
shop-api01,Hard disk 2,102400,False,persistent,sharingNone,True,SCSI controller 0,noSharing,4202-bbbb-0003
shop-pg01,Hard disk 1,102400,False,persistent,sharingNone,False,SCSI controller 0,noSharing,4202-bbbb-0004
shop-pg01,Hard disk 2,512000,False,persistent,sharingNone,False,SCSI controller 1,noSharing,4202-bbbb-0004
tpl-ubuntu2204,Hard disk 1,30720,False,persistent,sharingNone,True,SCSI controller 0,noSharing,4202-bbbb-0005resource "stackit_network_interface" "vm_shop_pg01_nic1" {
project_id = var.project_id
network_id = stackit_network.network_PG_Shop_DB.network_id
ipv4 = "10.20.30.31"
}
resource "stackit_server" "vm_shop_pg01" {
project_id = var.project_id
name = "shop-pg01"
machine_type = var.vm_shop_pg01_machine_type
availability_zone = var.availability_zone
boot_volume = {
source_type = "image"
source_id = var.vm_shop_pg01_image_id
size = 100
}
network_interfaces = [stackit_network_interface.vm_shop_pg01_nic1.network_interface_id]
}
resource "stackit_volume" "vm_shop_pg01_disk2" {
project_id = var.project_id
name = "shop-pg01-disk2"
availability_zone = var.availability_zone
size = 500
performance_class = var.vmware_volume_performance_class
}
resource "stackit_server_volume_attach" "vm_shop_pg01_disk2" {
project_id = var.project_id
server_id = stackit_server.vm_shop_pg01.server_id
volume_id = stackit_volume.vm_shop_pg01_disk2.volume_id
}Boot disk becomes the boot volume
Hard disk 1 of shop-pg01, 102400 MiB, becomes a 100 GiB boot volume, started from the image converted from that disk.
Second disk becomes a volume
Hard disk 2, 512000 MiB, becomes a 500 GiB STACKIT volume attached to the server. The file notes that its data is copied after the volume is created.
Address kept
The interface keeps 10.20.30.31 on the network that replaces PG-Shop-DB, so clients of the database find it at the same address.
Performance class chosen once
The performance class of the data volumes is one variable for the estate, so storage is decided in one place.
The machine size, stated from the source
From the same run. Left: the vInfo sheet of the export. Right: the two values the server of shop-pg01 reads, as variables.tf of the run declares them.
VM,Powerstate,Template,CPUs,Memory,NICs,Disks,Provisioned MiB,In use MiB,Primary IP Address,Datacenter,Cluster,Host,Folder,Annotation,OS according to the configuration file,OS according to the VMware Tools,VM UUID
shop-web01,poweredOn,False,2,8192,1,1,61440,22000,10.20.10.11,DC-Munich,CL-Shop,esx11,shop,Shop frontend,Ubuntu Linux (64-bit),Ubuntu 22.04.4 LTS,4202-bbbb-0001
shop-web02,poweredOn,False,2,8192,1,1,61440,21500,10.20.10.12,DC-Munich,CL-Shop,esx12,shop,Shop frontend,Ubuntu Linux (64-bit),Ubuntu 22.04.4 LTS,4202-bbbb-0002
shop-api01,poweredOn,False,4,16384,1,2,163840,70000,10.20.20.21,DC-Munich,CL-Shop,esx11,shop,Order API,Red Hat Enterprise Linux 9 (64-bit),Red Hat Enterprise Linux 9.4,4202-bbbb-0003
shop-pg01,poweredOn,False,8,32768,1,2,614400,380000,10.20.30.31,DC-Munich,CL-Shop,esx13,db,PostgreSQL 15 primary,Debian GNU/Linux 12 (64-bit),Debian GNU/Linux 12,4202-bbbb-0004
tpl-ubuntu2204,poweredOff,True,2,4096,1,1,30720,6000,,DC-Munich,CL-Shop,esx11,templates,Base image,Ubuntu Linux (64-bit),,4202-bbbb-0005variable "vm_shop_pg01_image_id" {
type = string
description = "STACKIT image converted from the boot disk of VM shop-pg01 (qcow2 or raw)."
}
variable "vm_shop_pg01_machine_type" {
type = string
description = "STACKIT machine type replacing VM shop-pg01 (source 8 vCPU / 32 GiB). See https://docs.stackit.cloud/products/compute-engine/server/basics/machine-types/"
}Size from vInfo
shop-pg01 has 8 CPUs and 32768 MiB of memory. The machine type variable states the source size, 8 vCPU and 32 GiB, and links the STACKIT machine types to choose from.
Image from the boot disk
The image variable stands for the boot disk converted to qcow2 or raw, so the server starts from the machine it replaces.
The plan in order
| Phase | What the plan does | Steps |
|---|---|---|
| Network and security | Creates the 3 STACKIT networks and has the Network Architect and Platform Architect settle the addressing and name of each port group | 9 |
| Data services | Creates the 2 data volumes for the second disks of shop-api01 and shop-pg01 | 2 |
| Platform | Sets up the template tpl-ubuntu2204 as a STACKIT image by hand | 1 |
| Workloads | Creates 4 network interfaces, 4 servers and 2 volume attachments, and has the Network, Platform and Security Architect review the settings of each VM | 22 |
34 steps in all: 15 OpenTofu steps and 19 manual steps, as execution-plan.json and migration/roadmap.md of the run list them. Each step names the steps it depends on: a server waits for its interface, an interface for its network, an attachment for its server and its volume.
From export to cutover plan
Export and assess
Run RVTools, then stacktoit assess ./rvtools.xlsx ./vmware-migration. The package holds the classes, the Terraform, the execution plan and the work packages.
Answer what the export lacks
The draft asks for machine types, disk sizes and server addresses. Answer them in review/ and run again: the next run reads your answers.
Prepare the images
Export each disk, convert it to qcow2 or raw and upload it as an image. Replace VMware Tools and the vmxnet3 and PVSCSI drivers with the drivers the STACKIT image needs.
Agree the cutover
Waves are computed from dependencies and are a starting point for the schedule. Application dependencies and cutover timing come from the workload owners.
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 migration leads ask
How does StackToIT size a VMware VM for STACKIT?
It reads the CPUs and memory of the VM from vInfo and states them on the machine type of its STACKIT server, for shop-pg01 8 vCPU and 32 GiB. Disk capacities from vDisk become the boot volume and further volumes in GiB.
In what order do the VMs move?
Networks first, then the machines that use them. The run puts the three port groups in the first wave and the VMs and the template in the second; units in the same wave can move in parallel.
Which disk formats can STACKIT import?
qcow2 and raw. Export each disk, convert it to one of them, upload it as an image and boot it as a server; additional disks become volumes.
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.