If you have tried to upgrade your current vCloud Automation Center distributed install to vRealize Automation 6.2 or if you have tried to plan for the upgrade lately, you will notice one piece of the puzzle seems to be missing. At the time vRealize Automation 6.2 was released, vRealize Orchestrator 6.0 was not released yet as it suppose to be a part of the vSphere 6.0 release(not yet released).
While the vRealize Automation 6.2 appliance has came up with a builtin vCO 6.2 with the 6.2 plugin installed which was sufficient for small deployment that did not require a distributed install, customers with distributed install are wondering what to do. In this article I wanted to highlight the three options available to you and when to approach each of these routes.
1- vRealize Orchestrator(vRO) 6.0 has been made available to vRealize Automation 6.2 customers before vSphere 6.0 go GA, where you will have to open a support ticket to obtain it. Here is the KB article documenting that: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2100951
2- Convert a vRA 6.2 appliance into vRO 6.2 appliance, again here is the KB documenting this: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2100951 (Almost there is no more use case for this with vRO 6.0 available to you through GSS. This was a temporary workaround till vRO 6.0 appliance was available for download. I have included this option here for completion and in case you read about it as the solution somewhere else on the web. Please skip this option).
3- Use vCO 5.5.2 with the vCAC 6.1 plugin with vRA 6.2. Please note while the vCAC 6.2 plugin for vCO is not compatible with vCO 5.5.2, it’s fully supported to utilize the vCO 5.5.2 with vCAC 6.1 plugin with vRA 6.2. This has created a good amount of confusion initially even with some VMware internals. After digging it with engineering, I have found out this is a fully supported configuration and with a bit of help, we have our interop matrix now updated and showing that. Below is screenshot of the compatibility matrix showing this.
Alright now that you are aware of the three different routes available to you, which one should you take. It really depend, and below is some tips to get you moving in the right direction.
1- Avoid the second route of getting a vRA 6.2 and converting it to vRO 6.0 as that will cause you a grief when upgrading in the future, and it was just a workaround till vRO 6.0 is available.
2- Go with the first route of requesting vRO 6.0 from GSS and using that with the vRA 6.2 plugin whenever possible. This will let you enjoy all the latest features of both vRO and vRA and the easiest path to upgrade in the future.
3- Utilize the third route of using vCO 5.5.2 with the vCAC 6.1 plugin with vRA 6.2 only when you have plugins that’s only compatible/working in vCO 5.5.2 and does not work in vRO 6.0. An example of this thirdparty IPAM integration plugins from Blue Cat, Info blocks, and the similar. While moving your own workflows to vCO 6.0 might require you to modify it a bit, it is worth the change, but with these plugins being maintained by the vendor and you are not able to modify it till the vendor get around to it, you might have to live with the vCO 5.5.2 till your vendor upgrade their plugin to support vRO 6.0. I have just helped a customer with such upgrade where we had to keep the vCO 5.5.2 while upgrading to vRA 6.2 as they were using the Blue Cat IPAM plugin, and all their workflows worked flawlessly without any modification with vRA 6.2 using this method.
Hope this post help clear up any confusion around this topic and save you some time on your research.