Google Cloud is a recognized destination for IBM workloads under bring your own license. WebSphere, Db2, MQ and other PVU metered products can run on Compute Engine using entitlements you already hold. Because GCP appears on IBM's eligible public cloud list, sub-capacity licensing is available there. The catch is the same one that catches every cloud deployment: availability is not automatic compliance. The vCPU counting method, the tooling obligation and Google Cloud's own placement and mobility behaviors all have to line up before the reduced core count holds.
How counting works on Compute Engine.
On Google Cloud, IBM counts the virtual processor cores, or vCPUs, of each instance running the software, consistent with the eligible public cloud approach. Your Passport Advantage entitlements cover the deployment up to the capacity they represent. A machine type with more vCPUs consumes more PVU, and an instance resized to a larger shape consumes more still. The entitlement to vCPU mapping has to be kept current, because a stale mapping is exactly what an audit reconciliation surfaces.
Tooling is still mandatory.
Sub-capacity on GCP requires the same evidence as anywhere else: an approved tool such as ILMT, Flexera One ITAM or HCL BigFix Inventory, deployed within 90 days of first eligible deployment, running continuously, with quarterly reports retained for two years. The tool has to reach every project and region where IBM software runs. Workloads launched in a project the inventory tool never scanned have no sub-capacity record, and that capacity defaults to full-capacity charging regardless of how it was actually used.
Where GCP deployments draw exposure.
The recurring problem areas on Google Cloud follow the platform's strengths:
- Autoscaling managed instance groups. Capacity that scales out under load must be captured at peak, not just at a quiet scan window.
- Live migration. Compute Engine moves instances between hosts for maintenance, so the position must rest on the instance shape rather than any single physical host.
- Sole tenant nodes. Dedicated hardware changes how capacity is presented and has to be reconciled deliberately rather than assumed.
- Projects outside inventory. New projects and regions that the tool never reached are the most common source of uncovered capacity.
Google Cloud being on the eligible list is the easy part. The defensible position depends on complete tooling coverage across every project and region, a current entitlement to vCPU mapping, and peak capture for anything that autoscales. Where any of those lapse, IBM defaults to full-capacity, and an elastic cloud bill becomes the smaller of two numbers.
The buyer side position.
Defending a Google Cloud estate means proving the sub-capacity conditions were met for every instance across the lookback, reconciling vCPU consumption against entitlements, and confining any real gap to the exact project and period rather than accepting a blanket full-capacity default. Where IBM has applied the cloud counting incorrectly, that is challenged with the inventory record. The corrected position is written into the settlement alongside a forward plan that keeps coverage complete as projects and machine types change.