Part 2 of 3. Read Part 1: why companies are making the move | Read Part 3: testing VMware alternatives
VCF 9 does not give Aria customers a simple version bump. VMware Aria Operations and Aria Automation become VCF Operations and VCF Automation, and getting there is a replatforming project. The cost of that project is not the license line. It is the integration rework, the validation effort, and the deeper dependency on a single vendor.
Part 1 of this series noted that Broadcom has cut list pricing on VCF subscriptions, and that is accurate as far as list pricing goes. What organizations report at renewal has moved the other way: 59% of the IT decision-makers in CloudBolt’s CII Reality Report 2026 saw increases above 25%, 85% expect further increases, and 86% are actively reducing their VMware footprint while only 4% have completed a full migration away. List price and renewal reality are two different numbers, and the second one is the one that shapes budgets.
The engineering effort is roughly the same whether a team upgrades further into Broadcom’s stack or moves to a control plane that does not extend the lock-in. That makes this upgrade a decision point, and the question worth asking is where the effort should land before the work is scoped, and whether a VMware Aria alternative is the better destination for it.
The licensing question is the least interesting part of this upgrade
Aria Operations and Aria Automation both come across in VCF 9 as VCF Operations and VCF Automation, and both are covered by the VCF subscription. VCF Automation licenses automatically once a VCF license is assigned to a vCenter instance from VCF Operations, with no separate component license to buy.
Three things are worth knowing before that reads as good news.
VMware vSphere Foundation excludes Automation. VVF covers Operations, Operations for Logs, Suite Lifecycle, and Automation Orchestrator. Full Automation ships only through VCF. A VVF customer who wants the automation layer has to move up to VCF to get it, which is a real cost and a real decision.
The entitlement is bounded. VCF Automation may only manage VCF-licensed cores. The included capability scales with what you have licensed, not with your estate.
The license line was never where the money was. What this upgrade costs is engineering time: rebuilding automation content, re-testing every custom integration, and validating a cutover before anything goes live. That cost is the same whether the destination is VCF Automation or something else, which is the entire point of this comparison.
What the upgrade actually requires
Broadcom’s documentation is candid about what this involves. The prerequisites alone are substantial.
| Component | Requirement |
| Aria Automation | 8.18.1 or later, imported into VCF Operations |
| Aria Suite Lifecycle | 8.18 Patch 6 or later, to import Aria Automation 8.x and re-register with VMware Identity Manager |
| VCF management components | VCF Operations at 9, with fleet management and cloud proxy also at 9 |
| Identity | VMware Identity Manager certificate valid more than a year, KB 389563 prechecks passed |
Broadcom documents the Aria Automation import and upgrade as Phase 3 of management-component preparation. Once the prerequisites above are satisfied, the guided sequence itself is not the hard part: import the instance from legacy fleet management, create an upgrade plan, acknowledge warnings, run inventory sync, configure networking, run precheck, submit. That runs in roughly an hour, and VCF 9.1 provisions a new instance alongside the old one and shuts down the source nodes after cutover.
The work sits on either side of that hour.
Before it, a set of conditions that stop the upgrade outright.
| Blocker | What it takes to clear |
| More than one Aria Automation instance per fleet | Separate VCF Operations fleets |
| Instance not in integrated mode | No upgrade path at all |
| Multi-vCenter cluster configuration | Consolidate to single-vCenter |
| Automation Pipelines, VMware Cloud Director accounts, NSX-V or NSX-T manager-mode accounts, AVI Load Balancer accounts, Cloud Consumption Interface, TKG or TMC Kubernetes integrations | Remove all of them before starting |
| VMware Identity Manager | No upgrade path. VCF Identity Broker has to be deployed manually. |
Automation Pipelines, formerly vRealize Code Stream, is deprecated and unavailable in VCF Automation 9 entirely. VCF Automation 8.18.1 is the last version that supports it.
After it, the part Broadcom itself flags as the long pole. Every custom integration and every piece of automation content has to be validated before traffic switches over. Broadcom’s guidance recommends treating this as an independent workstream, separate from the rest of the VCF upgrade, because the custom coding involved can take significant time to validate and remediate.
That validation effort is the real cost of this upgrade, and it is the same effort any platform migration would require.
Two destinations, one starting effort
| Upgrade to VCF Operations and VCF Automation | Adopt CloudBolt CMP |
| Integration validation and rework equivalent to any platform migration | The same starting effort, applied to a vendor-agnostic control plane |
| Deepens dependency on Broadcom’s licensing and product roadmap | Governance, approvals and policy that carry forward when the platform underneath changes |
| Automation entitlement bounded to VCF-licensed cores, and excluded from VVF entirely | Predictable pricing and an independent roadmap |
| Future infrastructure choices stay inside the VMware ecosystem | Test Proxmox, OpenShift Virtualization, Nutanix or public cloud in parallel, with no forced cutover |
| Several integration types have to be removed before the upgrade can start, and Automation Pipelines does not come back | A brownfield, crawl-walk-run adoption model, with no forklift and no big-bang commitment |
The Aria alternative: what CloudBolt CMP offers instead
CloudBolt CMP is a control and orchestration layer built on a vendor-agnostic architecture, not tied to any single hypervisor or cloud vendor’s roadmap. The governance layer a team is about to rebuild, covering tagging, cost controls, security policy, approval chains and audit, gets encoded once and stays intact when the infrastructure underneath it changes.
The extensibility model matters more here than any feature list. CMP is Python throughout, with no proprietary runtime, so automation logic is portable and custom business logic ships as plugins rather than waiting on a vendor roadmap. Teams building against CMP are not exposed to the dependency that makes the Aria upgrade a replatforming exercise in the first place.
Adoption follows a brownfield, crawl-walk-run model. Connect CMP to the environment as it exists today, discover what is already running, and automate incrementally, starting with a single process. The free edition covers up to 100 resources, which is enough for the crawl step.
Crawl, walk, run
| Crawl | Walk | Run |
| Connect CMP to the environment exactly as it exists today | Extend automation to additional processes and teams | Full orchestration across clouds, hypervisors and platforms |
| Discover current VMs, templates and workflows | Layer in governance, approvals and policy-as-code | Includes any alternative infrastructure being tested in parallel |
| Automate one existing process, with no changes to how teams work today | Add integrations as new needs come up, on your own timeline | Self-service and cost optimization at scale, across every team |
| Live day one | No re-platform | Integrations carry forward |
CloudBolt supports over 25 cloud providers and hypervisor platforms out of the box, within a broader library of more than 200 integrations covering ITSM, IPAM, DNS, identity, monitoring, backup and IaC tooling. On-premises and air-gapped deployment options are available for regulated environments.
Testing what comes after VMware without committing to it
Because CMP does not require an all-or-nothing commitment, a team can keep running production workloads on VMware while testing alternatives under the same control plane and the same governance policies. That matters given where the market actually is: 63% have changed strategy two or more times since the acquisition.
Adopting CMP instead of upgrading deeper into Aria turns leaving Broadcom from an all-or-nothing rebuild into an incremental hedge. Teams can pilot a workload on Proxmox or OpenShift Virtualization, compare it against the VMware baseline, and make the decision on their own timeline rather than on Broadcom’s renewal calendar.
The bottom line
Every organization upgrading Aria in VCF 9 will spend real engineering time on this regardless of what happens next. The prerequisites have to be met, the blocking integrations have to be removed, and every custom integration and piece of automation content has to be validated before cutover. That effort is the same effort a move to a vendor-agnostic control plane would require.
That is why it is worth pausing before defaulting to VCF Operations and VCF Automation, and looking at whether the same work could go toward a platform designed to reduce Broadcom dependency rather than extend it.
Spend the effort on a control plane that outlasts the decision
Start building for free
Continue the series: Part 1, why companies are making the move · Part 3, testing VMware alternatives
Download PDF
Related Blogs
Testing VMware alternatives after the VCF 9 upgrade – Part 3
Part 3 of 3. Read Part 1: why companies are making the move | Read Part 2: Aria vs CMP…
