---
title: "VMware Relocate Source Readiness"
description: "Prepare VMware estates for controlled Relocate waves by validating guest compatibility, source health, performance evidence, access, and transfer paths."
scfAsset:
managed: false
category: "runbook"
external: false
tags: ["design-and-mobilize", "use-cases", "relocate", "vmware", "source-readiness", "coriolis", "acura"]
maintainers:
- user: "lukas.weberruss"
source_url: "https://framework.stackit.cloud/migration/assetcontainer/stackit/vmware-relocate-source-readiness/"
source_file: "docs/migration/assetcontainer/stackit/vmware-relocate-source-readiness.mdx"
---
## Purpose
Use this runbook before assigning VMware virtual machines to a Relocate wave. It turns discovery
evidence into a technical source-readiness decision and separates common VMware checks from the
requirements of Cloudbase Coriolis and Hystax Acura.
The output is a per-VM readiness record with supported, conditional, or blocked status. Resolve
blocked items before replication begins instead of moving uncertainty into the cutover window.
## Required inputs
- **VM inventory**: vCenter, cluster, host, datastore, VM hardware version, firmware, operating
system, VMware Tools state, virtual disks, controllers, NICs, addresses, and attached devices.
- **Workload context**: Application owner, criticality, dependencies, consistency requirements,
recovery objectives, allowed downtime, and rollback tolerance.
- **Performance evidence**: Representative CPU, memory, IOPS, throughput, latency, queue, capacity,
and growth data rather than provisioned VMware capacity alone.
- **Migration path**: Selected tool, Coriolis or Acura, and its current source and target
compatibility matrix.
## Common VMware readiness checks
### Guest and virtual hardware
1. Confirm that the guest operating system, architecture, file systems, partition layout, and boot
mode are supported by the selected tool and STACKIT target.
2. Record BIOS or UEFI firmware, Secure Boot, virtual disk controllers, NIC models, static routes,
and guest-specific drivers that may require conversion or replacement.
3. Identify encrypted disks, Raw Device Mappings, shared disks, independent disks, passthrough
devices, nested virtualization, and removable media. Treat each unsupported attachment as a
blocker or design an explicit replacement.
4. Verify current VMware Tools health. Even where the migration tool is agentless, current guest
tools improve inventory quality, snapshot coordination, and controlled shutdown behavior.
5. Confirm operating-system licensing and activation behavior after the virtual hardware and cloud
environment change.
### Source health and snapshot safety
1. Resolve active alarms, failed backups, orphaned snapshots, snapshot consolidation warnings, and
file-system or volume errors before replication.
2. Verify that application-consistent or crash-consistent snapshots meet the workload's recovery
requirements. Databases and other stateful systems may need application quiescing or native
replication in addition to VM replication.
3. Reserve datastore capacity for migration snapshots and change tracking. Include current growth,
expected write rate, replication duration, and retry margin in the capacity decision.
4. Test backup restoration independently of the migration tooling and retain a recovery point that
predates the first migration operation.
### Network and access path
1. Measure available bandwidth, latency, packet loss, and the daily data-change rate between source
and target. Confirm that the initial copy and subsequent deltas fit the planned wave schedule.
2. Validate DNS, NTP, MTU, proxy, routing, NAT, and firewall behavior across management and data
paths. Record every required source, destination, protocol, port, and owner.
3. Use dedicated, least-privilege service accounts for vCenter or ESXi and the STACKIT target.
Validate API access and certificate trust before creating endpoints.
4. Confirm target address allocation, security groups, DNS changes, load-balancer changes, and the
traffic-switch mechanism. Replication software does not replace the cutover network runbook.
## Coriolis readiness path
Apply these checks when Cloudbase Coriolis is selected:
1. Validate the supported VMware source and STACKIT destination endpoint versions against the
Coriolis release used for the wave.
2. Create and test the VMware endpoint with a dedicated API identity. Confirm that Coriolis can
enumerate the selected VMs, disks, networks, and storage required by the migration scope.
3. Create and validate the STACKIT destination endpoint, then define source and destination minion
pools with enough worker capacity and concurrency for the planned wave.
4. Define source-to-target network and storage mappings before creating Transfer and Deployment
definitions. Review the destination machine type, boot volume, data volumes, and security groups.
5. Validate minion-worker and data-transfer connectivity required by the deployed architecture. Do
not assume that HTTPS access to the Coriolis user interface proves migration-path readiness.
6. Review guest conversion and OS-morphing support, including bootloader, storage driver, network
driver, and cloud initialization behavior. Mark workloads requiring manual remediation.
The Coriolis STACKIT Installer deploys and configures the Coriolis appliance on STACKIT. It does
not create VMware permissions, resolve unsupported source devices, size target VMs, or validate the
source-to-target transfer path.
## Hystax Acura readiness path
Apply these checks when Hystax Acura is selected:
1. Confirm that VMware Tools is installed and running on every selected VM.
2. Verify that Changed Block Tracking and VMware snapshots can be used for the selected virtual
disks and that no conflicting snapshot operation is active.
3. Keep at least 10 percent free capacity on source datastores and increase that margin for
high-change workloads or long replication windows.
4. Provide the documented vSphere API permissions and validate connectivity to vCenter or ESXi on
TCP ports 443 and 902 from the Acura components that perform discovery and replication.
5. Deploy and validate the required Hystax replication agents on the source ESXi hosts before
scheduling the first full replication.
6. Plan at least one isolated test migration. Traffic redirection, DNS changes, and application
freeze remain explicit cutover-runbook activities outside Acura replication.
## Readiness decision
Record the result for every VM and preserve the evidence used for the decision.
- **Guest compatibility**: Pass with a supported operating system, boot mode, disk layout, and
conversion path. Block on an unsupported device, encryption method, architecture, or boot path.
- **Source integrity**: Pass with a healthy VM, tested recovery point, and safe snapshot state. Block
on a consolidation error, failed backup, or insufficient datastore capacity.
- **Performance baseline**: Pass with representative CPU, memory, storage, and growth measurements.
Block when only provisioned capacity or incomplete peak-window data is available.
- **Access**: Pass with tested least-privilege endpoint credentials and certificate trust. Block on
missing API permissions or unmanaged shared credentials.
- **Transfer path**: Pass with measured capacity and validated routing, ports, DNS, NTP, and MTU.
Block on firewall gaps, unstable links, or a copy duration outside the wave schedule.
- **Cutover inputs**: Pass with target mappings, validation tests, a rollback trigger, and source
retention. Block on an undefined traffic switch or rollback path that cannot be tested.
Approve a VM for replication only when every blocker has an owner and resolution date. Conditional
items must have an executable remediation step in the wave runbook; observations without impact can
remain in the evidence record.
## Primary references