VMWARE → STACKIT · ARCHITECTURE
Mapping application dependencies before a VMware migration
An RVTools export tells you which VM sits on which port group. It does not tell you that billing reads the CRM database, that two applications share a message broker, or that nobody knows who uses the FTP server. StackToIT builds waves from the first kind of fact and takes the second kind from you, as an explicit applications file. This page shows the line between the two in a seven-VM demo estate and compares four ways to close the gap.
What the export shows, and what it only hints at
A demo export assessed by StackToIT on 4 November 2026. Left: four vInfo rows; the last columns hold the annotation an administrator typed. Right: engineering/review-edges.csv, the complete list of dependencies the run derived.
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
crm-web01,poweredOn,False,4,8192,1,1,61440,24000,10.60.10.11,DC-Koeln,CL-Core,esx41,crm,CRM web tier - calls crm-app01 on 8443,Ubuntu Linux (64-bit),Ubuntu 22.04.4 LTS,4209-eeee-0001
crm-app01,poweredOn,False,8,16384,2,2,163840,70000,10.60.20.21,DC-Koeln,CL-Core,esx41,crm,CRM application server - reads crm-db01 and mq01,Red Hat Enterprise Linux 9 (64-bit),Red Hat Enterprise Linux 9.4,4209-eeee-0002
crm-db01,poweredOn,False,8,32768,1,2,614400,380000,10.60.30.31,DC-Koeln,CL-Core,esx42,crm,PostgreSQL 15 - also used by billing-app01,Debian GNU/Linux 12 (64-bit),Debian GNU/Linux 12,4209-eeee-0003
billing-app01,poweredOn,False,4,16384,1,1,102400,40000,10.60.20.41,DC-Koeln,CL-Core,esx42,billing,Billing batch - reads crm-db01 and writes files to fs01,Red Hat Enterprise Linux 9 (64-bit),Red Hat Enterprise Linux 9.4,4209-eeee-0004from_unit,to_unit,architect_verdict (correct|wrong|missing),comment
vm.billing-app01,network.PG-App,,
vm.crm-app01,network.PG-App,,
vm.crm-app01,network.PG-Data,,
vm.crm-db01,network.PG-Data,,
vm.crm-web01,network.PG-Web,,
vm.fs01,network.PG-Data,,
vm.legacy-ftp01,network.PG-App,,
vm.mq01,network.PG-App,,Edges go from VM to port group
All eight edges end at a network. crm-app01 has two adapters and so two edges, one to PG-App and one to PG-Data. There is no edge from billing-app01 to crm-db01.
The annotation is not read as a link
Statements such as "also used by billing-app01" live in free text. The run lists the annotation of every VM among the properties it does not carry, so it cannot turn text into an edge.
The file has a place for your correction
The third column, architect_verdict, takes correct, wrong or missing. Use it to record edges the run could not see, so the review keeps them.
Four ways to find dependencies
None of them replaces the others. The trade-off is what each can see and what it costs you.
| Method | What it can see | What it misses or costs |
|---|---|---|
| Network membership (what StackToIT derives) | Which VMs sit on which port group, and so which STACKIT network must exist before each VM moves | Calls between VMs on the same or on different networks. Cheap, but wrong as the only basis of a wave plan. |
| Owner interviews and annotations | Intent: which VM belongs to which application and who owns it | Only what people remember. Fast to start, and the source of the applications file. |
| Observed traffic from your own network tools | Connections that nobody wrote down, such as an old FTP server that still receives files | Needs a collection period long enough to cover month-end and batch jobs. The data does not come from RVTools or from StackToIT. |
| Configuration management or a CMDB | Declared relations between services and hosts | Often out of date for the oldest machines, which are the ones you worry about. |
A practical order: start with annotations and owners, assign VMs to applications, then check the result against observed traffic before each cutover.
Give the run your application boundaries
The applications file groups units by selector. StackToIT infers neither ownership nor criticality from names. Left: the file used for this run. Right: migration/waves.csv with the application column filled.
applications:
- id: crm
name: CRM
selectors:
- vm.crm-*
environment: production
owners:
business: sales
technical: crm-platform
business_criticality: high
availability:
rto: 4h
rpo: 15m
downtime_tolerance: 1h
- id: billing
name: Billing
selectors:
- vm.billing-*
environment: production
owners:
business: finance
technical: billing-platform
business_criticality: critical
availability:
rto: 2h
rpo: 5m
downtime_tolerance: 30mwave,wave_state,unit,type,module_call,presence,class,confidence,application,application_status,proposed_group
1,MEMBER,network.PG-App,vmware_network,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,UNASSIGNED,UNASSIGNED,
1,MEMBER,network.PG-Data,vmware_network,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,UNASSIGNED,UNASSIGNED,
1,MEMBER,network.PG-Web,vmware_network,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,UNASSIGNED,UNASSIGNED,
2,MEMBER,vm.billing-app01,vmware_vm,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,billing,CONFIRMED,
2,MEMBER,vm.crm-app01,vmware_vm,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,crm,CONFIRMED,
2,MEMBER,vm.crm-db01,vmware_vm,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,crm,CONFIRMED,
2,MEMBER,vm.crm-web01,vmware_vm,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,crm,CONFIRMED,
2,MEMBER,vm.fs01,vmware_vm,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,UNASSIGNED,UNASSIGNED,
2,MEMBER,vm.legacy-ftp01,vmware_vm,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,UNASSIGNED,UNASSIGNED,
2,MEMBER,vm.mq01,vmware_vm,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,UNASSIGNED,UNASSIGNED,Matched and unmatched
crm matches three VMs, billing one. mq01, fs01 and legacy-ftp01 stay UNASSIGNED. They belong to no application yet, and that is exactly the list to take to the owners.
Waves stay network-driven
In migration/waves.csv the three networks are wave 1 and all seven VMs wave 2, whatever the application file says (the migration plan names the same order as its network and workloads waves, with its own numbers). Application grouping changes how the report is cut, not the dependency graph.
Recovery targets are recorded as written
RTO, RPO and downtime tolerance from the file are carried as you wrote them. Values you leave out stay NOT_PROVIDED instead of being assumed.
The shared pieces, and the decision each one forces
| VM | What the estate says | Decision for the architect |
|---|---|---|
| crm-db01 | PostgreSQL, annotated as also used by billing-app01 | Move with CRM and keep a network path for billing until billing moves, or move both in one wave. The run sees neither fact. |
| mq01 | Message broker used by crm and billing | Assign it to one application on purpose, or keep it as a shared service in the first wave of its consumers. |
| fs01 | File server with SMB shares for billing and office | Its clients are not VMs in the export. Find the clients before the wave is set. |
| legacy-ftp01 | Annotation: nobody knows who uses this; CentOS 7 | Observe traffic first, then retire it or move it. Do not carry an unknown dependency into a wave unexamined. |
In this run the guest of legacy-ftp01 triggers an end-of-support warning, a reason to ask about it early.
Turn the dependency list into target design
Write the applications file
One entry per application, selectors for its VMs, owners and recovery targets. Unassigned units in the report are your open questions.
Record missing edges
Add each VM-to-VM relation you learn to review-edges.csv as missing, with a comment. It keeps the knowledge next to the plan.
Derive network rules
On STACKIT, security groups apply through network interfaces: inbound traffic is blocked by default except from members of the same group, and egress is open by default. The draft writes no security group for a VMware estate, so each confirmed relation becomes a rule you write.
Watch shared disks
A STACKIT data volume attaches to one VM at a time. A VM that shares a disk with another needs a different design from a plain volume move. The Sharing mode column of the vDisk sheet tells you; in this estate every disk is sharingNone.
Cut waves along applications
Move an application whole when it can run on one side. When it cannot, plan the network path between both sides as part of the wave.
Dependency mapping questions
Does StackToIT discover application dependencies?
It derives which VMs share a port group and orders waves from that. Dependencies between applications come from your applications file and from the review.
Can RVTools show network traffic?
No. The export describes machines, disks and adapters. Traffic has to come from your network tools and is outside what StackToIT reads.
What happens to VMs I do not assign to an application?
They stay in the plan and in the totals. The executive brief counts them as units that no application holds: in this run they carry 15 manual steps, all in the plan and its totals.
Do dependencies change the class of a VM?
No. All seven VMs are RECONFIGURE however they are connected. Dependencies change the order and the grouping of work, not the class.
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.