vRealize Automation veterans may still remember the migrations from vRA 5.x to 6.x and 6.x to 7.x. However, for many enterprises utilizing vRealize Automation, the migration from vRA 7.x to vRA 8.x will be your first major vRA migration. In an ideal world these migrations would only take a few clicks of the mouse. Migrating from vRA7.x to vRA8.x is going to be a lot like switching banks. Trying to figure out all the services that have your bank card on file for automatic billing and moving over automatic bill payments is tedious and time consuming. Which payments are monthly, quarterly, annually, and for how much? Wouldn’t it be nice if there were a simple tool to identify and update all the services that you have on auto-pay?
vRealize Automation is a lot like that. Whether it’s frequently deployed common workloads, special purpose blueprints that are used a few times a month, quarterly, or a handful or fewer times a year, or software customizations specific to vRA, you have to identify everything that will require hand-holding when you begin the migration from vRA7 to vRA8. The good news is that, unlike your bank, VMware does offer a migration assessment tool to help you determine if your blueprints are ready to be migrated from vRA7 to vRA8. As of this writing, we have not yet learned if the migration assessment tool will determine if your customizations and workloads are ready for migration.
vRealize Automation Migration Assessment Tool
Think of the vRA assessment tool as an overview of your bank statements that you need to comb through. To start, you add an existing vRA7 instance to this tool so it can do a discovery on what you have and provide migration recommendations. The tool offers an option to validate an embedded vRO server. As of this writing there is no option to validate against a non-embedded vRO, which most folks are running in production these days. For my testing, I configured a vRA7.5 and a vRA7.6 environment to see how they look for migration. I also chose to look at vRO in only one of my environments.
Once the assessment is complete, it will list all the business groups available for the tenants you have selected and give you a status for each. In my case (below) there are 4 business groups, but only 2 of them have any blueprints. Can you guess which two they are?
At the top it states “Assessment,” then, just below that, it states “Select business group to migrate. All dependencies for the business group will be migrated.” Currently no migration is available; however, this information leads me to believe that this migration assessment tool will be the tool used in the future to perform such tasks.
Once you open up the business group you want to work with, you are then presented with a list of dependencies for that business group. Dependencies include constructs like Endpoints, Reservations, Approval Policies, vRO Endpoints, Xaas Blueprints, and Composite Blueprints.
Drilling down into Endpoints reveals a list of available Endpoints with a migration status in my environment. I have two Endpoints and one is Ready and one is Ready with Warnings.
Upon further investigation into the endpoint with warnings, I see that the warnings are all related to custom properties defined on the EndPoint. This explanation makes sense considering properties are almost non-existent in vRA8, and you cannot define properties on vRA8 Endpoints. What I find to be a little misleading is the migration assessment tool shows that the properties are “partially supported.” I searched the documentation to distill what that means, but I could not find any explanation. My best guess is that you can define tags within vRA8 and use tags in place of properties, which makes them “partially supported.”
When I investigate items under XaaS Blueprints (see image below) I see a large number of SovLabs XaaS Blueprints that are not ready to migrate, and a handful that are ready to migrate. After looking through the list it seems that the determining factor between an XaaS Blueprint being ready or not is whether or not the blueprint uses vRO custom resources. In my opinion, that criteria is not a great way of determining and reporting if something is ready to migrate to vRA8. Furthermore, I reviewed the list of XaaS Blueprints that it says are ready and one by one I realized they would not work work with vRA8.
The assessment tool looks for a few very finite requirements that VMware knows are currently not available in vRA8. But that’s just the tip of the iceberg. You will need to understand what your vRO workflow is doing that the XaaS Blueprint is calling. The assessment tool does not inspect your workflow and understand what its functions are.
Here’s an example: one of the XaaS items that is ready for migration is used to inspect and report on vRA7 custom properties. It looks across all the constructs in vRA7 to report on where properties are defined and what their values are. It even gives you the option to bulk update those properties. Although the assessment tool says this functionality is ready for migration, it certainly will not work on vRA8.
When investigating the assessment tool for Composite Blueprints, the tool presented me with some blueprints that were Not Ready, some that are Ready With Warnings, and some that are Ready. Here is what I discovered that each of those terms actually means.
Not Ready – Blueprints with nested blueprints inside, blueprints with items other than networks on the canvas, and Blueprints with XaaS items on the canvas.
Ready With Warnings – Blueprints with reserved vRA7 custom properties, including properties such as _deploymentName, Extensibility.LifeCycleProeprties, and other vRA7 specific reserved properties.
Ready – If the blueprint doesn’t meet any of the criteria listed in the above two statuses, then the blueprint is deemed “Ready”. Be careful though: the assessment tool has no idea what other properties values are actually used for. It only knows that they are not reserved vRA7 properties that have been deprecated, so they must be good. All SovLabs properties will be marked as ready and all properties you may have created on your own will be marked as ready. You will have to do your own due diligence to determine what these properties are used for.
There does not appear to be a check to see if these properties are used to trigger event subscriptions, which would potentially make them unsupported if the state they are triggering is no longer available in vRA8. Further, the assessment tool has no idea what they are being used for in your custom or third party workflows, so it’s best to assume that, if they are used in vRO workflows, they are not ready for vRA8.
Approval Policies, Reservations, Business Groups, and other Constructs
When looking at these other constructs, the assessment tool is really just looking at the custom properties defined on the constructs. If the assessment tool sees vRA7 reserved properties that are not supported within vRA8, the tool will flag these properties as “Ready with warnings”. Otherwise these properties will be considered “Ready”.
The assessment tool may give you some insights into what you should look out for, but, in its current form, the tool’s output can be very misleading. The best approach to building a migration plan is to start with a manual assessment. When using third party integrations, custom integrations, and your own properties, the assessment tool just doesn’t have the insight to know if the properties are supported.
Also, keep in mind the differences in concepts and constructs between vRA7 and vRA8. These changes may be cause to rethink how you accomplished something in vRA7, and may justify a change in property locations.
Stay tuned for Part 2 of vRA8 Migration Considerations for a more in depth look at vRO workflows, event Subscriptions, and why every workflow you created will need to be modified or completely re-written.