Now that vRA 8 is generally available, I wanted to put together a list of honest FAQs that will hopefully help people understand this release.

Set The Stage

To begin with, let's just get this out there because it's going to be the biggest shocker for most people who are already familiar with and users of vRA 7.x.

vRealize Automation, as we have known it up to this point in time (up through vRA 7.6) is effectively gone and finished. It will not be developed further. There is an entirely new application–a ground-up rewrite–which is replacing it that VMware have also decided to call, for continuity purposes, vRealize Automation, but for all intents and purposes it is not vRealize Automation. Let that soak in for a minute. Like with all change, some of it is good (and much is extremely good), and some of it is bad and will negatively impact certain customers. Keep in mind that this is an entirely new platform that seeks to bring many new capabilities to the formerly-known-as-vRA application, and new platforms bring new challenges.

Can I upgrade?

No, there is no upgrade path, only a (very) limited migration path which is not even available yet. As stated, vRA 8 is an entirely new application with all new constructs. There is no in-place upgrade process. There cannot be an in-place upgrade process. As of 8.0, there is only an extremely limited migration path, and only from vRA 7.5 or 7.6.

What is this thing?

vRA 8 is effectively a single appliance packaging of the SaaS application known previously as Cloud Automation Services (CAS) now renamed to vRealize Automation Cloud. It is virtually 100% identical except packaged in an appliance for on-premises deployment and consumption.

What about vRO?

vRO still exists and your content can still be leveraged. HOWEVER, because vRA 8 is an entirely new beast with entirely new constructs and architecture, any custom-written workflows you have will almost certainly have to be altered with some of them requiring an entire rewrite. More specifically, any workflows that leveraged any portions of the vRA or vRA Infrastructure plug-ins for vRO will have to be redesigned. There is no more café and there is no more IaaS component to vRA 8. vRA 8 has an entirely new API as well, so any workflows that used REST to speak to vRA 7 will have to be almost totally rewritten.

How is extensibility in vRA 8 different?

Quite significantly. There is a new extensibility feature in vRA 8 called Action Based Extensibility (ABX) which is effectively a Functions-as-a-Service (FaaS) ability. In using ABX, you write small snippets of code in one of the supported interpreters that fires at the appropriate phase. For more information on ABX, see blogs here, here, and here.

It doesn't have X feature!

Keep in mind that vRA 8 is effectively a 1.0 release. No 1.0 releases are ever fully featured. You will not have full feature parity with vRA 7 in vRA 8.0. And it probably won't be in 8.1 or even 8.2. Approval policies, for example, are not even included in vRA 8.0. Ensure your expectations are set appropriately when going into a brand new platform in effective version 1.0.

Where are custom properties?

Custom properties are gone. They are replaced by tags which are also key-value pairs. See the official documentation for more info.

What about software components?

Software components are also gone from vRA 8. The replacement, at this point in time, is cloud-init which is by comparison an extremely limited version of software components. And, before you ask, no, there is no migration path for that either.

But my X endpoint is gone

vRA 8.0 does not support certain endpoints any longer.

Can I still use gugent?

The guest user agent (gugent) is also gone and replaced with cloud-init.

What about deployments to public cloud?

You'll be pleasantly surprised by vRA 8's native abilities to deploy to public cloud! What was previously a bolt-on experience in vRA is now a true first-class citizen. Even certain cloud provider PaaS offerings can be authored and deployed through vRA 8! This is truly one of the greatest points of vRA 8 that you should investigate if vRA 7.x was holding you back in that regard.

How should I approach a migration?

If you've read the points above you'll understand that vRA 8 represents an entirely new platform with only a limited migration path. The best course of action I can recommend in order to adopt vRA 8 is the following workflow:

1. Deploy vRA 8 in your environment now. If you don't want to do this or can't, get a subscription to vRA Cloud as it is essentially the same thing. This will give you familiarity with where things are and how things work without being under pressure to learn it all on day 1. A lab deployment is a great place to start.
2. Upgrade to vRA 7.5 or 7.6 if you can. Not only are these two versions the only ones with a migration path available, they'll also give you the longest time in a supported posture before you must get off of them. As of this writing, the end of general support (EoGS) date for vRA 7.5 is 17 December 2020, and EoGS for vRA 7.6 is almost a year-and-a-half longer at 11 April 2022. This is subject to change, of course, but vRA 7.6 is going to give you the longest "ride it out" period before you have to make a change.
3. Perform a migration assessment against vRA 7 to understand the types of things that will require the most re-work. You will be rewriting and redesigning lots of things. That's just a foregone conclusion. The best thing you can do now is to prepare yourself and categorize tasks into work streams, especially if you're heavily leveraging custom extensibility.
4. Stay current with blogs, release notes, documentation, and news of vRA 8 developments. There will be lots of changes in the coming releases which will make the transition smoother and maybe enable a migration of previously un-migrateable things. You need to keep on the cusp of any developments to see how you can leverage them to make your life easier.
5. Avoid adopting new functionality in vRA 7.x if you can. Feature X in vRA 7 may not translate to Feature Y in vRA 8, not today and possibly not tomorrow. You should avoid adopting any new functionality in vRA 7 if you possibly can because you may be making your life harder when it comes to a migration path later. In many cases, you might be able to leverage a "pluggable" system external to vRA 7 which is more easily connected to vRA 8 than using native functionality.

This guide is a work in progress and will be updated as time goes on.