Migrating to whitesky

Move workloads to whitesky with a migration path that fits your downtime window

In short: whitesky supports both offline and nearly online migration from VMware, Hyper-V, Nutanix, Proxmox, OpenNebula, and hyperscalers (AWS, Google Cloud, Microsoft Azure). For suitable workloads and well-planned cutovers, downtime can be reduced to a few minutes; the actual figure depends on the workload and cutover window.

Virtual machines can be migrated to whitesky in multiple ways. In practice there are two main approaches:

  • Offline migration: the workload is powered off during migration (simplest and most predictable).
  • Nearly online migration: the workload is replicated while it is still running at the source, followed by a short cutover window.

Both approaches can be used for migrations from common virtualization platforms and from hyperscalers.

Offline versus nearly online migrationOffline migration: the workload runs at the source, is powered off while it is exported, transferred and imported during a planned maintenance window, and then runs in whitesky. Nearly online migration: the workload keeps running at the source while it is replicated to whitesky, followed by a short cutover, often a few minutes, after which it runs in whitesky.workload runningworkload downOfflinesimplest, predictableat sourceexport, transfer, importin whiteskyplanned maintenance windowNearly onlineminimal downtimeat source, replicating to whiteskyin whiteskyshort cutoveroften a few minutes
Offline versus nearly online migrationOffline migration: the workload runs at the source, is powered off while it is exported, transferred and imported during a planned maintenance window, and then runs in whitesky. Nearly online migration: the workload keeps running at the source while it is replicated to whitesky, followed by a short cutover, often a few minutes, after which it runs in whitesky.runningworkload downOfflinesimplest, predictableRuns at sourcePowered off:export, transfer, importplanned maintenance windowRuns in whiteskyNearly onlineminimal downtimeRuns at source whilereplicating to whiteskyshort cutover, often a few minutesRuns in whitesky
Where the downtime sits in each approach. Bar lengths are illustrative, not to scale.

Supported migration sources

whitesky migration projects commonly start from:

  • VMware vSphere
  • Microsoft Hyper-V
  • Nutanix
  • Proxmox
  • OpenNebula
  • Public cloud/hyperscalers (AWS, Google Cloud, Microsoft Azure)

If your source platform can export disks or VM images, an offline import path is typically possible.

Offline migration (workload powered off)

Offline migration is the most straightforward option. The VM is shut down, exported, transferred, and imported into whitesky. This approach is ideal when you can plan a maintenance window and want maximum predictability.

Option A: Import VM images from S3 using OVF

Virtual machines can be imported via S3 storage using the Open Virtualization Format (OVF). This works well when the source platform or tooling can export OVF packages.

Option B: Import disks by streaming from local storage (CLI-based)

When exporting a disk to the filesystem (for example from a backup repository or another source), you do not need to upload the disk image to S3 in order to import it into whitesky.

The whitesky CLI supports direct disk import by streaming the contents of a disk image from your local filesystem into the platform.

High-level workflow:

  1. Export the virtual disk (for example VMDK, VHD(X), QCOW2, or raw image) from the source platform or backup repository to a local filesystem.
  2. Use the whitesky CLI to initiate a disk import.
  3. whitesky creates an empty disk on the target platform.
  4. That disk is exposed over the NBD protocol.
  5. The CLI then streams the contents of the local disk image directly into the target disk over NBD.

This approach avoids intermediate storage steps and allows efficient imports even from environments that do not expose object storage.

Streaming disk import over NBDThe virtual disk is exported from the source hypervisor or backup repository to a local filesystem as VMDK, VHD(X), QCOW2 or raw image. The whitesky CLI starts the import, whitesky creates an empty target disk and exposes it over NBD, and the CLI streams the image contents directly into it. No S3 or remote staging is needed.Direct disk import by streamingSourcehypervisor orbackup repositoryDisk imagelocal filesystemVMDK, VHD(X),QCOW2 or raw1whiteskyCLITarget diskin whitesky3empty disk4exposed over NBD25streamed over NBD1Export the disk to a local filesystem2The CLI starts the disk import3whitesky creates an empty disk4That disk is exposed over NBD5The CLI streams the image into it✓No S3 or remote staging needed
Streaming disk import over NBDThe virtual disk is exported from the source hypervisor or backup repository to a local filesystem as VMDK, VHD(X), QCOW2 or raw image. The whitesky CLI starts the import, whitesky creates an empty target disk and exposes it over NBD, and the CLI streams the image contents directly into it. No S3 or remote staging is needed.Sourcehypervisor or backup repository1Disk image on a local filesystemVMDK, VHD(X), QCOW2 or rawwhitesky CLI2start5streamTarget disk in whitesky3empty disk4exposed over NBD1Export the disk to a local filesystem2The CLI starts the disk import3whitesky creates an empty disk4That disk is exposed over NBD5The CLI streams the image into it✓No S3 or remote staging needed
Streaming import: the CLI writes the local disk image straight into an empty whitesky disk over NBD.

Benefits of streaming-based import:

  • No requirement for S3 or object storage
  • No need to stage large disk images remotely
  • Works with disks exported from backup repositories or hypervisors
  • Suitable for isolated or restricted environments

Option C: Recovery-boot method (restore into an empty VM)

Another offline approach is to create an empty VM in whitesky and boot it using a backup/recovery disk provided by your backup vendor, then restore the system into the new VM.

Recovery media from these vendors have been tested:

  • VMware (recovery tooling depending on solution)
  • Veeam (recovery media)
  • Acronis (recovery media)

Use this approach when your backup tooling already defines the restore process and you want the simplest “restore-to-new-target” workflow.

Nearly online migration (minimal downtime cutover)

For workloads where downtime must be minimized, a nearly online approach replicates the VM while it is running at the source. Once all VMs that form an application stack are in sync, a controlled cutover is performed.

Tested technologies

Two technologies that have been tested for nearly online VM migrations are:

These tools replicate VM state from the source environment to whitesky while the source remains operational.

Typical cutover procedure

  1. Initial replication while running
    VM data is synchronized from the source while workloads remain online.

  2. Application-level coordination
    When all VMs that serve an application are replicated and consistent, schedule a cutover window.

  3. Final sync + stop at source
    Stop the workloads (or stop the VMs) briefly, perform a final synchronization, then shut down the source VMs.

  4. Start at target
    Start the VMs in whitesky and validate application availability.

  5. Minimize downtime via DNS planning
    With proper DNS preparation (short TTL in advance) and a clean cutover plan, downtime can often be limited to a few minutes (for example ~5 minutes in many scenarios).

Nearly online cutover procedureFour phases for all VMs of an application. 1: the source keeps running while VMs replicate to whitesky. 2: all VMs are consistent and a cutover window is scheduled. 3: the source is stopped and a final sync runs. 4: the VMs start in whitesky and are validated. Downtime covers phases 3 and 4 and is often a few minutes, helped by 5: DNS prepared in advance with a short TTL.1Replicate2In sync3Final sync4Go liveSourceall VMswhiteskyall VMsrunningreplicatingrunning✓ consistentstoppedfinal syncshut downrunning ✓downtime: often a few minutes5DNS prepared in advance with a short TTL keeps the switch fastCut over the whole application stack together, not VM by VM
Nearly online cutover procedureFour phases for all VMs of an application. 1: the source keeps running while VMs replicate to whitesky. 2: all VMs are consistent and a cutover window is scheduled. 3: the source is stopped and a final sync runs. 4: the VMs start in whitesky and are validated. Downtime covers phases 3 and 4 and is often a few minutes, helped by 5: DNS prepared in advance with a short TTL.Sourcewhiteskyall VMsall VMs1Replicaterunningreplicating2In syncrunning✓ consistent3Final syncstoppedfinal sync4Go liveshut downrunning ✓downtime (3 and 4): often a few minutes5DNS prepared in advance with ashort TTL keeps the switch fastCut over the whole application stacktogether, not VM by VM
The cutover is one application event: all VMs move together, and downtime covers only the final sync and start.

Choosing the right migration path

  • Choose offline migration when you want the simplest process and can schedule a maintenance window.
  • Choose nearly online migration when downtime must be minimized and you can invest in replication tooling and cutover planning.

If you migrate multi-VM applications, plan cutover as an application event (not VM-by-VM) to avoid partial availability.

Next steps

  • Discuss your downtime window, source platform, and application dependencies.
  • Decide on offline vs nearly online migration.
  • Run a pilot migration for one representative workload before scaling out.