Run the methodology with a senior advisor.
A senior Admodum advisor will walk the methodology through with your CIO, CTO, infrastructure or procurement team on a private call. Engagements run as fixed fee, contingency or annual retainer.
Twenty-two pages on Red Hat inside the IBM commercial overlay; the RHEL socket and vCPU subscription arithmetic; OpenShift Container Platform node sizing across Self-Managed and Cloud Service variants; Ansible Automation Platform managed-node counting; the Cloud Pak VPC and OpenShift bundle reconciled against direct Red Hat subscription; the subscription-compliance audit posture; and the renewal cycle inside the IBM-overlay buyer-side methodology.
Red Hat sells subscriptions, not perpetual licences. The construct is a fixed-term entitlement to product use, software updates and support; without the active subscription, deployed Red Hat code remains technically functional but is unsupported and out of compliance with the subscription agreement that authorised the deployment.
The buyer-side reading is that the Red Hat subscription is a recurring operational commitment with no perpetual residual. There is no equivalent of the perpetual Passport Advantage entitlement that survives lapse, and there is no equivalent of a one-time purchase with optional Software Subscription and Support. Where the subscription lapses, the deployed Red Hat estate continues to run; what is lost is the support, the updates and the entitlement to continue use under the Red Hat End User Licence Agreement and Subscription Agreement.
The entitlement units across the Red Hat family are heterogeneous. Red Hat Enterprise Linux is sized on socket-pairs (physical) and vCPUs (virtual or cloud). OpenShift Container Platform is sized on two-core subscription units against worker nodes. Ansible Automation Platform is sized on managed-node counts. Red Hat Satellite is sized on managed hosts. The procurement methodology is to read each subscription unit at the SKU level rather than to assume a single subscription metric across the portfolio. This paper sets out the methodology Admodum applies inside the IBM practice across the cycle.
Red Hat Enterprise Linux is sized on a socket-pair subscription for physical deployments and on a vCPU subscription for virtual and cloud deployments. The boundary between the two is where the procurement work concentrates.
For bare-metal RHEL deployment, the entitlement counts socket-pairs. A two-socket physical host carries one socket-pair subscription regardless of core density. A four-socket host carries two socket-pair subscriptions. The high core density of modern processors means the socket-pair construct is generally favourable to the buyer at the bare-metal layer.
For virtualised RHEL deployment, the entitlement counts vCPUs assigned to RHEL guests. The Red Hat Virtual Datacenter subscription provides unlimited RHEL guests on a defined host footprint; the per-vCPU subscription provides individual entitlement against a defined guest count.
The procurement question is which construct is favourable against the deployed estate. Where the RHEL virtual footprint exceeds a defined break-even (typically four to six RHEL guests per host) the Virtual Datacenter construct is favourable; below that, the per-vCPU construct is favourable. The methodology runs the break-even calculation against the actual deployed estate, not against the projected estate.
The Red Hat Cloud Access programme allows the buyer to use existing Red Hat subscriptions to cover RHEL workloads running on AWS, Azure, Google Cloud and Oracle Cloud, instead of buying cloud-marketplace RHEL on a per-hour basis. The Cloud Access reading interacts directly with the AWS, Azure and GCP commitment design (covered in the AWS EDP, Azure MACC and GCP EDP papers). Where Cloud Access is sized against the cloud-deployed RHEL footprint, the cloud-marketplace RHEL spend can be materially reduced.
OpenShift Container Platform is sized on a two-core subscription unit applied to worker nodes. The control-plane nodes are not separately licensed where they run the cluster control plane only; the worker nodes carry the subscription cost.
OpenShift sells in two principal commercial variants. The Self-Managed variant licenses the OpenShift Container Platform for buyer-operated deployment on bare metal, virtualisation platforms or cloud infrastructure. The Cloud Service variants (Red Hat OpenShift Service on AWS, Azure Red Hat OpenShift, Red Hat OpenShift Dedicated, Red Hat OpenShift on IBM Cloud) bundle the subscription with managed-service operations.
The procurement question is which variant fits the buyer’s operating model. The Self-Managed variant is materially less expensive on a per-core basis but transfers the operational discipline to the buyer. The Cloud Service variants are more expensive but absorb the operational discipline (cluster lifecycle, security patching, multi-zone resilience, upgrade cadence) into the managed service.
The subscription counts in two-core units across the worker-node estate. A four-core worker carries two subscription units; an eight-core worker carries four. The methodology reads the worker-node sizing against the deployed-application footprint and sizes the subscription against the working node count plus a defined headroom band.
OpenShift Virtualisation extends OpenShift to host virtual machines alongside containers, using KubeVirt as the substrate. The commercial construct counts the VM workload against the OpenShift worker node subscription. Where the buyer is migrating off VMware (covered in the VMware exit paper) OpenShift Virtualisation is one of the destinations; the OpenShift node arithmetic and the Red Hat subscription pricing are direct inputs to the cost of move.
Ansible Automation Platform is sized on managed-node counts. A managed node is any endpoint (server, network device, container, cloud resource) that Ansible Automation Platform manages through inventories and playbook execution.
The managed-node count is the load-bearing input. Where the inventory includes ephemeral cloud resources, the count can move materially across deployment cycles. The procurement methodology distinguishes persistent infrastructure managed nodes from ephemeral managed nodes and sizes the subscription against the trailing-twelve-month maximum, not against the point-in-time inventory.
The Ansible Automation Platform controller-node count (the platform infrastructure that runs the automation control plane) is a separate sizing input. Controllers are licensed by node and by cluster size against the managed-node count.
Event-Driven Ansible is an additional capability that triggers automation on event sources. The commercial construct overlays the standard Ansible Automation Platform subscription with an event-source allowance. The procurement methodology reads the event-source forecast against the published allowance and sizes the uplift against the projected event-driven automation cadence.
The IBM commercial overlay sits on top of the Red Hat subscription in several constructs. The Cloud Pak family bundles OpenShift entitlement against a defined VPC capacity; Watsonx draws against Cloud Pak entitlement; the IBM Cloud OpenShift service bundles a managed OpenShift deployment against IBM Cloud commitments.
The Cloud Pak commercial construct provides VPC (Virtual Processor Core) entitlement against the IBM software inside the pack, with a bundled OpenShift Container Platform entitlement sized against the VPC commitment. The bundled OpenShift entitlement is sized to cover the OpenShift footprint required to run the IBM Cloud Pak software; it is not unlimited.
Where the OpenShift estate exceeds the bundled Cloud Pak entitlement, the additional OpenShift is paid directly to Red Hat under the standard two-core subscription. The buyer-side methodology reads the Cloud Pak entitlement against the actual OpenShift deployed footprint and reconciles the two commitments before the renewal conversation, not during it.
Watsonx and Cloud Pak for Data sit on top of OpenShift and draw the underlying OpenShift entitlement through the Cloud Pak construct. The procurement methodology reads the Watsonx and Cloud Pak for Data commitments as IBM-side procurement decisions, with the OpenShift sizing as a downstream input.
The interaction with the Passport Advantage and ILMT sub-capacity protocols is direct. The Cloud Pak VPC count is sub-capacity-eligible under ILMT; the OpenShift footprint underneath the Cloud Pak is sized against the Cloud Pak VPC commitment. The reconciliation work sits inside the IBM-overlay methodology.
Red Hat’s subscription-compliance position is materially less audit-heavy than the IBM commercial posture, but the audit risk exists. The risk concentrates in two places: deployed-use overrun against the subscription unit count, and Cloud Pak overlay reconciliation against direct Red Hat subscription.
The Red Hat subscription compliance position is largely self-attested. The buyer-side discipline is to maintain a defensible inventory of RHEL hosts, OpenShift worker nodes, Ansible managed nodes and Red Hat Satellite managed hosts, reconciled against the active subscription count. The inventory is the load-bearing record at any compliance event; the absence of an inventory is the load-bearing risk.
Where the OpenShift estate exceeds the Cloud Pak bundled entitlement, the gap is a direct Red Hat subscription requirement. The audit risk is that the gap is unaddressed at renewal and that the underlying Red Hat subscription is sized to the wrong footprint. The audit-defence methodology runs the Cloud Pak reconciliation as part of the standing IBM-overlay protocol, not as an audit response.
The seven-step audit defence protocol Admodum applies parallels the IBM Passport Advantage methodology set out in the Passport Advantage paper. The steps are: first-letter response, scope contestation, evidence-gathering protocol, ELP reconciliation, settlement framing, renewal-coupling decoupling and audit-clause renegotiation.
Red Hat subscriptions run on one-year and three-year cycles. The price-uplift discipline at renewal is the procurement input that does the most damage when left unmanaged across a multi-year horizon.
The methodology reads the renewal posture against three inputs: the deployed-use reconciliation against the subscription unit count, the multi-year commitment construct against the price-uplift cap, and the Cloud Pak overlay reading against the direct Red Hat position.
The renewal opens with the deployed-use reconciliation against the prior-term subscription. Where the deployed footprint is below the subscription count, the renewal sizes the subscription down. Where the deployed footprint is above the subscription count, the renewal sizes the subscription up with the additional discipline of an audit-defence protocol against the gap.
Three-year and five-year commitments carry a price-uplift cap that protects against the publisher-side annual list-price escalation. The procurement methodology reads the cap explicitly, requires it to be visible at signature and negotiates the protection against the deployed-use growth band rather than against the publisher-proposed band.
Where the buyer holds a Cloud Pak commitment alongside a direct Red Hat subscription, the renewal cycles should align. Where the cycles do not align, the procurement methodology pushes the renewal cycles into alignment at the next renewal opportunity. Mis-aligned cycles compound across the term and weaken the buyer-side leverage at each individual renewal.
The BATNA leverage at the Red Hat renewal table is the credibility of the exit architecture. Where the buyer has no credible exit, the renewal is a price-uplift conversation framed by the publisher. Where the buyer has a credible exit, the renewal is a methodology conversation framed by the buyer.
The RHEL exit destinations include Rocky Linux and AlmaLinux (community RHEL-compatible distributions), Oracle Linux (a vendor-supported RHEL-compatible distribution with its own commercial overlay), Ubuntu Server with Ubuntu Pro support and SUSE Linux Enterprise Server. The methodology reads each destination against the deployed RHEL application stack and the support and certification requirements (particularly where regulated workloads depend on certified RHEL deployment).
The OpenShift exit destinations include vanilla Kubernetes with the operational discipline self-built or service-managed, the cloud-provider managed Kubernetes services (EKS, AKS, GKE), Rancher with SUSE Linux Enterprise Server as the substrate and the lightweight Kubernetes distributions (K3s, MicroK8s) for edge deployment.
The methodology models the cost of move against the OpenShift-specific dependencies in the deployed application stack (OpenShift Routes, OpenShift Operators, the OpenShift developer experience, the OpenShift security model). Where the dependencies are deep, the migration cost is material; where the dependencies are light, the migration cost is contained and the exit is genuinely credible.
The credibility of the exit is the BATNA. The procurement methodology sizes the exit cost explicitly, presents it at the renewal table and uses it as the floor against the renewal pricing conversation. The exit does not have to be executed; the credibility of the exit is the renewal leverage.
The IBM Red Hat Subscription paper sits inside the IBM cluster of the Admodum white paper library and the broader platform-commitment reading. The companion papers extend the methodology to adjacent commercial mechanics:
The methodology in this paper is the methodology Admodum has applied across the IBM Red Hat engagements of the past twelve months. Each engagement is structured as fixed fee, contingency / gainshare or annual retainer. The full case studies library carries Red Hat engagement summaries; the blog publishes the running practice analysis.
A senior Admodum advisor will walk the methodology through with your CIO, CTO, infrastructure or procurement team on a private call. Engagements run as fixed fee, contingency or annual retainer.