Sixty eight. That is how many Red Hat OpenShift core pair subscriptions the reference estate in this series needs, and it is the number every finance conversation about this migration eventually collapses into. Getting it right matters less than most people assume. Getting the ten months either side of it right matters far more, because that is where the money actually goes.

Tanzu Kubernetes Grid Integrated Edition (TKGI, formerly Enterprise PKS) has a hard date on it. Broadcom has confirmed October 2027 as official End of Support, and TKGI 1.2x cannot run against VMware Cloud Foundation 9.1 or NSX 9.1 at all, because NSX 9.x removed the legacy Management Plane API that the NSX Container Plugin (NCP) depends on. From August 2026 that leaves roughly fourteen months. A business case written against fourteen months looks nothing like one written against three years, and pretending otherwise is how these programmes end up half finished with two platforms in production and no budget left.

Counting core pairs for a TKGI estate

Red Hat sells self managed OpenShift two ways. A core pair subscription covers 2 physical cores or 4 vCPUs, and a bare metal node subscription covers one physical server regardless of socket or core count. On a hypervisor such as vSphere you do not get to choose. Red Hat is explicit that bare metal node subscriptions require OpenShift installed directly on the hardware with no third party hypervisor in the way, so a vSphere estate is entitled by core pair and nothing else. Anyone quoting you socket based pricing for OpenShift on vSphere has misread the guide.

Two definitions do most of the work in the count. Compute nodes, where your application pods run, require subscriptions. Control plane nodes, which run the Kubernetes orchestration layer, and infrastructure nodes, which run cluster supporting pods such as the ingress routers and the internal image registry, have their entitlements included and are not counted. Core pair subscriptions also pool at the estate level rather than pinning to a host, so 68 subscriptions cover 272 vCPUs spread across any number of clusters.

Here is the count for the reference migration this series follows: three TKGI 1.18 clusters called dev, staging and prod, landing on three OpenShift 4 clusters installed with the installer provisioned infrastructure method on vSphere.

Core pair worksheet for the reference estate. Take this table, swap in your own node counts, and you have a defensible first quote.

Look at the last two columns together. You provision 392 vCPUs of virtual machines and pay for 272 of them. Roughly 31 percent of your OpenShift compute footprint is unentitled, and it is unentitled only because you deliberately separated those roles. That separation is the whole trick, and it is where most first attempts leak money.

Cost lines a migration business case must carry

Subscription count is the easy part. What sinks approvals is a paper that lists one recurring licence line and calls it a business case. A TKGI to OpenShift migration has at least eight cost lines, three of them one time, and only two of them go away when the old platform does.

Eight lines, and only two of them stop when Ops Manager is deleted.

On public pricing Red Hat advertises reserved self managed OpenShift from $0.076 per hour based on 4 vCPUs on a three year contract, which annualises to roughly $666 per core pair. Treat that as a floor and nothing more. Every negotiated Premium 24×7 line I have seen on a real estate of this size lands well above it, and the OpenShift Platform Plus edition, which bundles Advanced Cluster Management, Advanced Cluster Security and Quay, is a different number again. Put the core pair count in the business case and put the vendor quote beside it. Do not put a modelled unit price in a board paper.

One more warning about the labour lines. Sixty of the 190 engineer days go to Security Context Constraints (SCC), the OpenShift admission mechanism that decides what a pod is permitted to ask for. TKGI estates almost always ran a permissive PodSecurityPolicy posture, and the OpenShift default of restricted-v2 rejects a great deal of what used to be normal. Part 3 broke that spend down workstream by workstream, and Part 7 takes the mechanism apart properly. For the business case the only thing that matters is that the largest labour line in this migration is application remediation, not platform build, and that number belongs in the paper on day one.

Double run window and why it dominates the budget

Because there is no conversion path from TKGI to OpenShift, you stand the new platform up beside the old one. That single architectural fact produces the defining budget shape of the whole programme. From the moment you install the first OpenShift cluster until the moment the last TKGI workload cuts over, you are paying for two platforms, two sets of hosts and two operational rotas.

Modelled against the twelve month plan below, with TKGI steady state indexed to 100, the overlap looks like this.

Three things in that chart are worth arguing over with whoever holds the budget. Peak combined spend is 1.8x, not 2x, because OpenShift entitlement arrives in three tranches as clusters land rather than all at once. Six consecutive months sit at or above 1.6x, and that sustained plateau is harder to fund than a single spike. And month 12 lands back at 100, which is the honest promise: this migration does not reduce your platform cost, it changes what you are paying for and buys you a supported runway past October 2027.

Note that subscription overlap and hardware overlap are different lengths. Entitlement runs double for ten months, months 3 through 12. Physical capacity only needs the extra 18 hosts for about seven months, because once dev and staging cut over in months 8 and 10 those TKGI hosts come back into the pool and get re racked as OpenShift compute. Whoever runs capacity planning needs both numbers, and they will not thank you for giving them one.

Phased timeline against an October 2027 clock

Fourteen months of runway and a twelve month plan gives you two months of slack. That is tighter than it sounds, because the two phases that overrun are never the platform build. Assessment overruns when nobody has ever inventoried the estate properly, and application remediation overruns when the first restricted-v2 rejection lands on a team that did not know it was coming.

Five phases, ten months of overlap, two months of slack against October 2027.

Pick your target minor version at the start of phase 2 and then hold it. OpenShift 4 ships on a roughly four month cadence with at least four minor versions supported at once. Full Support for a minor ends six months after general availability or 90 days after the next minor ships, whichever is later, and Maintenance Support ends 18 months after general availability. Red Hat designates even numbered minors as EUS releases, and the optional Additional Term 1 and Term 2 add-ons take a single release out to 36 months, with Term 3 reaching 48.

Choosing OpenShift over the alternatives

OpenShift is one of two credible landing places for a TKGI estate, and the other one is worth naming honestly. If your organisation is committed to VMware Cloud Foundation 9 and staying on NSX, then vSphere Kubernetes Service (VKS) is a shorter hop than OpenShift, with fewer moving parts to relearn and no new vendor relationship to build. That path has its own series on this site, and if that is your destination you should be reading the TKGI to VKS guide instead of this one. Everything below assumes you have already made that call.

Once OpenShift is the answer, one more decision changes the number: which edition.

flowchart TD
  A[TKGI estate, October 2027 clock] --> B{Keeping the VMware stack}
  B -->|Yes, VCF 9 path| C[TKGI to VKS, the shorter hop]
  B -->|No, or already multi vendor| D{Platform scope needed}
  D -->|Kubernetes runtime only| E[OpenShift Kubernetes Engine]
  D -->|Builds, pipelines and GitOps| F[OpenShift Container Platform]
  D -->|Plus Quay, ACS and ACM| G[OpenShift Platform Plus]
  E --> H[Same core pair maths, smaller feature set]
  F --> H
  G --> H
  C --> I[Admission and CNI rework still applies]

My verdict for a TKGI estate specifically: OpenShift Container Platform, and resist OpenShift Kubernetes Engine even though it is cheaper per core pair. TKGI gave you a bare Kubernetes runtime and you built everything above it yourself, so Kubernetes Engine looks like a natural like for like swap. That reasoning is a trap. Container Platform includes the internal image registry, OpenShift Pipelines and OpenShift GitOps, and those are precisely the pieces you will be rebuilding anyway during migration. Buying them separately or hand rolling them again costs more than the edition delta. Platform Plus is a real option if you already wanted Advanced Cluster Security, but do not let a migration be the reason you buy it. Decide on Platform Plus on its own merits, after month 12.

Field note on a subscription count that grew by 41 percent

My first business case on this estate quoted 68 core pairs. Nine weeks into phase 2 the real number was 96. That is a 41 percent miss on the single line finance had memorised, and it cost me a credibility I had to earn back over two steering meetings.

Three causes, all avoidable. First, two application teams had been running their own Prometheus and Fluentd deployments on TKGI worker nodes, and our plan was to lift them as ordinary workloads. Doing that would have put user managed observability on nodes we were counting as infrastructure, which disqualifies the included entitlement, so those nodes became compute. Second, three container images could not satisfy restricted-v2 and had to be rebuilt to run as an arbitrary user ID, and the rebuilt images turned out to need more memory headroom per replica, which pushed prod compute from 12 nodes to 14. Third, and this is the embarrassing one, we forgot the temporary migration cluster. Phase 3 needed a scratch OpenShift cluster for restore rehearsals, it lived for 11 weeks, and its compute nodes needed entitlement like anything else.

We reversed the first decision. Rather than lift those two Prometheus stacks, we moved both teams onto the OpenShift cluster monitoring stack with user workload monitoring turned on. Nine engineer days, some genuine unhappiness from one team about losing their custom scrape configs, and 24 vCPUs came straight back off the subscribed count. The other two causes we simply paid for, because there was no clever answer to either. Final steady state settled at 74 core pairs rather than 68, and the temporary cluster was a one quarter line item rather than a permanent one.

What I do now is refuse to give finance a single core pair number before assessment is finished. Quote a band instead, with the count you can defend at the bottom and that count plus 15 percent at the top, and name out loud what moves you between the two: temporary clusters, self managed observability that cannot legally live on infrastructure nodes, and image rebuilds that change your resource ratios. A band you hold beats a point estimate you miss.

Fund the double run, not the unit price

Every hour I have spent arguing about core pair pricing was less useful than the first hour I spent showing somebody the overlap chart. Unit price is a procurement conversation and procurement is good at it. Ten months of paying for two platforms, with a plateau at 1.6x and a peak at 1.8x, is a conversation only you can have, and it is the one that decides whether this programme finishes.

So build the paper in this order. Core pair count as a band, with the worksheet above attached so anybody can audit it. Eight cost lines, marked one time or recurring, with the two that actually retire clearly flagged. Overlap shape as a picture, not a sentence. Twelve month phased plan with exit conditions per phase and the October 2027 date on the last page. Then the vendor quote, last, as an input rather than the headline.

Your action for Monday: open a spreadsheet, list every TKGI worker node across every cluster with its vCPU count, and divide the total by four. That single number, plus 15 percent, is your opening position, and you can produce it before lunch. Part 5 turns that spreadsheet into a real inventory with the commands to build it, because a count you got from a wiki page is not an inventory. If you have not read why this is a migration rather than an upgrade yet, read it before you write the business case, because framing decides the budget. Full series index sits on the TKGI to OpenShift guide.

References

• Red Hat, Self managed Red Hat OpenShift subscription guide, January 2026 revision. Core pair and bare metal node definitions, control plane and infrastructure node entitlement, qualifying infrastructure workloads, and the five step sizing method.
• Red Hat OpenShift Container Platform Life Cycle Policy. Four month release cadence, Full Support and Maintenance Support phases, and Extended Update Support Additional Terms 1, 2 and 3.
• Broadcom KB 446224, Incompatibility between TKGI and VCF 9.1 or NSX 9.1. October 2027 End of Support and the removal of the legacy NSX Management Plane API that NCP requires.
• Red Hat OpenShift pricing. Public reserved instance floor of $0.076 per hour based on 4 vCPUs on a three year contract.

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts