You run roughly 400 servers on paid Red Hat Enterprise Linux subscriptions, and finance asks whether they could all move to a free RHEL-compatible rebuild such as AlmaLinux or Rocky Linux. How do you make that call?
answer
- it is a bundle, not a product
- unbundle it in front of finance
- segment by obligation, not by opinion
- two platforms is a standing cost
- pilot, because conversion runs both ways
basics
~20 sDecide per workload, not per fleet. Segment the estate by what actually requires the vendor relationship — ISV certification, validated cryptography, an escalation path, life-extension options — keep those on RHEL, and move the rest, weighing the standing cost of operating two platforms.
solid answer
~50 sI would refuse to answer it as a single yes or no, because the subscription is not one product. It bundles an escalation path with a service level, classified errata and their timing, certifications that attach to Red Hat's own builds, ISV support statements that name the platform explicitly, fleet tooling, and options like extended life at end of major. Some of those matter to a database host under a vendor support contract and none of them matter to a CI build agent. So I segment: workloads with a certification, compliance or ISV dependency stay paid; ephemeral and internal-only capacity moves to a rebuild. Then I price the thing finance did not ask about — the standing cost of two content pipelines, two golden images and one automation codebase that must stay distribution-agnostic — and I pilot before committing, because conversion tooling exists in both directions and being wrong should stay cheap.
go deeper
Know that free RHEL-compatible rebuilds exist and run the same software, and that what a paid subscription adds is support, certification and vendor-published errata rather than different capabilities.
Be able to unbundle the subscription into escalation, errata, certification and tooling, and explain why a build agent and a certified database host arrive at opposite conclusions from the same list.
Show how you would pilot and measure — a representative workload converted for a full patch cycle, errata lag measured on your own package set, conversion tooling proving the decision stays reversible.
Own the framing with the budget holder: present a tiered saving against named obligations, subtract the ongoing dual-platform cost, and argue the residual as insurance against specified events rather than as a subscription nobody used.
## Reframe the question before answering it "Can we drop the subscriptions" treats an entitlement as a line item. It is really a bundle, and the mature move is to unbundle it in front of the person asking: - **An escalation path with a service level.** Someone contractually obliged to help at three in the morning on a kernel problem you cannot reproduce. - **Errata provenance and timing.** Fixes classified by severity, mapped to identifiers, published on a schedule the vendor owns — the raw material of most compliance reporting. - **Certifications that attach to the builds.** Validated cryptographic modules and government or industry hardening profiles are certified against Red Hat's binaries. A rebuild is compatible; it does not inherit the certificate. - **ISV support statements.** Large commercial products — databases, ERP platforms, storage and security agents — name supported platforms explicitly. Running on something else can mean the *application* vendor declines to help, which is often the more expensive loss. - **Fleet tooling and lifecycle options.** On-premises content management, advisory services, live kernel patching, extended-life options at the end of a major release. Each item is worth something different to each workload. That is the whole analysis. ## Segment the estate Sort 400 hosts into tiers by what they actually depend on: 1. **Contractually pinned.** Anything running a certified ISV product, anything inside a compliance boundary that names validated cryptography or a specific hardening baseline, anything whose failure triggers a customer-facing service level. These stay on RHEL and the conversation about them is over quickly. 2. **Production, but self-supported.** Internal services on standard components where your own team is already the escalation path in practice. Genuine candidates — ask honestly how many vendor support cases were opened for this tier in the last two years, and what the outcomes were. That number is the strongest evidence in the room, in whichever direction it points. 3. **Ephemeral and non-production.** Build agents, test environments, scratch capacity. Almost always the right place to start, because the blast radius of being wrong is a rebuilt machine. Often the population is heavily weighted toward tier three, which means most of the saving is available without touching anything that carries an obligation. ## Price the split honestly The cost finance did not ask about is the cost of running two platforms: - Two content pipelines to mirror, sign and monitor. - Two golden images, two hardening baselines, two sets of validation. - Automation that must be distribution-agnostic in perpetuity — the moment a playbook grows a branch on the distribution, the split has become a tax on every future change. - Staff attention divided across two errata streams with different publication cadences. If the tier-two population is small, a split fleet can cost more than it saves. "Move everything or move nothing" is occasionally the right recommendation, and it is a credible one only if you show the arithmetic. ## Keep the decision reversible Conversion tooling exists in both directions: Red Hat ships `convert2rhel` for bringing a compatible rebuild onto RHEL, and the rebuild projects ship their own migration scripts. In-place major-version upgrades are handled by the `leapp` tooling on RHEL, with equivalents in the rebuild ecosystem. That reversibility is what lets you pilot rather than negotiate in the abstract. A defensible pilot looks like: one representative service, converted, run for a full quarter including a patch cycle and at least one incident, with the errata lag measured rather than assumed. Bring back data on how quickly fixes for genuinely urgent vulnerabilities appeared on the rebuild compared with RHEL, because that timing is the operational risk people argue about with anecdotes. ## What to say to finance Give them a tiered number rather than one number: this much saving is available immediately at effectively no risk (tier three), this much is available with a defined risk and a stated migration cost (tier two), and this much is not available at any price without renegotiating obligations we have already made (tier one). Attach the ongoing dual-platform cost as a subtraction, not a footnote. And say the quiet part: the subscription's value is mostly insurance, so it is invisible until the quarter it is not. The right way to argue about insurance is to name the events it covers and how likely they are — not to observe that nothing bad happened last year.
- Which single factor most often forces a workload to stay on genuine RHEL?An independent software vendor's support statement. Compliance requirements can sometimes be met by other means, and internal teams can absorb their own escalation, but when a commercial product's support contract names the platform, running elsewhere risks losing support for the application rather than the operating system — which is usually the more expensive and less negotiable loss.
- How would you measure the errata risk of a rebuild instead of arguing about it?Pick a window of high-severity vulnerabilities relevant to your stack and measure the elapsed time between the fix appearing in RHEL and in the rebuild, on your own mirror, for your own package set. That produces a distribution of lag times you can put next to your patching service level, replacing a debate about reputation with a number the risk owner can accept or reject.
- If the fleet does split, what one engineering rule keeps the cost from compounding?No distribution-specific branches in automation or application packaging. The moment configuration management, build pipelines and images grow conditional logic per platform, every future change costs double and the two halves drift. Enforce a common interface — same package names, same paths, same service definitions — so a host's distribution is a deployment detail rather than a design input.
saying these in an interview costs you the question
- Answers with one fleet-wide yes or no.
- Ignores that ISV support statements name the platform explicitly.
- Assumes certifications transfer to a compatible rebuild.
- Omits the standing cost of operating two platforms.
- Treats an incident-free year as proof support has no value.