Dr. Pranay Jha

The first question every client asks about moving off vRealize Automation is wrong. They ask which migration tool to download. There is no migration tool. VCF Automation 9 treats your Aria Automation 8.x estate as something to import and upgrade in place, not export and re-import. That single fact changes how you plan the whole project: you are not rebuilding a catalog from scratch, you are carrying a live system across a version boundary and praying the precheck is honest. It mostly is. The places it is not are predictable, and that is what this Part is about.

The mental model: upgrade, not re-platform

vRealize Automation became Aria Automation, and in VCF 9 it became VCF Automation. The 8.x to 9 step is a product upgrade with a new control plane underneath it, and Broadcom shipped it as an import-and-upgrade workflow owned by VCF Operations and its Fleet Management appliance. Your existing 8.18 appliances keep running. Fleet Management stands up a brand new VCF Automation 9 cluster beside them, pulls your configuration and data into it, validates, and only then moves the network identity over. If the upgrade fails, the old cluster is still sitting there, intact, ready to be powered back on. That blue-green shape is the single most reassuring thing about this migration, and the reason I tell clients to stop treating it like a cliff.

What you do not get is a content export you can stage, diff, and replay into a clean org. The blueprints, projects, cloud accounts, tags, custom forms and extensibility come across as part of the upgrade, as-is. That is convenient and it is also the risk: whatever cruft your 8.x estate accumulated comes along for the ride.

Prerequisites that actually gate you

Most failed migrations I see did not fail in the upgrade. They failed the precheck, or worse, they failed weeks earlier because the environment was never eligible. The gates below are not advisory. They are the difference between an import that proceeds and one that silently refuses to pull inventory.

The single-instance limit is the one that surprises people. If you ran a separate Aria Automation for dev and another for production, only one of them rides this path into Fleet Management. The other needs its own plan, and that usually means consolidating or rebuilding. Decide which instance is the survivor before you touch anything.

The import-and-upgrade flow, step by step

The work splits into two halves: get the 8.18 instance imported into VCF Operations, then drive the upgrade from the Fleet Management lifecycle UI. Each half has its own failure surface.

Import into VCF Operations

You bring the existing Automation appliances into VCF Operations so Fleet Management can see them as an integrated component. This is where the ASLC 8.18 Patch 6 dependency bites: the instance has to be cleanly registered with Identity Manager through Aria Suite Lifecycle first, or the import connects to LCM and vCenter but never pulls inventory. If you see the import hang on network data, that mismatch is almost always why.

Plan, precheck, submit

Once Automation shows up under Fleet Management Lifecycle as an integrated component, the upgrade is a guided pipeline. You create a plan that maps the correct upgrade binary to the target version, trigger an inventory sync, run the precheck, then submit. Most fields are prepopulated from the imported instance, so the temptation is to click through. Read them anyway, especially the cluster node IP pool and the internal cluster CIDR, because a CIDR that overlaps existing infrastructure is a self-inflicted outage.

Where you land: a VM Apps organization

This is the part the docs underplay and clients always ask about. When you import and upgrade an Aria Automation 8.x instance, you land in a VM Apps organization, the VM-centric model that maps closely to how 8.x already worked. You do not migrate into an All Apps organization, the new Kubernetes-API-based architecture. That is not a downgrade and it is not a mistake. It is the only model that preserves your existing blueprints, projects and extensibility without a rewrite. If your roadmap needs All Apps and its self-service Kubernetes story, treat that as a separate build alongside the migrated VM Apps org, not as something the upgrade hands you. I covered the trade-off in depth in Part 3, and it matters more during a migration than at any other time.

The dependencies nobody plans for: Identity Manager and ASLC

Here is the gotcha that catches teams who think the upgrade is self-contained. After cutover, the VCF Operations Fleet Management appliance manages VCF Automation 9, but VMware Aria Suite Lifecycle 8.x keeps managing Identity Manager. Identity Manager stays an authentication source for the upgraded instance. So you do not get to decommission the old management tooling on day one. ASLC 8.18 and Identity Manager 3.3.x have to stay alive to handle Day-N operations for identity, and deleting Identity Manager after the migration is how you lock every tenant out of the new instance.

Extensibility is where the real work hides

The infrastructure content travels well. The extensibility layer is where I budget the most validation time. Your Orchestrator workflows, ABX actions and Event Broker subscriptions come across, but vRO is now VCF Operations Orchestrator, and any workflow that called an 8.x-specific endpoint, relied on a plug-in version, or hard-coded a host name is a candidate to break quietly. Subscriptions that block provisioning are the dangerous ones: a broken blocking subscription does not throw a loud error, it stalls every deployment that triggers it. After cutover, exercise each critical catalog item end to end, not just a smoke test of the UI. The migration from vRO to VCF Operations Orchestrator deserves its own validation pass, and the workflow mechanics I walked through in Part 17 are the baseline to test against.

Verify the cutover, then know how to roll back

Once the upgrade reports success, do not trust the dashboard alone. Authenticate against the VCF Automation API and confirm the IaaS service answers. The token flow is the same shape the series covered in Part 20: exchange credentials for a refresh token, swap it for a bearer access token, then hit a read endpoint.

# 1. get a refresh token from the migrated instance
REFRESH=$(curl -k -s -X POST 
  https://vcfa.lab.local/csp/gateway/am/api/login 
  -H 'Content-Type: application/json' 
  -d '{"username":"configadmin","password":"********"}' 
  | jq -r .refresh_token)

# 2. exchange it for a bearer access token
TOKEN=$(curl -k -s -X POST 
  https://vcfa.lab.local/iaas/api/login 
  -H 'Content-Type: application/json' 
  -d "{"refreshToken":"$REFRESH"}" 
  | jq -r .token)

# 3. confirm the IaaS service is alive on the new cluster
curl -k -s https://vcfa.lab.local/iaas/api/about 
  -H "Authorization: Bearer $TOKEN" | jq .latestApiVersion

A clean run returns a version string from /iaas/api/about. If step 1 fails, your problem is identity, not Automation, and that points straight back at the Identity Manager dependency above. If step 3 returns 401 with a valid token, the IaaS service has not fully come up yet, so wait and retry before you panic.

If the upgrade itself fails, the rollback is mechanical because the old cluster never left. Power the 8.x appliances back on, restart services on every node, and re-register through Aria Suite Lifecycle.

# on any Aria Automation 8.x appliance, after powering the cluster back on
/opt/scripts/deploy.sh

# then, from Aria Suite Lifecycle 8.18 Patch 6 or later:
#   re-import Aria Automation 8.x and re-register with Identity Manager

What I would do

Treat this as an upgrade project with an identity dependency, not a content migration. My order of operations: get to 8.18 and ASLC Patch 6 cleanly, confirm no ELM and no IPv6 and vLCM-based clusters, pick the single surviving instance, freeze changes, run the precheck until it is green, then cut over in a window with the 8.x cluster held as your rollback. Keep Identity Manager and ASLC alive afterward and plan their consolidation separately. The migration carries your VM-centric estate faithfully into a VM Apps org. The places it hurts are extensibility and identity, so spend your validation budget there. If you want self-service Kubernetes, build an All Apps org in parallel rather than waiting for the upgrade to deliver it.

Running this migration soon? Tell me which 8.x size and topology you are starting from, and I will help you map the target cluster and IP plan.

References

• Broadcom TechDocs: Upgrade VMware Aria Automation to VCF Automation 9.0
• Broadcom TechDocs: Import an Existing Aria Automation Instance Into VCF Operations
• Broadcom KB: Recommended deployment journey for VCF Automation in VCF 9.0

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts