That is a great plan and layout. Makes the transition seemleas to the new environment.

Yes, a similar approach saved us much time (and downtime) when migrating VMs between two clusters with different vSphere version over a connection with small bandwidth.

Veeam manages this much better than VMware...

Neatly outlined and easy to comprehend! thank you for sharing @victorwu 

For this scenario, I cannot find the other solutions for this migration. Please let me know if you have the other approach.

Hopefully, this case sharing can help you.

The diagram only shows a single vCenter Server v7. Will this be managing both old and new hosts during the migration?

vCenter 7 is not supported to manage ESXi 5.5. In this diagram, vCenter 7 is only used to manage ESXi 7.0.

I think it’s a bit too early for me. I knew v7 couldn’t manage the old boats but for some reason completely missed the second 5.5 Windows vCenter in your diagram Victor. Sorry for the confusion on my side.

Don’t mind. Just a discussion with each expert in this community.

I said, we did a similar approach.

We had an old cluster, too. And had to bring the VMs to a V7 cluster.

Unlike you we did not replicate them over to the new cluster. We shut down the VMs on the old cluster, connected the VBR server for the new cluster to the old one and did a backup of the VMs. Then we restored on the new cluster.

We simply had some time and coukd afford some downtime and there were far less VMs than in your environment. And our Windows and Linux Admins wanted to to some maintenance for the VMs anyway.

If there were a bigger amount of VMs or downtime would have been more critical I would have done the replication approach, too.

But it was a lot faster doing the migration with Veeam than to do it with VMware procedures. So everyone was happy

very nice project and challenge!

I like this type of scenarios.

Looking at your picture, and running a quick test, would be awesome to run in small groups Veeam Replicas, so you can replicate a vm, and in a non productive hour, run a failover, if it woks properly, convert it to production machine, if not, just power on back the original and think a new plan, and so on with all of them.

we did this in the past, but not with the amount of VMS you are handling here, they were 20 or so, one half with the replicas plan, and the other half (non critical or time window very high to move) powering off the machine, taking a incremental backup, and restoring the vm in the new environment.

cheers and thanks once again for sharing this cases and scenarios.

@JMeixner Thanks for your detail information.

Thanks @victorwu nicely summarised and with a simple diagram .

Is it possible to take an outage on each VM?  Do you have from FC HBA’s that can be installed on the new hosts?  If so, I’d also be looking at connecting the new HCI platform to the old shared storage.  Mount up the datastores.  On the old hosts, shutdown the VM’s, note the VM location and unregister the VM.  On the new hosts/HCI, browse to the storage, register the VM’s and storage vMotion.  Power-on can happen before or after the storage vMotion depending on downtime requirements. I’d suggest not upgrading the virtual hardware until things are up and running and confirmed working so that if you have to roll back, you can easily enough.  Option 2 would be a cross-vcenter vMotion, but I’m not sure that you can do that between 5.x and 7.  You can upgrade 5.x to 6 to whatever.  Once you get to 6.5 I think - maybe 6.7 (check the matrix posted above) and then you could manage the old hosts in the 7.x vCenter.  Of course, as others mentioned here and since this is a Veeam forum, setting up replication (or backups and restores, but replication is going to be faster/easier) in Veeam between the old and the new hosts may be the easiest solution.

what is the best way to do this, veeam quick migration. like backup the VM from the Source 5.5 then quick migrate (the backup Copy) to the new 7.0. or there is other ways to do this? what is the most safe way on production?

what about EVC should it be enabled on the target hosts 7.0??

thank you so much for the illustration above very useful. 

This migration approach is safe and quick method.

This is perfect.  To go one step further I’d group the VM’s by priority.    Things like DC’s, SQL should come up first, then app/web servers and file servers based on dependency's etc. Test/Dev should be last so your production comes up fast.    (Depending on how much throughput your storage and network can handle at once too)

I did this exact thing moving DataCenters using SRM a few years ago.. Fired up SAN replication, let copy, then flipped the switch.. took about 20 minutes to migrate an entire DC and have it up and running. 

That was finished, the Domain was up quickly and most of the production was up very fast. 

In my case, I cannot use SRM or VR for VM migration. I can only use the Veeam VBR.

That is fine, but I’d still prioritize your VM’s and come up with a plan.  Migrating 1000 Guests at once might be a fair bit, however, if your system can handle it now is the time to try. 

In my customer’s environment, 1000 VMs are for different departments. I worked with the customer for a migration plan, we can migrate the VMs in the different maintenance windows.