Buyer-side and seller side, distinguished.

A buyer-side advisor is compensated by the buyer, and only by the buyer. The advisor's revenue does not depend on any product the vendor sells. The advisor cannot earn a referral fee, a margin, a kickback, a marketing development fund, or a partner co sell incentive from any vendor whose product is on the buyer's table. The independence is structural rather than rhetorical. This is the posture the practice operates under.1

A seller side advisor is compensated, in part or in whole, through structures that depend on a vendor's product moving. The dependency may be explicit (a reseller margin earned on every order processed), implicit (a partner status that requires a minimum vendor quota each year), or strategic (a consulting practice whose pipeline depends on referrals from the vendor's field organisation). In each case the advisor's economic interest is partially aligned with the vendor's, and the alignment becomes a structural conflict at any moment in the engagement when the buyer's interest diverges from the vendor's.

The two postures are not equally common in the Red Hat advisory market. Most firms that advise on Red Hat purchases sit on the seller side, often because the firm is a Red Hat reseller, holds a Red Hat partner tier, or maintains a system integrator delivery practice that the Red Hat field refers business to. Buyer-side firms exist in smaller numbers, by design. The economic model is harder to operate at scale because the firm cannot supplement client fees with vendor revenue.

On the buyer side, the firm's only client is the buyer. The firm's only revenue mechanic is the fee the buyer pays. The firm has no commercial relationship with Red Hat that produces revenue, holds no partner status that requires minimum vendor quota, sells no software, processes no purchase orders, and signs no marketing agreement with the vendor. The firm cannot be referred work by the Red Hat field, because there is no commercial relationship in which a referral could be reciprocated.

On the seller side, the firm sits in one of several common postures. The reseller earns a margin on every Red Hat order it processes; the firm's revenue line item for Red Hat sits next to the firm's revenue line item for the buyer's advisory work, and both run through the same income statement. The partner maintains a partner tier in exchange for an annual revenue commitment to the vendor; the tier carries marketing development funds, training discounts, and pipeline referral rights, all of which depend on the partner remaining in good standing with the vendor. The system integrator maintains a delivery practice on Red Hat product and is referred work by Red Hat field representatives in exchange for product attached to the integrator's delivery engagements. The boutique consultancy earns no margin directly but depends on Red Hat field referrals to fill its pipeline, which is the strategic form of the same dependency.

Each of these postures creates a structural interest in the vendor's product continuing to move. The advisor is not always conscious of the interest, and the interest does not always surface in the day to day work. It surfaces at the table when the advisor is asked to recommend a position that costs the vendor money.

The structural conflict on the seller side is not corruption. The seller side advisor is, in most cases, technically competent and personally honest. The conflict is economic. The advisor's firm has a balance sheet that depends on the vendor relationship. When the advisor is asked to recommend a position that costs the vendor money (a smaller deal, a delayed renewal, a credible migration plan, a settlement below the initial finding) the recommendation is being made against the advisor's firm's economic interest. The conflict is invisible at the introduction call and visible only when the matter reaches the table.

In practice the conflict surfaces in three predictable places. The first is the framing of the engagement. The seller side advisor is more likely to frame the Red Hat conversation as a partnership and the buyer's role as collaborative. The framing is not wrong as language; it is wrong as posture for an audit or a hard renewal. The same vocabulary the seller side advisor uses to keep the vendor relationship intact is the vocabulary that softens the buyer's negotiation position at the table.

The second is the willingness to recommend an exit. The seller side advisor whose firm derives revenue from Red Hat product cannot credibly recommend a migration to AlmaLinux, Rocky Linux, Oracle Linux, or SUSE without recommending against the firm's own revenue base. The advisor either softens the recommendation or sidesteps the question, and the buyer's exit planning work is consequently underdeveloped relative to what the buyer needs to credibly use as leverage in the renewal.

The third is the willingness to take an adversarial posture at the audit table. The advisor who needs the Red Hat field organisation to keep referring business cannot take a posture in the audit room that makes the field organisation harder to work with afterward. The buyer engaged in an audit defense needs an advisor who is willing to be difficult on the buyer's behalf. The seller side firm structurally cannot supply that posture without paying a cost in its other line of business.

Three things change in a defense or a renewal when the advisor is buyer-side only. The first is the framing. The buyer-side advisor frames the audit as an adversarial procedural exercise, because that is what it is. There is no partnership in the audit clause; the clause exists precisely because the relationship is contractual rather than collaborative. The framing produces a different opening posture, a different communication protocol, and a different appetite for taking positions that Red Hat will dislike. The buyer's general counsel and the advisor are aligned in the framing rather than working against each other.

The second is the willingness to recommend exit. The buyer-side advisor can model the migration economics to Rocky Linux, AlmaLinux, Oracle Linux, SUSE Liberty, or a mixed posture without conflict. The buyer's leverage in the renewal frequently depends on the migration plan being credible. The advisor whose firm cannot credibly model a migration without recommending against itself is the wrong advisor for that work, and the buyer's renewal leverage suffers in direct proportion to the credibility of the gap. The buyer-side practice has no such gap by construction.

The third is the willingness to settle below the initial finding. The buyer-side advisor's only reputational asset, across engagements, is the settlement number against the initial Red Hat figure. The advisor's firm is paid by the buyer, evaluated by the buyer, and re engaged by the buyer. The advisor whose firm is paid in part by Red Hat through margin, through partner status, through field referral pipeline does not have a reputational asset of this kind that is clean of the vendor relationship. The buyer who values the settlement delta values the firm that is structurally free to chase it.2

Five quick tests sort the field reliably. None of them depend on the firm's marketing claims, which are unreliable across both sides of the market.

The first is the partner status test. Ask whether the firm holds any partner tier with Red Hat or IBM. A yes is dispositive; the firm is on the seller side. A no must be verified rather than accepted, because partner status is a matter of public record on the vendor's partner directory and can be cross checked.

The second is the margin test. Ask whether the firm earns any margin, any referral fee, any kickback, or any marketing development fund from any vendor on whose product the firm advises. Any answer other than zero is dispositive. A vague answer is also dispositive; a clean buyer-side firm answers this question crisply in the negative because the question has been asked many times before.

The third is the resale test. Ask whether the firm sells, resells, or processes any software or hardware purchase order through its books. A yes is dispositive. Processing a purchase order is selling, regardless of whether the firm describes the function as a procurement convenience.

The fourth is the references test. Ask the firm to name three references where the recommendation was to migrate off Red Hat or to walk away from a Red Hat renewal. A firm that cannot name three is unlikely to take that posture on the buyer's engagement. The references are not always available for direct contact for confidentiality reasons; the firm should be able to describe the engagements in enough detail that the pattern is credible.

The fifth is the contract test. Ask to see the firm's standard engagement contract. The clause that matters is the one that prohibits the firm from accepting compensation from any vendor whose product is on the buyer's table during the engagement. If the clause is not present in writing, the protection is not present. Marketing language about independence is not a substitute for a contractual prohibition.

The Buyer-Side Desk operates exclusively on the buyer side under each of these tests. The firm holds no partner status with Red Hat or IBM. The firm earns no margin, no referral fee, no kickback, no marketing development fund from any vendor. The firm resells nothing and processes no purchase orders. The firm has recommended migration off Red Hat where the migration economics produced the better outcome, including engagements where the recommendation reduced the buyer's Red Hat spend materially. The standard engagement contract prohibits any vendor compensation during the engagement, in writing.

The posture is structural rather than rhetorical. The practice cannot accept seller side revenue because the practice's business model does not have a place for it. The independence is not a marketing claim; it is the architecture of the firm. The architecture exists because the buyer who is engaging on an audit or a renewal needs an advisor whose only economic interest in the room is the buyer's outcome.

The companion brief on the six services sets out how the practice's engagements are structured. The brief on audit, review, true up sets out which procedural surface the work routes through. The brief on the Red Hat enterprise agreement sets out the structural reading of the document the buyer will sign at the end of the renewal.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.