VMWARE → STACKIT · RUNBOOK
Network, DNS and firewall cutover from VMware to STACKIT
The draft creates the networks, the interfaces with their old addresses and the servers in dependency order. It creates no DNS records, no firewall rules and no public addresses, and the cutover section of the plan says so. This runbook orders the whole move around those gaps for a twelve-unit demo estate, with an owner and a check for every step and a rollback for each point of no return.
What the run writes for the network side
A demo estate written for this page and assessed by StackToIT on 4 November 2026: eight VMs, four port groups, one load balancer VM on two of them. Left: the whole vNetwork sheet. Right: the network the run drafts for the PG-DMZ port group; the DNS sentence above the block is quoted below.
VM,NIC label,Adapter,Network,Switch,Connected,IPv4 Address,VM UUID
lb01,Network adapter 1,Vmxnet3,PG-DMZ,dvs-prod,True,10.60.0.10,4206-f018-0001
lb01,Network adapter 2,Vmxnet3,PG-App,dvs-prod,True,10.60.1.10,4206-f018-0001
web01,Network adapter 1,Vmxnet3,PG-DMZ,dvs-prod,True,10.60.0.11,4206-f018-0002
web02,Network adapter 1,Vmxnet3,PG-DMZ,dvs-prod,True,10.60.0.12,4206-f018-0003
app01,Network adapter 1,Vmxnet3,PG-App,dvs-prod,True,10.60.1.21,4206-f018-0004
app02,Network adapter 1,Vmxnet3,PG-App,dvs-prod,True,10.60.1.22,4206-f018-0005
db01,Network adapter 1,Vmxnet3,PG-DB,dvs-prod,True,10.60.2.31,4206-f018-0006
dns01,Network adapter 1,Vmxnet3,PG-Infra,dvs-prod,True,10.60.3.5,4206-f018-0007
batch01,Network adapter 1,Vmxnet3,PG-App,dvs-prod,True,10.60.1.61,4206-f018-0008resource "stackit_network" "network_PG_DMZ" {
project_id = var.project_id
name = "pg-dmz"
ipv4_prefix = var.network_PG_DMZ_ipv4_prefix
ipv4_nameservers = var.network_PG_DMZ_ipv4_nameservers
}Prefix and nameservers are yours
RVTools exports no subnet masks, as the run's report states, and it does not show which DNS servers the port group's VMs use, as the comment above the block says. Both are variables with no default: the prefix and the nameservers of the new network.
Names are rewritten
The port group PG-DMZ becomes the network pg-dmz. Anything that refers to the old name, such as scripts or documentation, needs the new one; the run lists the name as a setting to confirm.
The two-network load balancer and the cutover note
Left: the interfaces and the server the run drafts for lb01, without the comment lines. Right: the order of the units and the cutover section of the plan, from migration/technical-sequencing.md (lines 9 to 33, with wave 2 listing eight units).
resource "stackit_network_interface" "vm_lb01_nic1" {
project_id = var.project_id
network_id = stackit_network.network_PG_DMZ.network_id
ipv4 = "10.60.0.10"
}
resource "stackit_network_interface" "vm_lb01_nic2" {
project_id = var.project_id
network_id = stackit_network.network_PG_App.network_id
ipv4 = "10.60.1.10"
}
resource "stackit_server" "vm_lb01" {
project_id = var.project_id
name = "lb01"
machine_type = var.vm_lb01_machine_type
availability_zone = var.availability_zone
boot_volume = {
source_type = "image"
source_id = var.vm_lb01_image_id
size = 60
}
network_interfaces = [stackit_network_interface.vm_lb01_nic1.network_interface_id, stackit_network_interface.vm_lb01_nic2.network_interface_id]
}## Wave 1 — 4 unit(s)
| Unit | Class | Target |
|---|---|---|
| `network.PG-App` | RECONFIGURE / MEDIUM | STACKIT network |
| `network.PG-DB` | RECONFIGURE / MEDIUM | STACKIT network |
| `network.PG-DMZ` | RECONFIGURE / MEDIUM | STACKIT network |
| `network.PG-Infra` | RECONFIGURE / MEDIUM | STACKIT network |
## Wave 2 — 8 unit(s)
| Unit | Class | Target |
|---|---|---|
| `vm.app01` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.app02` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.batch01` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.db01` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.dns01` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.lb01` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.web01` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.web02` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
## Cutover (decision support — performed by the customer)
No cutover facts: the scan and the draft established no DNS record set whose value the draft re-binds to a generated address, no public address re-binding, no DNS record unit, no certificate unit and no open cutover decision. That is not a statement that nothing has to be cut over: a name, an address or a certificate outside the scanned source is not seen, and a unit that exists only if OpenTofu decides so at plan time is not read here. StackToIT performs no cutover and gives no time estimate.Addresses are kept
Each interface carries the address of the source adapter as a fixed IPv4: 10.60.0.10 on the DMZ side and 10.60.1.10 on the application side. Only the first address of an adapter is written; further addresses are a decision.
Networks first, servers second
Wave 1 holds the four networks, wave 2 the eight servers, because a server waits for its network. Units in one wave can move in parallel, the plan says, so the order inside wave 2 is up to you.
The cutover section is empty on purpose
The plan states that it found no DNS record set, no public address re-binding and no certificate to move, and that this does not mean nothing has to be cut over. It performs no cutover and gives no time estimate.
The runbook, in order
Owners named Network Architect and Platform Architect are the roles the run assigns to its open settings; the other owners are suggestions. Steps marked practice are general method, not output of the run.
| Step | Owner | Check |
|---|---|---|
| 1. Decide the prefix and the DNS servers of each of the four networks and fill the variables. | Network Architect | The plan's pre-step checks ask that every prefix and nameserver variable has a value. |
| 2. Decide per VM whether it keeps its address and what happens to its DNS name. The run lists both as open settings. | Network Architect | One decision record per VM. |
| 3. Lower the TTL of records that point at the servers, a few days ahead (practice). | DNS owner | The records show the lowered TTL and the old TTL has passed. |
| 4. Write the firewall rules as security groups. The draft has none (practice for the rules). | Security owner | Every interface has its group; a test host reaches only what is allowed. |
| 5. Apply the four networks (wave 1). | Platform Architect | Four networks exist with the chosen prefixes and the names pg-dmz, pg-app, pg-db and pg-infra. |
| 6. Apply interfaces and servers (wave 2) and keep them isolated. Decide the state of batch01, which is powered off at the source. | Platform Architect | Each server shows the source address; lb01 shows two interfaces; batch01 is not running unless intended. |
| 7. Copy the data, first a full copy, later the changes (practice). | Application owner | Row counts or checksums match. |
| 8. Freeze writes, take the last copy and power off the source VMs (practice). | Application owner | No session is left on the source. |
| 9. Start the target VMs from the data tier outwards (practice). | Platform Architect | Health checks pass on each tier. |
| 10. Attach a public IP to the interface of lb01 and open the needed ports in its security group. | Network Architect | A request from outside reaches lb01. |
| 11. Switch DNS: change the records to the new addresses, or the resolvers to the new nameservers. | DNS owner | Names resolve to the new addresses inside and outside. |
| 12. Observe with the source powered off but not deleted (practice). | Operations | The agreed observation period has passed without incident. |
| 13. Retire the source VMs (practice). | Platform owner | Sign-off recorded. |
The run's plan holds 53 steps for this estate, 21 automated and 32 manual. The cutover wave of that plan holds none, which is why steps 3 and 7 to 13 are yours.
What STACKIT networking gives you here
From the STACKIT pages on core networking and network interfaces.
Security groups
Stateful, applied per network interface, ingress denied by default and egress allowed by default. One group can apply to several interfaces.
Interfaces and addresses
A server can have up to five interfaces; a fixed IPv4 is set when the interface is created. NIC security, against IP and MAC spoofing, is on by default when you create an interface; the STACKIT CLI how-to says its --nic-security flag is off unless you set it, so set it explicitly in scripts.
Public addresses
A floating IP is a public IPv4 address mapped by NAT to the private address of a VM; the guest does not see it. The router address gives shared outbound access once a floating IP is assigned in the project.
DNS records
Records are created in the portal, and only in primary zones. A deleted record no longer resolves once its TTL has expired.
The DNS settings the run hands back
From the action list of the same run: two settings of a VM, both for the Network Architect.
- `ip-address` (Network Architect)
- Why: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. The rehost case asks whether the VM keeps its address; the draft sets only the first address of an adapter as ipv4 (stackit_network_interface.ipv4).
- Done when: A person decides whether the VM must keep its addresses and how any further address of an adapter is provided, since the draft sets only the first address of each adapter as the ipv4 of the network interface.
- `dns-name` (Network Architect)
- Why: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. DNS records are not migrated; the draft creates no stackit_dns_record_set.
- Done when: A person confirms the value against the target, or the knowledge base gains a rule that decides this setting.Rollback
Rollback depends on how far you got. For its manual steps the run's plan states that it does not know how they are undone, so the steps below are practice.
Before step 8
The source is untouched. Stop the target servers and fix the cause. Nothing needs undoing at DNS.
After step 8, before step 11
Power the source VMs back on, disable the target interfaces or stop the servers, and confirm the source answers. Writes made on the target in between are lost unless you copy them back.
After step 11
Point the records back to the old addresses, release the public IP from lb01 and power the source on. The lowered TTL from step 3 is what makes this fast. Decide first what happens to the data written on STACKIT since the switch.
Keep the source disks
Do not delete source VMs or disks until step 13. They are the rollback.
Questions about the network cutover
Does the run create DNS records or firewall rules?
No. Its notes say that it creates no DNS record set, and the Terraform it wrote for this estate holds no security group. Both are yours to build.
Do servers keep their IP addresses?
The draft sets the source address as a fixed IPv4 on each interface, so yes for the first address of each adapter. Whether they must keep it is a decision the run lists.
What happens to a powered-off VM such as batch01?
The draft sets no desired status, so the server would start on STACKIT. The run lists the target state of each server as a decision.
Is the cutover timing estimated?
No. The plan gives no time estimate; the downtime depends on your data copy and your DNS TTLs.
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.