Migrate VM's from one vRA deployment to another

[MR-T]

If I have an existing vSphere environment running 100's of VM's which have been deployed using vRA and wish to migrate them all to an entirely new platform managed by a different vRA instance, what are the steps I'd need to take and can this be achieved non-disruptively?

All the VM's will be connected to an NSX network and running on vSAN if this adds additional complexity.

Imagine a situation where the current environment is running vSphere 6.5 with vRA 7.3 but my new world is actually running ESX 6.7 with vRA 7.4

[daphnissov]

It's not going to be a fun, simple, or transparent process I'll just prompt you with that right now. You'd basically need to stand-up a fully-functional vRA 7.x environment with a new vCenter endpoint configured for the target vCenter environment where you hope to move these vRA-managed VMs. You'd then have to do a VM ingestion through CSV over into the new vRA environment keeping in mind that it's a one-for-one mapping with regard to VM-per-deployment. I don't even know if it can ingest all the NSX-specific constructs. So if you have lots of complex blueprints and deployments with ESGs and on-demand networks, etc., don't expect all that to come over into the other side. Ingestion in vRA is generally something you wish to avoid because you never end up with first-class citizens in the way you would if they were deployed natively.

[MR-T]

Thanks for the response, you've confirmed my fears to be honest.

I've been told the vRA config can be easily ported between different instances but my concern is about re-associating 100's if not 1000's of VM's with blueprints again once I migrate (ingest) them.

It's quite hypothetical at the moment but I'm trying to understand how this is going to hurt me on day 2 before I go ahead and implement the solution.

I'm building out the initial deployment as a VCF solution which leverages SDDC manager to stand up vRA.

I'm wondering if I might actually build vRA outside of this world and as I deploy new VCF stacks, they just get added to this as additional endpoints to avoid the need for any migration.

[daphnissov]

I wouldn't necessarily agree that porting the vRA config over to a fresh environment is "easy" as there is no one file to grab which represents the entire string of settings or identity of a vRA installation. There's no easy button to export and import the entirety of vRA's settings like what may be found in vSphere. It's just the nature of the beast: vRA is a very complicated stack with a lot of moving parts. Think long and hard about how and where you want to stand that environment up and its lifecycle concerns before you start off to the races with it.

[nsajepi]

About a year ago we migrated our vRA environment from 6.2 to 7.2 which had about 8000 VMs but after the migration about 2000 VMs didn't get migrated properly as we couldn't perform any reconfigure tasks on them such adding storage,CPU,... those tasks were failing. So we removed those 2000 VMs from vRA and re-imported them with the newly created blueprints (Blueprint type: Server, Action: Create, Provisioning workflow: BasicVmWorkflow). Everything has been working fine since then.