VMWARE → STACKIT · EXIT PLANNING
Planning a VMware exit backward from the renewal date
A renewal is a fixed date, and a migration is a list of work packages with owners. The exit plan is what you get when you put the second under the first. Run an RVTools export through StackToIT early, count the steps and owners it writes, sort the estate into move, retire and rebuild, and settle the decisions a deadline cannot absorb: disaster recovery, Windows licences and the machines nobody owns. This guide uses a nine-VM, two-site demo estate to show what the run gives you and where your own judgement starts.
Step 1: put numbers on the work
A demo export of two sites, assessed by StackToIT on 4 November 2026. Left: three of the nine vInfo rows. Right: from execution/README.md, the line that counts the work and, further down the same file, the work package table that splits it by role.
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
erp-db01,poweredOn,False,16,131072,1,3,1048576,640000,10.70.10.12,DC-Frankfurt,CL-Prod,esx52,erp,ERP database SQL Server,Windows Server 2016 (64-bit),Microsoft Windows Server 2016,4210-ffff-0002
tst-old01,poweredOff,False,2,4096,1,1,40960,15000,,DC-Frankfurt,CL-Test,esx61,test,Powered off since 2025,CentOS 7 (64-bit),,4210-ffff-0006
dr-erp02,poweredOn,False,16,131072,1,3,1048576,500000,10.80.10.12,DC-Duesseldorf,CL-DR,esx71,erp,DR replica of erp-db01,Windows Server 2016 (64-bit),Microsoft Windows Server 2016,4210-ffff-0009**What will be created.** OpenTofu creates 34 resource blocks. Architect work: 35 manual steps in 5 work packages.
| Package | Owner | Phase | Steps | Resources | Decisions to answer | State |
|---|---|---|---|---|---|---|
| [`WP-01`](manual/actions.md) Decide and set the critical settings (foundation) | Network Architect | foundation | 4 | 4 | — | a person can start it now |
| [`WP-02`](manual/actions.md) Decide and set the critical settings (foundation) | Platform Architect | foundation | 4 | 4 | — | a person can start it now |
| [`WP-03`](manual/actions.md) Decide and set the critical settings (workloads) | Network Architect | workloads | 9 | 9 | — | a person can start it now |
| [`WP-04`](manual/actions.md) Decide and set the critical settings (workloads) | Platform Architect | workloads | 9 | 9 | — | a person can start it now |
| [`WP-05`](manual/actions.md) Decide and set the critical settings (workloads) | Security Architect | workloads | 9 | 9 | — | a person can start it now |What the figures say
13 units: 9 VMs and 4 networks. The plan creates 34 resource blocks and holds 35 manual steps in 5 work packages, owned by three roles: Network, Platform and Security Architect.
What they do not say
None of the 34 automated steps can run as written yet: the plan lists 28 OpenTofu variables without a value, among them machine types, image ids and network prefixes. The figures count work; they are not durations.
Where the owners are
Two packages belong to the Network Architect and two to the Platform Architect, one to the Security Architect. If one role owns most steps, that role is your schedule risk.
Working backward from the date
1. Fix the dates you cannot move
The contract end date, any notice period and the date by which the last VM must be off the old platform. These come from your contract; no tool reads them.
2. Sort the estate
Every VM is a candidate to move, retire or rebuild. The run classifies all nine VMs as RECONFIGURE, because rehosting is the default treatment. Retiring is your decision and saves work: a powered-off machine, a test copy or a build server is cheaper to drop than to move.
3. Fill the open variables
Machine types, image ids, network prefixes and the performance class are the values the draft cannot know. The network prefixes belong to the first work package, WP-01 of the Network Architect; machine types and image ids go into review/target-values.tfvars. Until they are filled, no automated step can run.
4. Pick a pilot
The run proposes one workload end to end on a STACKIT sandbox project, with an architect closing the open settings first. You accept or reject it. Treat it as the dress rehearsal that tells you how long a VM really takes.
5. Cut waves and leave a buffer
In migration/waves.csv the networks are wave 1 and all nine VMs wave 2. Split the second wave by application and leave a buffer before the contract date; the order within it is a choice discussed below.
6. Plan the parallel run and the retirement
Agree how long both platforms run, who switches the traffic and who switches off the old machines. The plan of this run holds no cutover, verification or retirement steps, so you add them to the schedule.
Sort the demo estate: move, retire or rebuild
| VMs | What the export shows | Exit decision |
|---|---|---|
| erp-app01, erp-db01 | Windows Server 2016, ERP; the database VM has 1 TiB of provisioned disk; production cluster | Move first or last by risk, not by size. STACKIT offers Windows Server 2016 to 2025 and states that Windows licences cannot be migrated, so the licence model changes with the move. |
| web-intra01, web-intra02 | Two identical Ubuntu 22.04 servers | Rebuild from the Ubuntu 22.04 image STACKIT offers, then move the content; a pilot candidate. |
| tst-erp01, dev-build01 | Test copy of the ERP and a build server | Decide whether they follow production or are recreated from it afterwards. |
| tst-old01 | Powered off, CentOS 7 in its configuration | The run warns that the guest is past its vendor end of support. Retire it unless an owner appears. |
| dr-erp01, dr-erp02 | Replicas of the ERP in a second datacenter | Moved like any VM by the run. Their purpose is a design question; see below. |
All of these are RECONFIGURE in the run. The decisions in the right column are yours, not the run's.
Step 2: the decision a deadline cannot cover, disaster recovery
Left: the production database VM and its replica sit in different datacenters. Right: the one variable that places every server and volume of the draft.
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
erp-db01,poweredOn,False,16,131072,1,3,1048576,640000,10.70.10.12,DC-Frankfurt,CL-Prod,esx52,erp,ERP database SQL Server,Windows Server 2016 (64-bit),Microsoft Windows Server 2016,4210-ffff-0002
dr-erp02,poweredOn,False,16,131072,1,3,1048576,500000,10.80.10.12,DC-Duesseldorf,CL-DR,esx71,erp,DR replica of erp-db01,Windows Server 2016 (64-bit),Microsoft Windows Server 2016,4210-ffff-0009variable "availability_zone" {
type = string
description = "Default availability zone for servers and volumes."
default = "eu01-1"
}One zone for everything
The run states that the draft puts every server in var.availability_zone and that the source datacenter is not mapped to a STACKIT location. Primary and replica would land in the same zone with the default value.
Your design question
Do you still need a replica in a second place, and how will it be kept in sync on the new platform? That is an architecture decision with its own work, not a side effect of the move.
Replicas that replicate
In the export the replica is a VM with its own disks. Moving it as a plain VM copies its disks, not its replication; decide first what the new recovery design is.
What a renewal date cannot decide for you
Windows licences
STACKIT Windows Server VMs are licensed for the operating system only, and licences cannot be migrated. Five of the nine demo VMs run Windows Server 2016, so the licence cost line changes with the move.
Unowned machines
tst-old01 and its kind have no owner in the export. Ask once, with a date; silence is a decision to retire.
Machine sizes for Windows
The ERP database VM has 16 vCPU and 128 GiB, a 1:8 ratio, which the machine types page gives for the m family. Sizes cannot be customized, and Windows Server runs only on the types the page marks as compatible (no AMD types, for example), so check early that the exact size exists for Windows.
Order of the second wave
Hardest first leaves time to recover; easiest first builds practice. Pick one on purpose.
Exit planning questions
How long will the migration take?
StackToIT does not estimate durations. It counts steps and work packages and shows who owns them. Time one pilot VM end to end and scale from that, with a buffer.
Can I start before I know the renewal terms?
Yes. RVTools needs only read access to vCenter, and the assessment needs nothing but the export, so both can run well ahead of the negotiation.
Does the plan include cutover and retirement?
Not in this run: its console reports 0 lifecycle steps (cutover, verify, retire), and the cutover, verification and decommission waves of the migration plan hold no step. Add them yourself; our runbook for the VMware network, DNS and firewall cutover is one worked example of such steps, each with an owner, a check and a rollback.
Should every VM move?
No. Moving is the default treatment, not a recommendation. Retiring a machine nobody uses is the cheapest step in the plan.
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.