---
title: "VMware Relocate Wave Execution"
description: "Execute controlled VMware Relocate waves to STACKIT through complete Coriolis or Hystax Acura paths with test migration, cutover, validation, and rollback."
scfAsset:
  managed: false
  category: "runbook"
  external: false
  tags: ["design-and-mobilize", "use-cases", "relocate", "vmware", "coriolis", "acura", "cutover", "rollback"]
  maintainers:
    - user: "lukas.weberruss"
source_url: "https://framework.stackit.cloud/migration/assetcontainer/stackit/vmware-relocate-wave-runbook/"
source_file: "docs/migration/assetcontainer/stackit/vmware-relocate-wave-runbook.mdx"
---

## Purpose

Use this runbook to execute one approved VMware Relocate wave to STACKIT. It provides two complete
tool paths: Cloudbase Coriolis and Hystax Acura. Select one path for the entire wave and retain the
same tool, inventory identifiers, mappings, and evidence through test migration and final cutover.

The runbook assumes that applications remain VM-based. Architecture modernization, database
replatforming, and application refactoring require separate plans and acceptance criteria.

## Entry criteria

Do not start replication until all entry criteria have passed:

- Wave scope and dependency groups are frozen and every VM has a stable source identifier.
- VMware source readiness, tool-specific prerequisites, and recovery points are verified.
- Target machine types, volumes, performance classes, networks, addresses, security groups, and
  placement are approved and available within quota.
- Application-level consistency, test cases, maintenance window, expected downtime, and maximum
  cutover duration are documented.
- Source freeze, traffic switch, monitoring activation, and rollback actions have named technical
  owners.
- The source retention period and the authority to delete source VMs are defined before cutover.

<CardGrid>
  <LinkCard
    title="VMware Relocate Source Readiness"
    href="/migration/assetcontainer/stackit/vmware-relocate-source-readiness/"
  />
  <LinkCard
    title="STACKIT VM Target Sizing and Storage Selection"
    href="/migration/assetcontainer/stackit/stackit-vm-target-sizing-and-storage/"
  />
</CardGrid>

## Wave control record

Create one version-controlled control record for the wave. Include:

- source and target VM, disk, network, address, and security-group mappings;
- selected tool and appliance or service version;
- initial-copy start, latest successful delta, and measured replication lag;
- ordered application shutdown and startup procedures;
- technical and functional test cases with objective pass criteria;
- cutover timeline, checkpoints, hold points, and decision authority;
- rollback trigger, latest safe decision time, data reconciliation method, and source retention;
- links to logs, screenshots, checksums, test results, and approvals.

Run the procedure first with a low-risk pilot that represents the intended operating-system, disk,
network, and application patterns. Promote the runbook to larger waves only after pilot findings are
incorporated.

## Coriolis execution path

Select this complete path when Cloudbase Coriolis is the approved migration tool.

### Deploy Coriolis on STACKIT

1. Run the Coriolis STACKIT Installer dry run and cloud check against the approved project, region,
   machine type, storage performance class, network, DNS, and TLS configuration.
2. Deploy the licensed appliance, store its structured result and generated credentials securely,
   and rerun the installer to verify that it reuses the intended resources.
3. Verify appliance backup, administrative access, TLS, time synchronization, monitoring, quota,
   and the migration data paths that are not covered by the HTTPS user interface.

<CardGrid>
   <LinkCard
      title="Cloudbase Coriolis"
      href="/migration/assetcontainer/cloudbase/cloudbase-coriolis/"
   />
   <LinkCard
      title="Coriolis STACKIT Installer"
      description="Deploy and configure the Coriolis appliance on STACKIT before endpoint and migration setup."
      href="/migration/assetcontainer/stackit/coriolis-stackit-installer/"
   />
</CardGrid>

### Configure endpoints and minion pools

1. Create the VMware source endpoint and STACKIT destination endpoint with dedicated credentials.
   Test authentication, certificate trust, inventory discovery, and API access independently.
2. Configure the source and destination minion pools that execute Coriolis operations. Verify worker
   health, capacity, concurrency limits, routing, name resolution, and access to both endpoints.
3. Confirm that a worker can reach every required management and data-transfer service. Browser
   access to the Coriolis appliance alone does not prove endpoint-to-endpoint transfer readiness.
4. Record endpoint and minion-pool identities and versions in the wave control record so retries and
   cutover use the same execution topology.

### Design and execute the Coriolis Transfer

1. Create one migration Transfer definition for each approved VM or consistency group. Select the
   source instance and resolve every source disk and network to the approved STACKIT target design.
2. Confirm Coriolis guest support and OS-morphing behavior. Add required bootloader, storage-driver,
   network, or cloud-initialization remediation to the control record.
3. Start the first Transfer execution while the source workload remains active. Monitor source
   snapshots, worker health, bytes transferred, throughput, destination capacity, and failures.
4. Run subsequent Transfer executions to synchronize changed disks. Repeat until the measured delta
   duration fits the cutover window, then preserve the successful execution ID and its evidence.

<Aside type="caution" title="Transfer and Deployment are the migration workflow">
  Use Coriolis Transfer executions to synchronize disks and a Deployment to create the destination
  VM. A Coriolis Replica is the disaster-recovery workflow and is not the migration object used by
  this runbook.
</Aside>

### Test the Coriolis Deployment

1. Create a Deployment definition from the approved Transfer and map the destination machine type,
   boot and data volumes, networks, addresses, security groups, and deployment options.
2. Run a Deployment execution into an isolated target network without switching production traffic.
3. Verify boot, disk discovery, file-system integrity, NIC naming, routes, DNS, NTP, certificates,
   and STACKIT Server Agent state. Activate Agent Service once for the destination project before
   using agent commands; this is separate from agent installation/provisioning on individual servers.
   Start dependencies and the application in the approved order.
4. Run technical and functional tests while preventing production messages, jobs, and shared-service
   writes. Record defects and timing, then delete or isolate the test VM before another rehearsal.
5. Correct the Transfer mapping, Deployment definition, or guest remediation and repeat Transfer and
   Deployment executions until all mandatory tests pass.

### Cut over with Coriolis

1. Confirm the latest successful Transfer execution, current source health, target capacity,
   decision owners, and rollback deadline at the cutover start gate.
2. Apply the application write freeze and stop services in the approved dependency order.
3. Shut down the source VMs where required to prevent new writes, run the final Transfer execution,
   and verify its completion, transferred-disk state, and consistency evidence.
4. Run the production Deployment execution from that Transfer. Apply only the approved production
   addresses, routes, security groups, DNS, and load-balancer changes.
5. Continue with the shared validation and rollback gate. Keep the source VMs powered off and
   protected from automatic restart.

## Hystax Acura execution path

Select this complete path when Hystax Acura is the approved migration tool.

### Prepare Hystax Acura and the source

1. Deploy and license the customer-isolated Acura components according to the approved STACKIT
   target architecture. Verify administration access, backup, time synchronization, monitoring,
   target storage, and target API access.
2. Register the VMware source and STACKIT target with dedicated credentials and validate the
   documented management and data-transfer paths.
3. Deploy and verify the required Hystax replication agents for the selected VMware integration.
   Confirm VMware Tools, Changed Block Tracking, snapshot safety, datastore headroom, and required
   vCenter or ESXi connectivity before protecting a VM.
4. Freeze the source VM identifiers and target mappings used by the migration wave.

<LinkCard
  title="Hystax Acura Live Migration"
  href="/migration/assetcontainer/hystax/hystax-acura-live-migration/"
/>

### Start Acura replication and store target state

1. Start background replication for the approved application VMs, their disks, and required
   metadata. Monitor source snapshots, agent health, throughput, datastore growth, and failures.
2. Verify that replicated data is stored as the expected volumes and snapshots in the target cloud
   and that retention does not exhaust target quota.
3. Allow full and incremental replicas to complete until replication lag and the expected final
   delta fit the cutover window.
4. Resolve agent, snapshot, CBT, capacity, or connectivity errors before accepting a recovery point.

### Build the Acura migration plan

1. Create the migration plan from the approved VM, disk, network, machine-type, address, and
   security-group mappings.
2. Encode dependency order and application launch sequence in the orchestration plan. Keep DNS,
   load-balancer, and other production traffic switches in the wave control record.
3. Review the plan against the frozen target design and record the version selected for rehearsal.

### Test the Hystax Acura migration

1. Spin up a test migration from the selected recovery point in an isolated STACKIT network without
   redirecting production traffic. Acura may repeat this rehearsal without stopping replication.
2. Verify orchestrated launch order, boot, disks, file systems, NICs, routes, DNS, NTP, certificates,
   and STACKIT Server Agent state.
3. Run the approved functional and performance tests while preventing production messages, jobs,
   and shared-service writes from the isolated target.
4. Record defects and timing, clean up or isolate the test environment, update the migration plan,
   and repeat the test migration until all mandatory checks pass.

### Cut over with Hystax Acura

1. Confirm the latest healthy replica, current source health, target capacity, approved migration
   plan, decision owners, and rollback deadline at the cutover start gate.
2. Apply the application write freeze and stop services in the approved dependency order.
3. Shut down the source VMs where required to prevent new writes, complete the final incremental
   replication, and verify the resulting recovery point.
4. Run final cutover through the approved orchestration plan, then apply the planned production
   addresses, routes, security groups, DNS, and load-balancer changes.
5. Continue with the shared validation and rollback gate. Keep the source VMs powered off and
   protected from automatic restart.

## Shared validation and rollback gate

Start validation as soon as target instances are reachable. Record timestamps because the remaining
rollback window is a technical constraint.

<Steps>
1. Validate VM state: boot, console, disks, file systems, mounts, network interfaces, routes, DNS, NTP, certificates, Server Agent, and required operating-system services.
2. Validate data state: expected recovery point, file or database consistency, checksums or record counts, and absence of unintended writes on the source.
3. Start dependencies and applications in order, then run health checks, synthetic transactions, integrations, scheduled jobs, and mandatory business tests.
4. Confirm logs, metrics, alerts, backups, administrative access, and security controls in the target environment.
5. Compare CPU, memory, disk latency, IOPS, throughput, network behavior, application latency, and error rates with the approved acceptance thresholds.
6. At the decision deadline, either accept the target or execute the documented rollback. Do not drift into an unbounded troubleshooting window.
</Steps>

Rollback is safe only while data ownership remains clear. If the target has accepted writes, stop
target processing and execute the approved reverse synchronization or reconciliation method before
the source is restarted. Never power on both copies with production connectivity unless the
application design explicitly supports concurrent writers.

## Completion and source retention

The wave is technically complete when:

- mandatory technical and functional checks pass and the target is the declared system of record;
- monitoring and backup evidence is available from STACKIT;
- defects, temporary exceptions, and follow-up actions have owners and deadlines;
- actual replication, freeze, cutover, and validation durations are recorded for the next wave;
- source VMs remain powered off and access-controlled for the approved retention period;
- source deletion occurs only after retention expiry, recovery confirmation, and explicit approval;
- the initial target sizing is handed to Optimize with its measurements and acceptance thresholds.

## Primary references

<CardGrid>
  <LinkCard
    title="Cloudbase Coriolis"
    href="https://cloudbase.it/coriolis/"
  />
  <LinkCard
    title="Hystax Acura Live Migration"
    href="https://hystax.com/acura-live-migration/"
  />
</CardGrid>