Unit 7.4: Migration and Hybrid Cutover

Introduction

Migration is the unit where the platform's honesty matters most, because the largest source of project risk is a capability assumed but not present. IONOS Cloud has no native OVF/OVA import wizard: you cannot point a console at a vSphere export and have a running IONOS instance appear. Migration is therefore engineered, not imported, and the design work is choosing the right engineered path per workload and sequencing those paths so the business is never offline longer than it agreed to be.

This unit anchors on FinCorp, the German financial-services firm carrying a large VMware estate under GDPR and BSI obligations. The estate is the heaviest single use of dedicated Private Cloud in the whole course, so the migration design leans on it directly: where the target is dedicated VMware, FinCorp can keep VMs whole and use VMware-native tooling; where the target is the standard IONOS Public Cloud surface, the same VMs must be converted. Getting that fork right, workload by workload, is the architecture.

1. The Disposition Framework, Applied Honestly

Before choosing any tool, classify each workload by what you intend to change. The disposition framework (the "R" model) names the realistic options for an estate this size. The honest version is narrowed to three because the others (retain, retire, repurchase) are decisions to not migrate that workload at all:

• Rehost ("lift and shift"): move the workload as-is, same OS and application, onto target infrastructure. Fastest path, lowest application risk, no modernisation benefit.
• Replatform ("lift and reshape"): keep the application but swap an underlying component for a managed equivalent, for example moving a self-managed PostgreSQL VM onto Managed PostgreSQL. Modest effort, removes operational toil, but introduces a data-migration step.
• Refactor: change the application itself, for example decomposing a monolith onto Managed Kubernetes. Highest effort and risk, deferred to its own programme rather than folded into a cutover wave.

The disposition decision is what selects the infrastructure path, and the single most load-bearing fork is the target platform. A rehost into dedicated Private Cloud keeps the VM whole and VMware-native, so it can use VMware replication tooling. A rehost onto the standard IONOS Public Cloud surface (Compute Engine) crosses a hypervisor boundary: Private Cloud runs VMware ESXi, while the Public Cloud product family runs a different, KVM-based substrate, and the two families are not interchangeable. That boundary, not a preference, is why some rehosts are an image-conversion job and others are a replication job.

A replatform always carries a data step that the infrastructure path does not cover. Converting a database VM's disk image moves the machine; it does not make IONOS Managed PostgreSQL adopt that data. The data moves separately, by dump and restore (Section 4). Treat every replatform as two coordinated migrations: the surrounding application and the data underneath it.

2. The Three Infrastructure Paths

Each disposition resolves to one of three engineered paths. They differ in what is preserved, what tooling carries the bytes, and how much downtime the cutover costs.

2.1 Path 1: Image Conversion and Upload

This is the path when the target is the standard IONOS Public Cloud surface and the VM must cross the VMware-to-KVM boundary. There is no native OVF/OVA import, so the VM is converted into a bootable image and uploaded, then provisioned as an IONOS instance.

The non-negotiable technical requirement is the guest driver set. IONOS Public Cloud instances boot on KVM and require KVM VirtIO drivers; an image that only carries VMware's paravirtual drivers will not boot correctly or will run without disk and network performance. For Windows guests, IONOS provides an ISO image containing the relevant VirtIO drivers, which you mount as a CD-ROM drive and install before or during the cutover. The practical sequence is to install VirtIO drivers into the source VM while it is still running on VMware (so the converted image already contains them), convert the virtual disk to a supported uploadable format, upload it, and provision an instance from the uploaded image. Firmware mode matters: a guest installed under UEFI must be provisioned to boot UEFI on the target, and a guest installed under legacy BIOS must boot BIOS; a mismatch produces an unbootable image and is the most common avoidable failure on this path.

Path 1 is inherently an offline cutover for the converted workload: the source is shut down to take a consistent disk state, converted, uploaded, and booted on the target. Downtime spans the conversion and upload, which scales with disk size and link bandwidth, so it is the path with the largest and least predictable cutover window. It is the right path for workloads being modernised onto the Public Cloud surface, and the wrong path for a large estate you simply want to keep whole.

2.2 Path 2: VMware-Native Replication into Dedicated Private Cloud

When the target is dedicated Private Cloud, the VM never leaves VMware, so the migration stays inside VMware-native tooling and the cutover window collapses. The tool IONOS provides for this is VMware Cloud Director Availability (VCDA).

VCDA is a Disaster-Recovery-as-a-Service offering that protects vApps and virtual machines with asynchronous replication, migrates them, performs failover, and reverses failover, deployed between the customer's on-premises vCenter and the IONOS Private Cloud. In an IONOS Private Cloud the cloud-side appliance is auto-provisioned, and the customer deploys a matching on-premises replication appliance into the local vCenter; the two are then paired. The deployed version is VCDA 4.7.x. The on-premises appliance reaches the cloud appliance over the Private Cloud's public IP on TCP port 55443. Commercially, this is the decisive property: only protected VMs are invoiced, at 50 EUR per VM per month for VCDA Protection, and the migration feature itself is free. A large estate can therefore be migrated with VCDA at no per-VM migration charge, paying only for any VMs it keeps under ongoing DR protection afterward.

The replication model is what makes the cutover short. VCDA replicates asynchronously while the source keeps running, so the data is staged on the target before any outage. The cutover is a failover: the source is quiesced, the final delta replicates, and the VM is powered on at the IONOS Private Cloud site. Because VCDA also performs reverse failover, the cutover has a defined rollback: if validation fails, fail the VM back to the still-intact on-premises site. This is the single most important reason a large VMware estate targets Private Cloud rather than the conversion path: the VMs stay whole, the per-VM cutover window is minutes rather than hours, and the rollback is built into the same tool.

Two networking points govern how cleanly the cutover lands:

• Layer 2 extension. To let migrated VMs keep their existing IP addresses during a phased cutover, NSX-T provides an L2 VPN, which stretches a Layer 2 segment between the on-premises network and an NSX segment in the Private Cloud. NSX segments are virtual Layer 2 domains, so an extended segment lets a migrated VM sit on the same broadcast domain it had on-premises while its peers are still being moved. This is what avoids re-addressing every VM on day one and lets a dependency cluster move in stages.
• In-cluster mobility only. Once VMs are running in the Private Cloud, vMotion can move them live between hosts within the cluster (for example to balance load or to drain a host). vMotion is intra-cluster only. It is not a cross-site migration mechanism and does not move a running VM from on-premises into IONOS; that cross-site movement is VCDA's job, and it is a replicate-then-failover operation, not a live cross-site move. Do not design a cutover around moving running VMs across sites without an outage; that capability is not present.

2.3 Path 3: Backup and Restore

The third path treats migration as a recovery: back the workload up from the source and restore it onto the target. It is the slowest to cut over because it is sequential (a full backup, then a full restore) and offline for the duration, but it is the most universally applicable and needs no live link between sites. Use it for workloads where neither a clean VMware replication path nor an image conversion is warranted: low-change-rate servers, archival systems, or anything where a long maintenance window is acceptable and operational simplicity outweighs cutover speed. It is also the natural fallback when a Path 1 conversion proves unbootable and the schedule does not allow a second attempt.

2.4 Choosing Between the Paths

The following compares the three paths on the dimensions that actually drive the decision.

The rule that follows: a VM headed for dedicated VMware takes Path 2 by default, because it is the only path that keeps the VM whole and gives a short, reversible cutover. A VM being modernised onto the Public Cloud surface takes Path 1 and accepts the conversion work and longer window. Path 3 is the fallback for the long tail where neither special-purpose path earns its complexity.

3. Wave Planning and Hybrid Cutover

A large estate is never cut over at once. It is decomposed into waves, and the unit of a wave is a dependency cluster: a set of VMs that talk to each other and must move together or stay reachable across the boundary while they are split. Splitting a chatty application across the on-premises/cloud boundary mid-wave turns every internal call into a round trip over the hybrid link, so the dependency cluster, not the individual VM, is the planning atom.

Order the waves to retire risk early and dependencies cleanly:

1. Pilot wave: a small, self-contained, low-criticality dependency cluster. Its purpose is to validate the chosen path end to end (conversion or VCDA pairing, the hybrid link, the validation gates) before anything important moves.
2. Dependency-leaf waves: systems that others depend on but that depend on little themselves move before their consumers, so consumers never point across the boundary at something that has not arrived.
3. The database wave: sequenced deliberately relative to its applications (Section 4), because it is dump/restore and therefore a hard cutover, not a trickle.
4. The application and edge waves: the consumers, moved once their data and dependencies are already in place.

Throughout the migration the estate is hybrid, so the link between the on-premises site and IONOS is load-bearing, not incidental. Two constructs from Module 3 carry it: a VPN Gateway (IKEv2/WireGuard, active-passive HA on a shared public IP) for encrypted site-to-site connectivity, and Cross-Connect for a higher-bandwidth private interconnect where the migration volume or the residual cross-boundary traffic justifies it. For VMs landing in dedicated Private Cloud, the NSX-T L2 VPN of Section 2.2 is the segment-level extension that lets a dependency cluster span both sites without re-addressing. Size these links for the migration's data movement, not just steady-state traffic; an undersized link is the most common cause of a wave overrunning its window.

Each wave ends at a validation gate before traffic is shifted: confirm the workload boots, the application answers on its endpoints, the data is intact and current, and dependent systems can still reach it across whatever boundary remains. Only after the gate passes do you cut traffic over, typically by repointing DNS (Unit 3.7), which steers new connections to the migrated endpoint while the old one drains.

If a gate fails, the rollback position differs by path and must be designed in advance:

• Path 2 (VCDA): reverse failover returns the VM to the intact on-premises site. This is the cleanest rollback and another reason VMware-target workloads are lowest risk.
• Path 1 and Path 3: the source VM was shut down but not destroyed, so rollback is to power the source back on (and re-shift DNS). Keep the source intact and untouched until the gate passes; do not decommission a source in the same wave that migrates it.
• Snapshots are a within-target rollback, not a cross-site one. A VM-level snapshot on the target (whether a Private Cloud vSphere snapshot or an IONOS Block Storage snapshot) lets you roll a freshly migrated VM back to its just-arrived state if a post-cutover change goes wrong. It is region-local and VM-level, and critically it is not database-consistent: a snapshot of a running database VM may capture an in-flight transaction state that does not cleanly restore. Snapshots protect the cutover step; they do not replace the database wave's dump/restore.

4. The Database Wave: Dump and Restore

Databases are the wave that most often breaks an otherwise sound plan, because the instinct is to migrate them like any other VM. For workloads being replatformed onto IONOS managed databases, that instinct is wrong: there is no native, replication-based cutover from a source database into IONOS Managed PostgreSQL, MariaDB, or MongoDB. The supported migration path is dump and restore. You export a logical dump from the source, then load it into the target managed cluster.

This shapes the wave in three ways. First, it is a hard cutover with real downtime: to take a consistent dump you stop writes at the source, dump, restore, and validate before resuming writes against the target. The window scales with data volume, so the database wave gets the most generous maintenance window in the plan. Second, the rollback is the source itself: keep the source database online and authoritative until the restored target passes its validation gate, then switch the application's connection string. Third, a target-side snapshot is not the safety net here. Because snapshots are not database-consistent, the dump is the authoritative migration artifact and the source is the authoritative rollback. Sequence the database wave so its dump/restore window aligns with, and ideally precedes, the cutover of the applications that depend on it, so those applications arrive to a database that is already populated and validated.

Decision Summary

Use the disposition to select the infrastructure path, the target platform to confirm it, and the table below as the at-a-glance rubric.

Hard constraints to carry into every wave: there is no native OVF/OVA import (conversion is engineered); vMotion is intra-cluster only and is not a cross-site move; database migration is dump/restore only; and snapshots are VM-level, region-local, and not database-consistent. For FinCorp, the large VMware estate resolves cleanly: the bulk of the estate rehosts into dedicated Private Cloud via VCDA (whole VMs, free migration, reverse-failover rollback, NSX-T L2 VPN keeping addresses stable across phased waves), the databases earmarked for managed services replatform via dump/restore in their own windowed wave, and only the explicitly modernised workloads take the image-conversion path onto the Public Cloud surface.

Summary

Migration into IONOS Cloud is engineered, not imported: with no native OVF/OVA import, the architecture is choosing one of three honest paths per workload (image conversion and upload to the KVM Public Cloud surface, VCDA replication into dedicated VMware, or backup/restore), sequencing them by dependency cluster into waves over a sized hybrid link, and gating each wave with validation and a path-specific rollback. The database wave is its own hard cutover by dump and restore, and snapshots are a VM-level safety net for the cutover step rather than a substitute for it.

Key Points:

• There is no native OVF/OVA import; migration is engineered per workload, and the target platform (VMware vs KVM) selects the path.
• VCDA 4.7.x is the VMware-native path into dedicated Private Cloud: asynchronous replication, free migration, failover and reverse failover, with only protected VMs billed at 50 EUR per VM per month; the cloud appliance is reached on TCP 55443.
• NSX-T L2 VPN extends a Layer 2 segment across sites so phased waves keep their IP addresses; vMotion is intra-cluster only and never a cross-site live move.
• The image-conversion path requires KVM VirtIO drivers and matching UEFI/BIOS firmware, and is an offline cutover scaled by disk size and link bandwidth.
• Databases migrate by dump and restore with a hard cutover window; the source stays authoritative until the target validates, and snapshots are not database-consistent.

Important Terminology:

• VCDA (VMware Cloud Director Availability): the VMware-native DRaaS tool IONOS provides for replicating, migrating, failing over, and reversing failover of VMs between on-premises vCenter and IONOS Private Cloud; version 4.7.x, free migration, per-VM Protection billed separately.
• NSX-T L2 VPN: a Layer 2 extension that stretches an NSX segment between sites so migrated VMs keep their addresses during a phased cutover.
• Disposition: the per-workload decision (rehost, replatform, refactor) that selects the infrastructure migration path.
• Wave: a dependency cluster of workloads migrated together, with a validation gate and a defined rollback at its end.

Further Reading

• Unit 4.4: Private Cloud (Dedicated VMware) - the target platform for the VMware-native migration path
• Unit 5.3: Relational Databases - replication modes and the dump/restore migration path for the database wave
• Unit 3.6: Hybrid Connectivity - VPN Gateway and Cross-Connect, the links that carry the hybrid cutover
• Unit 7.1: Resilience and Business Continuity - customer-orchestrated DNS failover and the recovery strategies this builds on