Agentless migration from VMware to Skypium: a technical guide

Moving off a virtualization platform and onto cloud infrastructure gets postponed for two reasons: a long downtime window, and a step you can’t take back. Agentless migration is built to remove both — it reads your virtual machines straight out of the live environment, with nothing installed on the source, and rebuilds them on the target cloud. This guide walks through the technical flow, the downtime window you should actually expect, and what to check before and after cutover.

How agentless migration works

“Agentless” means no agent software gets installed inside the VM being moved. The migration tool connects directly to the virtualization platform’s management layer (vCenter) and takes a snapshot of the disks. That snapshot captures a consistent point-in-time state of the disk while the source machine keeps running — taking it is a matter of seconds and doesn’t stop the VM.

The transfer happens in three stages:

1. Snapshot — a consistent starting point is created for the source VM’s disks.
2. Changed-block transfer — the disk is split into fixed-size chunks and copied to the target. The first pass covers the whole disk; writes that happen after the snapshot are tracked separately, and only the changed blocks get transferred again. That means transfer time scales with how much data actually changes, not with raw disk size — even on large disks.
3. Boot — once the transfer completes, the disk is attached to a server on the target cloud that boots directly from it (boot-from-volume). There’s no separate image-building or format-conversion step; the disk moves over as-is.

If the network connection drops mid-transfer, the job doesn’t restart from zero — it resumes from the last chunk. That matters most for large disks or bandwidth-constrained links: an overnight transfer interrupted by a morning outage doesn’t have to start over.

Windows and Linux VMs go through the same flow, because the transfer operates at the disk level — the guest OS doesn’t change the migration logic, it only changes what you check post-boot (drivers, in-guest agents).

How long is the downtime window, really

Most of the transfer happens while the source machine is still running, in the background — there’s zero downtime during that part. The actual downtime happens only during cutover: the source machine is briefly stopped, the writes that landed after the snapshot get synced over, and then the target server boots on Skypium. That final step usually takes minutes regardless of disk size, because what’s being transferred at that point is only the last delta — not the whole disk.

The length of the cutover window depends on two things: how write-heavy the source machine was at that moment, and network speed. A quiet file server with little write activity has a delta close to zero; a database server under heavy load can take a few minutes for that final sync. Scheduling your busiest database servers for a quieter window shortens that final sync accordingly.

Pre-migration checklist

A few things are worth nailing down before you start:

• Take inventory. List the VMs you’re moving, along with disk count and size, guest OS, and dependencies — which server talks to which.
• Confirm disk formats. The migration tool reads VMDK disks directly; if you’re coming from a different virtualization platform, check whether a conversion step is needed first.
• Confirm the boot mode (BIOS/UEFI). Establish whether the source VM boots via BIOS or UEFI before you move it; the target server is created to match that mode. A mismatch can make the very first boot fail even when the disk transfer itself completed cleanly — checking this at inventory time, rather than after cutover, avoids an unexpected delay outside your planned maintenance window.
• Plan your networking. Decide up front how addressing on the target maps to the source — same IP range, or a new VPC — since this is the single most common cause of post-cutover connectivity issues.
• Estimate the transfer time roughly. Since the initial copy covers the whole disk, duration depends on disk size and the usable bandwidth between source and target; for a 500 GB disk, a rough division using your real transfer rate (usually below the nominal link speed) gives a realistic expectation of how many hours the first copy will take. That estimate makes the call on starting the transfer outside business hours much better informed.
• Write a test plan. For each server, spell out the concrete checks that count as “it’s working” after migration: service reachability, database connectivity, background jobs.
• Sequence the move. Start with low-dependency servers to learn the process, and save your critical servers for when you’re most confident in the flow.

Progress during transfer shows up as a chunk-level log you can watch:

transfer: disk0 chunk 128/512 done — 6.4 GB / 512 GB
transfer: disk0 delta-sync complete — 3 chunks changed
cutover: source stopped, final sync started
cutover: target server booted on Skypium

That sequence mirrors exactly what the migration tool is doing behind the scenes — knowing which stage you’re in helps you time the cutover correctly.

Rollback plan

One of the most important properties of agentless migration is that it never touches the source environment. During snapshot and chunk transfer, the source VM keeps running unmodified. That makes rollback simple: your source machine stays live until you approve cutover, so if you test the new server and find a problem, you go back to the source — nothing needs to be undone. This isn’t “restore to a previous state,” it’s just “don’t cut over yet.”

If an issue surfaces after cutover, the source machine can be kept in a stopped state for a while and, if needed, restarted with traffic pointed back at it. That’s why running the full test plan before cutover matters — it’s what minimizes how often you actually need that rollback.

Post-migration verification

Once the server is up on Skypium, don’t skip three checks: disk integrity (does the filesystem mount cleanly), network connectivity (can the target services be reached with the new addressing), and the application layer (is the database, are the background services, running as expected). Once those three pass, the migration is done and you can confidently decommission the source machine.

Ready to plan your move? Request a demo and let’s walk through your disk inventory and timeline together, and map out the migration flow for your own servers.