VMware Relocate Wave Execution

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.

Cloud Framework VMware Relocate Source Readiness Open page Cloud Framework STACKIT VM Target Sizing and Storage Selection Open page

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.

Cloud Framework Cloudbase Coriolis Open page Cloud Framework Coriolis STACKIT Installer Deploy and configure the Coriolis appliance on STACKIT before endpoint and migration setup. Open page

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.

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.

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.

Cloud Framework Hystax Acura Live Migration Open page

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.

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.

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

External source cloudbase.it Cloudbase Coriolis Open external site Leads off the trail External source hystax.com Hystax Acura Live Migration Open external site Leads off the trail