Audit Risk From Virtualization and Cloud Migration

Audit risk from virtualization and cloud migration is one of the largest and least understood sources of inherited licensing exposure, because the rules that govern how software is licensed across virtual and cloud infrastructure are complex, publisher specific, and frequently misapplied. Inherited software licensing exposure is usually latent and unquantified in standard due diligence, and nowhere is it more latent than in a virtualised estate where a single licensed product may, under the publisher's counting rules, be deemed to run across far more hardware than anyone intended. When a newly acquired company has virtualised heavily or migrated to the cloud without validating the licensing consequences, the gap between what it believes it is licensed for and what a publisher will claim can be enormous. This page sets out where that exposure comes from, as a child of the cluster on M&A software audit risk.

Audit risk from virtualization and cloud migration begins with counting rules

The core problem is that some publishers count licenses against the physical capacity a product could potentially run on, not the capacity it actually uses. In a virtualised environment governed by these rules, a database deployed on a single virtual machine can be deemed to require licensing for every physical processor in the cluster that the virtual machine could move to. A company that licensed for the cores it was using can therefore be found, under audit, to owe for the entire underlying farm. This counting logic, often described in terms of soft partitioning versus hard partitioning, is where virtualisation turns a modest deployment into a large claim. Oracle in particular is known for pursuing this exposure aggressively after a change of ownership, as set out in how Oracle targets recently acquired companies.

Why migration multiplies the risk

Migration events are inflection points for exposure because they change where and how software runs without necessarily changing the license. When a company moves a workload from a dedicated server to a shared virtual cluster, lifts a database into a public cloud, or consolidates data centres after an acquisition, the deployment footprint changes and the licensing position may no longer match. The migration often happens for sound infrastructure reasons, driven by integration teams focused on cost and performance rather than license metrics, and the licensing consequence is discovered only when a publisher counts the new environment. A buyer integrating an acquired company frequently triggers exactly this kind of migration, which is why post deal integration is a peak period for unintentionally creating exposure. The broader integration risk is covered in indirect access and audit risk after a merger.

The cloud adds its own counting questions

Moving to public cloud does not remove licensing exposure; it changes the rules that apply. Some publishers publish specific policies for how their products are counted on named cloud providers, and those policies can differ sharply from on premises rules and from each other. A workload that was correctly licensed in a data centre can become non compliant when it lands in a cloud region under a different counting convention, and bring your own license arrangements carry their own conditions that are easy to breach unintentionally. A buyer inheriting a cloud heavy estate cannot assume the previous owner validated these policies, because cloud adoption is frequently led by engineering teams without licensing oversight. Each major cloud move needs to be checked against the publisher's current cloud policy with an as of date, because these policies change.

The Broadcom VMware dimension

The virtualisation layer itself is now a direct source of licensing risk, not only the platform other software runs on. Following Broadcom's acquisition of VMware in late 2023, the licensing and pricing model for VMware products shifted toward subscription bundles, and many organisations have faced materially higher costs and tighter terms at renewal. For a buyer acquiring a company that runs heavily on VMware, this means two layers of exposure at once: the cost and terms of the VMware estate itself, and the way that estate governs the counting of every other licensed product running on it. A change of hypervisor strategy, whether forced by Broadcom's terms or chosen for cost, can reset the licensing position of the entire stack. The specific VMware exposure is examined in Broadcom VMware audit risk after a deal.

Why this exposure survives standard diligence

Virtualisation and cloud exposure is almost designed to slip past conventional due diligence. A financial review sees the license spend but not the counting rules, a technical review sees the architecture but not the contractual metrics, and neither asks how a specific publisher would measure the specific deployment. The exposure lives in the intersection of architecture and contract, which is exactly the gap that standard workstreams leave open. It takes a review that understands both the publisher's counting logic and the company's actual virtual and cloud footprint to find it, and that review has to happen against the deployment as it really is, not as the architecture diagrams claim. This is why the largest inherited exposures so often turn out to be virtualisation related: they require a specific kind of look that standard diligence does not include.

Building a defensible virtual licensing position

The remedy for virtualisation exposure is a position the buyer can document and defend, built on an accurate picture of how each licensed product actually runs across the virtual and cloud estate. That means recording which workloads sit on which clusters, what mobility is technically possible and what is contractually relevant, how the company has configured partitioning, and which cloud policies were in force when each workload was deployed. With that record in hand, a buyer can argue from evidence rather than concede to the publisher's broadest interpretation, and where genuine gaps exist it can close them deliberately rather than under audit pressure. Where the architecture can be configured to limit the licensable footprint, for example by constraining VM mobility in a way the publisher recognises, the buyer can reduce the exposure rather than merely measure it. The work is technical and contractual at once, which is why it sits in the gap standard diligence leaves, and why it repays a specific review against each publisher's current rules.

Audit risk from virtualization and cloud migration, in one line

Audit risk from virtualization and cloud migration comes from counting rules that can deem an entire cluster or a whole cloud region licensable for a single workload, and it grows every time integration moves software without checking the licensing consequence. A buyer that maps the virtual footprint against each publisher's rules closes the gap before the publisher counts it. We run that review on the buyer side only, paid solely by the acquirer.