A virtualization migration changes more than the hypervisor. For months, workloads run on two platforms at once, each with its own backup method, and the restore points created before the move still have to be usable after it. Planning tends to focus on moving virtual machines. The backup side gets attention late, usually when someone asks how a machine that now runs on the new platform would be restored to a date before it moved.
This post covers what needs protecting on both sides during the transition and how to avoid gaps while the estate is split.
Few organizations move everything in one weekend. A typical project runs in waves over several months, starting with low-risk workloads and ending with the databases and applications nobody wants to touch. Throughout that period there are three populations of virtual machines: those still on the old platform, those already on the new one, and those in motion. Each needs a current backup, and the team needs to know at any moment which job protects which machine.
| Stage | Backup state | Main risk |
|---|---|---|
| Before a wave | Existing jobs on the old platform | None new, provided the last backup is recent and verified |
| During conversion | Machine may exist on both platforms briefly | Neither job captures a consistent copy |
| First days on the new platform | New job starts with a full backup | Capacity and backup window spike |
| After the wave | Old chain stops growing, new chain builds | Old restore points orphaned or deleted early |
| After the project | Old platform decommissioned | No host left to restore old backups to |
When a virtual machine moves to a different hypervisor, the backup software generally treats it as a new object. Its first backup on the new platform is a full, even though the data has barely changed. Multiply that by a wave of fifty machines and the repository receives a large volume of new data in a few nights, while the old chains for the same machines still occupy space until their retention expires.
This double occupancy is the most predictable capacity event in a migration, and it is temporary. Sizing for it means adding the full size of each wave on top of normal growth for as long as the old retention runs. Backup storage headroom describes how to plan for short-lived peaks like this one.
The restore points taken on the old platform do not lose their value on migration day. A file deleted last month, a database that needs to go back to a quarter-end state or a legal request can all call for a backup that predates the move. Two questions need answering before the old platform is switched off. Can those restore points be restored to the new hypervisor, either directly or through a conversion step? And if not, how long must a small footprint of the old platform be kept to restore them?
Many backup products can restore a machine across hypervisors, but the result should be tested with real workloads, including boot, drivers and network settings. Backup migration and older restore points covers the retention side in more depth.
If the backup repository is tied to the old platform, the migration becomes two projects. That is the case when backups are stored on the hypervisor's own storage, on a virtual appliance that only runs on one hypervisor or on a target that needs a platform-specific plug-in. A repository reached over a standard protocol such as S3 does not change when the hypervisor does. Jobs for the old platform and jobs for the new one write to the same place, retention carries on and immutability settings stay as they were.
Where the repository itself also needs replacing, it is usually better to do that before or after the hypervisor move, not during it. Running two backup targets at once explains what that overlap involves.
A simple register avoids most gaps. For each machine it records the platform it runs on, the job that protects it, the date of the last successful backup on each side and the date the old chain can be released. Updating it at the end of each wave takes minutes and gives a clear answer when someone asks whether a given machine is protected today.
A restore test from each wave is worth the time as well. One machine restored on the new platform from its new chain, and one restored from an old-platform restore point, confirms both paths while the team still has the old environment to fall back on.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. It presents an S3 endpoint to the backup software and has no dependency on the hypervisor the protected workloads run on, so the same repository serves both sides of a migration. Immutability is provided by S3 Object Lock on each object, and locks set before the migration remain in force throughout.
ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB, which helps absorb the temporary double occupancy that new full backups create. It is used as a target for Veeam and other backup software.
Three things are worth settling before any machine moves: the capacity available for the first full backups of each wave, the tested method for restoring an old restore point after its source platform is gone, and the date on which old chains may be released. With those written into the migration plan, backups stop being a late surprise and become one more workstream with an owner.