Every VMware renewal conversation I have sat in on for the last year starts the same way. The finance team is focused on the number Broadcom just quoted, and the infrastructure team is focused on whether to fight it or migrate. Almost nobody in that room is asking what happens to the Oracle license position sitting on top of that VMware cluster once the migration starts.
That is the gap I want to close here.
Two contracts, one shared assumption
Your VMware licensing and your Oracle licensing are governed by completely separate agreements, but they share a dependency most organizations never examine. Oracle does not recognize VMware as hard partitioning. That means Oracle’s position is that you are licensed for every physical core in every host that Oracle could possibly run on, not the vCPUs your VM is actually allocated. A four vCPU database VM sitting on a 32 core physical host, in Oracle’s read of its own policy, requires licensing for the full 32 cores at the appropriate core factor.
Worth knowing, because it comes up in every dispute I have watched: Oracle’s own partitioning policy document states outright that it is not part of your license agreement. That single sentence is the seam every audit negotiation eventually works through. Oracle applies the position as if it were contractual. Your license agreement, in most cases, does not actually say that. The gap between what Oracle asserts and what your signed agreement obligates you to is exactly where a defensible position gets built, and it is not something you want to be discovering for the first time during a live audit.
What the Broadcom changes actually touch
The Broadcom acquisition ended perpetual VMware licensing and moved the entire portfolio to subscription only, with a much higher effective core minimum than most environments were running before. Organizations that budgeted for a modest renewal are now looking at increases that reshape the infrastructure roadmap entirely. Some are staying and restructuring their cluster architecture to control the blast radius. Some are migrating to Nutanix, Hyper-V, or a public cloud target. Some are moving Oracle workloads specifically, leaving everything else on VMware.
Every one of those paths resets your Oracle exposure calculation. Not metaphorically. Literally, the moment the underlying hypervisor or hosting model changes, the core count Oracle would use in an audit changes with it.
Staying on VMware and restructuring the cluster. If you isolate Oracle workloads onto a dedicated, smaller cluster instead of a shared one, you shrink the physical core count Oracle can point to. This is the single highest leverage move available to organizations not ready for a full migration, and it is also the one most commonly skipped because it gets treated as a VMware cost decision instead of an Oracle license decision.
Moving to Nutanix or Hyper-V. Same soft partitioning problem, different vendor. If your infrastructure team picks a new hypervisor to escape Broadcom pricing without revisiting the Oracle partitioning question, you have just carried the exact same audit exposure into a new platform and possibly widened it if the new cluster is sized differently than the old one.
Moving to OCI under bring your own license. This is the cleanest reset available, because you are now inside Oracle’s own cloud licensing policy instead of its virtualization policy, and the two are not the same argument. It is not automatically cheaper, and it is not a decision to make casually, but it removes the soft partitioning dispute entirely.
Moving to a managed cloud database service. Removes the partitioning question in a different way, by putting the core counting inside the provider’s own licensing terms rather than your infrastructure. Worth evaluating on its own merits, not as a side effect of a VMware exit.
The exposure window nobody plans for
The part of this migration that concerns me most is not the end state. It is the middle. Most VMware to anything migrations run Oracle workloads on both platforms simultaneously for weeks or months during cutover. During that window, you may be running Oracle on the old VMware cluster and the new target at the same time, which means you are potentially carrying two separate licensing exposure calculations concurrently, and almost nobody accounts for that in the migration plan or the license position review.
What I would do before the migration calendar starts driving the decision
Run your own Oracle license position review against your current VMware footprint before the migration plan is finalized, not after. You want to know your actual exposure under the current architecture so you can measure whether the target architecture improves it, makes no difference, or quietly makes it worse. Use the migration itself as leverage. If you are already forced to spend money and engineering time on infrastructure change, that is the moment to right size your Oracle licensing alongside it, not eighteen months later when the VMware project is closed out and nobody wants to reopen it.
The organizations I have seen handle this well treat the VMware exit and the Oracle license review as one project with two workstreams. The ones that get an unpleasant surprise treat them as unrelated line items on two different budgets, discovered by two different teams, reconciled by neither.
If you are mid-planning on a VMware migration and have not run the Oracle side of that calculation yet, that is exactly what the Oracle License Risk Assessment is built to catch before the architecture decision locks in, not after.
Have a question about how your specific environment sits in this picture?
The discovery call is free, 20 minutes, and focused entirely on your situation. If an assessment does not make sense, I will tell you that in the first five minutes.
