Leveraging Veeam to replace/upgrade 2 hosts at remote site

[pkelly_sts]

We're looking to upgrade two ESXi 4.1 hosts at our smallest site to newere h/w & ESXi versions (prob sticking with 5.5 for now for compatibility reasons) and I'm trying to architect it in such a way as to minimise impact on Veeam backups/replication.

ATM there is very little/no local backup storage but just enough space for a few replica restore points so we're effectively active/passive there (no shared storage) with VMs replicated from active to passive first, then backup from active to primary site, then replicas created at the primary site from the backup data.

B&R server is at primary site, remote site only has proxy VMs.

I'm trying to minimise the impact of "starting again" backup-wise as much as possible but not sure what's achievable bearing mind VMs being shifted around etc. Full backup is currently around 250Gb, link back to primary site is around 10Mb but has critical use during the day so can't be saturated during working hours.

I am able to temporarily have all 4 hosts (2 old & 2 new) up & running at the same time at the remote site but won't be able to do vmotion due to no shared storage & the old hosts being on 4.1 (so can't do host & datastore vmotion).

If I use Veeam to do a quick migration between hosts, then repoint the backup job to the newly migrated VMs, will it recognise them & only need to recalculate digests, or will it see them as completely new VMs & so want to do a full new backup?

I'm half-thinking about bringing some sort of USB storage with the new hosts & doing a new "local" seed backup to USB, then taking that back to primary site but I think things are likely to take longer than the individuals doing the work will want to wait (first wait for initial backup, then wait to copy that to USB though with USB 3.0 & pass-thru it'll probably not be as bad going direct)

Any other suggestions to minimise data transfer over the WAN?

Paul

[foggy]

Paul, since the VMs will be registered on the new hosts with different ID's during the migration, they will be treated by Veeam B&R as new ones, so I'd use some sort of seeding to avoid entire VM data to be sent over the slow link.

[pkelly_sts]

Ah, thought as much, thanks for the confirmation.