Broadcom Audit Third-Party Support Options

Third-party support — TPS — for enterprise software has been a recognised cost-control lever for two decades. Rimini Street built the category around Oracle and SAP. Spinnaker, US Cloud, Origina, and several others have extended it across the enterprise software landscape. The combination of Broadcom's aggressive pricing changes after the VMware acquisition and the simultaneous expansion of audit activity has driven a sharp increase in customer interest in TPS for VMware, Symantec, and CA Technologies. The interest is rational. The execution requires understanding several non-obvious mechanics. This article works through the practical considerations.

What third-party support actually delivers

TPS providers offer support services for software the customer has licensed but no longer pays the original vendor for support on. The services typically include:

• Break-fix support — incident response for production issues, often with SLAs comparable to or better than the original vendor
• Patch development — security patches, bug fixes, and compatibility updates developed by the TPS provider, distributed to the customer as independent updates
• Compatibility engineering — testing and remediation as the customer's surrounding environment evolves (new OS versions, new hardware, new compliance requirements)
• Configuration and architecture support — advisory work on the existing deployment, comparable to vendor professional services

The TPS provider does not have access to the vendor's source code (with rare licensed exceptions) and cannot deliver new feature releases. The customer remains on the version of the software they were running when they left vendor support, with TPS-developed patches applied on top.

For mature, stable software where the customer is not pursuing new features — a common state for many Symantec, CA, and even VMware deployments — TPS is a viable alternative to paying vendor support at renewed Broadcom pricing.

The TPS providers in the Broadcom space

Several providers actively market TPS for Broadcom-managed software:

Rimini Street — the category leader; offers support for VMware, Symantec, and some CA Technologies products. The largest customer base and the most established legal posture, though also the subject of long-running litigation with Oracle that has shaped how the industry operates.

Spinnaker Support — competes directly with Rimini in the same product set; positions on customer service depth and engineering tenure.

US Cloud — initially Microsoft-focused, has expanded into VMware support with a focus on enterprise customers seeking to leave Broadcom support.

Origina — focused historically on IBM software; some adjacent coverage for CA Technologies given the IBM/CA ecosystem overlap.

The market is evolving. New entrants are appearing as the Broadcom support-pricing changes drive demand. Customers evaluating TPS should run a current RFP rather than assuming the field is what it was 18 months ago.

The interaction with audit risk — the central question

The most common customer question about TPS is whether moving to a third-party provider increases audit risk. The honest answer has several layers:

Layer 1: Leaving support does not change licence entitlement. The customer's perpetual licences remain in force. The right to use the software is contractual and is not extinguished by ending support. From a strict licence-compliance perspective, a TPS customer is no more out of compliance than a customer on vendor support, provided the customer is using the software within the original licence terms.

Layer 2: Vendors target ex-support customers more frequently. This is well documented across Oracle and SAP, and emerging patterns suggest the same for Broadcom. Customers who terminate vendor support are statistically more likely to receive audit notices in the subsequent 12-24 months than customers who continue paying support. The vendor's view is that ex-support customers are higher-priority audit candidates because (a) they have demonstrated price sensitivity and (b) any finding can be used to recover lost support revenue.

Layer 3: The audit findings themselves are not different. The audit measures licence compliance — whether deployment matches entitlement. The auditor does not gain new authority because the customer is on TPS. What the auditor gains is opportunity, because audit notices follow the trigger of leaving support and the customer is now in the queue.

Layer 4: The negotiating leverage shifts. A customer on vendor support has a renewal lever — the threat of leaving support and going TPS. A customer already on TPS has a different lever — the threat of staying on TPS and resisting the vendor's offer to return. The audit settlement negotiation looks different depending on which side of the line the customer is on when the audit lands.

The net implication is that TPS is not "safe" in audit-risk terms — but the right TPS engagement, with the right preparation, can deliver material net savings even after factoring in elevated audit probability.

Pre-conditions for TPS to work

Successful TPS engagements share a set of pre-conditions:

Clean licence inventory before the transition

The customer must know what they own and where it is deployed before terminating vendor support. Inventory deficiencies that were tolerable while paying support become liabilities afterwards, because the audit-defence position depends on accurate records.

A frozen-or-managed environment

TPS works best when the customer is not aggressively expanding the deployment. Static or shrinking footprints fit TPS naturally. Rapidly expanding deployments either need vendor support (for new feature delivery) or need to plan the expansion before leaving support so the deployed state is known and TPS-compatible.

Acceptable risk on new vulnerabilities

TPS-developed security patches are credible and well-tested, but they are not vendor patches with vendor support behind them. The customer's security posture has to accept the model — that critical vulnerabilities will be addressed by the TPS provider's engineering, not by the original vendor.

A defensible exit position

If the customer ends up needing to return to vendor support — for example, because of a compatibility issue, a regulatory requirement, or an acquisition — the path back exists, but it typically involves catching up on the support fees missed plus a reinstatement premium. Plan the exit before the entry.

Product-by-product TPS viability

VMware (vSphere, vSAN, NSX, vCenter)

Core VMware infrastructure is well-suited to TPS. The product is mature, customer deployments are stable, and most customers are not in immediate need of new feature releases. TPS coverage is broad. The audit-risk uplift is real but manageable with preparation. Pricing savings versus renewed Broadcom support are typically 50-70%.

VMware Cloud Foundation (VCF)

VCF is harder. The product is rapidly evolving under Broadcom and customers genuinely benefit from new releases. The subscription bundling of VCF (which includes ongoing support) does not lend itself naturally to TPS. Customers tend to make the TPS decision at the underlying component level (vSphere, NSX, vSAN) rather than at the VCF bundle.

Symantec (Endpoint Protection, DLP, Encryption, etc.)

Symantec is a strong TPS candidate. The product set is mature; many customers have been managing it for a decade or more. Broadcom's pricing changes have been sharp, making the savings calculation favourable. TPS providers have well-developed Symantec practices. The main risk: customers who need ongoing threat intelligence updates may find TPS-developed updates a step behind vendor feeds.

CA Technologies (Automic, Clarity, API Management, Rally, etc.)

CA Technologies products are typically very good TPS candidates because most are extremely mature, customer deployments are stable, and Broadcom's pricing has been particularly aggressive on the legacy CA portfolio. TPS for Automic, Clarity, and the mainframe automation tools is a mature market.

Carbon Black

Carbon Black is harder than Symantec. The product depends heavily on threat intelligence and updated detection rules, and the TPS market is less developed. Customers running Carbon Black at scale typically retain vendor support unless they are actively migrating to an alternative.

Contractual gotchas

The "all-or-nothing" clause

Some vendor contracts include language requiring support to cover the entire entitlement, not just selected components. Customers who want to TPS a portion of their VMware estate while keeping vendor support on the remainder may find the contract prevents this without renegotiation.

Subscription vs perpetual

TPS is fundamentally a perpetual-licence model. Subscription customers do not "leave support" in the same way — terminating subscription terminates the right to use. Broadcom's push toward subscription is partly a TPS-prevention strategy. Customers who hold significant perpetual entitlements have more TPS optionality than customers who have converted fully to subscription.

The reinstatement premium

If the customer returns to vendor support after a period on TPS, vendor pricing typically includes the missed support fees plus a reinstatement premium. This premium can be material — sometimes 50-150% of the missed fees. The contractual ability to return at standard pricing is something to negotiate before leaving.

Patch IP boundary

TPS providers must be careful that patches they develop do not infringe vendor IP. The Oracle-Rimini litigation has shaped how this is done; current TPS engagements are structured to keep on the right side of the line. Customers should validate that the TPS provider's engineering model is robust.

Cost model — what TPS actually saves

Typical TPS pricing across VMware, Symantec, and CA Technologies engagements runs at 35-50% of vendor-list support pricing. For customers facing Broadcom support renewals at 200-400% of their historic level, the swing relative to "renew at Broadcom price" is dramatic — often 60-80% savings.

The savings are partially offset by:

• Audit-defence preparation costs — typically a one-time spend of $50K-$300K for a thorough baseline, depending on estate size
• Potential audit-settlement costs — risk-adjusted, often 5-15% of the saved support fees over a multi-year horizon
• Internal change costs — staff time to transition support workflows to the TPS provider, document deployments, and adjust escalation paths

Net savings, after these offsets, typically run 40-60% versus continued vendor support — substantial enough to justify the engagement for most customers with material support spend.

Decision framework

The TPS decision typically reduces to four questions:

1. Can we live without new releases for the foreseeable future? If yes, TPS is viable on this dimension. If no, vendor support is required.
2. Is our deployment well-documented and bounded? If yes, TPS audit-risk is manageable. If no, prepare the inventory first.
3. What are the savings, net of audit risk and transition cost? Quantify both sides; TPS only makes sense if the net is material.
4. What is the exit plan? If TPS doesn't work out, what does it cost to return to vendor support, and what is the contractual mechanism?

Customers who answer these clearly and document the answer can make an informed TPS decision. Customers who skip the analysis can find themselves in difficult positions either way — exposed in audit if they leave support, or paying renewed Broadcom pricing if they don't.

Frequently asked questions

Does going TPS guarantee an audit?

No — but it does increase probability. The evidence across the industry suggests ex-support customers are more frequently audited within 12-24 months of terminating support than continuing-support customers.

Can we partially TPS — keep vendor support on some products?

Sometimes. Contractual all-or-nothing language can prevent this. Where contracts allow partial coverage, it can be a useful interim step — keep vendor support on the rapidly changing components, TPS on the stable ones.

Will Broadcom refuse to sell us new licences if we TPS?

Vendors do not typically refuse new sales to TPS customers, but pricing and terms may be less favourable than for continuing-support customers. The relationship dynamic shifts.

What happens if we need a new feature that only the vendor provides?

Two options: return to vendor support (with reinstatement costs) or live without the feature. For most enterprise customers running stable production estates, the feature gap is manageable.

How does TPS handle security vulnerabilities?

The TPS provider develops independent patches based on vulnerability disclosures. The patches are credible and tested but are not vendor patches. For environments with stringent regulatory requirements around vendor-supplied patches, validate the regulatory position before transitioning.

What about cloud-hosted versions of these products?

SaaS and cloud-hosted products are not TPS-eligible in the same way. The vendor runs the service; the customer cannot independently choose to stop paying for it without losing access. TPS applies to customer-deployed perpetual-licensed software.