I can't say specifically if it's the best option for your environment, but for us it worked perfectly. Difficult to think how we would have managed it without.
We moved one of our EMC Data Domains to the new DC, and used the nightly Backup Copy Jobs from that, to seed the VMs.
Then ran replication updates overnight for each server.
That step isn't required, but cuts down significantly on the preparation stage.
On the day of each migration, we ran the Replications Jobs to run continuously, so the delta was as small as possible.
When each migration window arrived, we powered down the VM, did a final replication with the VMs powered off - while our Comms engineers migrated the VLAN/IP range.
The VMs could then be powered on at the new DC with the original IP config, and the VMware HW and tools versions updated.
There was very little downtime, but obviously this wouldn't be suitable where zero downtime is required.
Think the only real issue related to Veeam that we faced was a recurring invalid CBT data bug on one file server which caused a digest recalculation every night. Eventually we spun it off onto its own replication job, wiped the destination VM and restarted to fix.
Extending drives on the source VM, also causes a digest recalculation (a colleague has just done this, this morning - right before the final migration
). So remember an embargo on that before migration dates.