Migrating to whitesky

Move workloads to whitesky with a migration path that fits your downtime 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.

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.

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.

Examples of vendors that provide recovery media:

  • VMware (recovery tooling depending on solution)
  • 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).

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.