Third party software support is the most underused leverage in enterprise software. This report reads what enterprises actually pay when they leave vendor support, what coverage they keep, and how the credible option resets the renewal even when the customer never moves.
Third party software support is the most underused leverage in enterprise software. This report reads what enterprises actually pay when they leave vendor support, what coverage they keep, and how the credible option resets the vendor renewal even when the customer never moves.
About this report
This is a directional benchmark of third party software support outcomes for enterprise buyers. It is not a price list, and it does not endorse any individual provider. It draws on three inputs.
We report bands and directions, not precise discounts. Individual outcomes vary widely with product mix, customization depth, term length, and exit terms. Where a single number appears, treat it as the middle of a range rather than a guarantee.
Third party software support is independent maintenance and break fix support delivered by a firm other than the original software vendor. The customer keeps the license, drops vendor support, and pays the third party a lower annual fee for an agreed scope of post sale work.
The model has been an option for two decades on Oracle products and has expanded to SAP, IBM, and selected other vendors. Providers such as Rimini Street and Spinnaker Support publish service descriptions that frame the standard scope.
A mature contract covers break fix support, tax and regulatory updates, performance tuning, and a defined level of security advisory. The provider engineers fixes for issues the vendor would have triaged through standard support channels.
The provider also delivers customization support, which the vendor explicitly excludes. Heavily customized estates often see the largest operational benefit, not just the largest cost reduction, because customizations are now in scope.
New vendor releases and vendor written feature patches are excluded. The customer locks in the current release line for the term, and any future upgrade requires a return to vendor support, or a switch to a different platform.
Direct access to vendor support portals also ends. The third party becomes the front line for all post sale issues. For most stable estates this trade is invisible day to day, but it changes who answers the phone at three in the morning.
The economic gap that funds third party support comes from vendor support fees that include a heavy innovation premium. Customers on a stable release pay for a roadmap and a release stream they do not consume, while the provider charges only for the maintenance they actually deliver.
The premium has been a structural feature of enterprise software economics for decades. Vendors price support to fund their next product cycle. Third parties price support to fund the maintenance of the current one, and the difference is the savings.
The move is a project, not a switch. It runs over six to twelve weeks. The provider takes a snapshot of the current environment, builds a knowledge base, runs parallel response on a defined set of issues, and only takes over the full support workload once the customer is comfortable with the handover.
The vendor handover itself is procedural rather than dramatic. The customer gives notice on the support contract per its terms, lets the existing agreement run to its end date, and starts the new agreement from the same day. There is no support gap if the planning is honest.
The internal application team has to rewire its incident flow. Tickets that used to open in the vendor portal now open with the provider. The escalation path is shorter and the response time is usually faster, but the route through the third party's engineers is new and needs documenting.
The biggest internal change is mindset. The team stops waiting for vendor patches and starts asking for engineered fixes. Most teams adapt within a single quarter, and many report a higher quality of post sale dialogue than the vendor channel offered.
The blended planning anchor is 40 to 60 percent on the annual support bill, against the same scope of vendor coverage. That figure aligns with what mature providers publish and with what we see across our engagement file.
The number reaches the upper band on heavily customized estates and on long stable release lines, where the customer is paying a large innovation premium for software they are not changing. It compresses where the customer is on or near a major version transition.
Three factors push the savings band up. A stable release line that the customer does not intend to leave for the term. Heavy customization that the vendor charges to support but the third party considers core scope. A large installed base where the vendor support fee has compounded over many years.
The interaction matters. A customer with a stable release, heavy customization, and a long term commitment can land near the top of the 40 to 60 percent band, occasionally beyond it. A customer with the opposite profile rarely should consider the move.
Payback is usually immediate, because the third party fee replaces the vendor fee in the same budget cycle. The harder question is the multi year picture, where the value of the savings has to net against the cost of any eventual reinstatement or migration.
A three to five year horizon is the right frame. Savings compound, but so does the eventual cost of returning to vendor support. The right move is the one that wins on a multi year, not a single year, basis.
Coverage is broad on operational maintenance and narrow on forward release content. The contract covers what keeps the existing software running. It does not cover what extends it.
The difference shows up most clearly in two areas. Security and regulatory updates work, but through a different model. New vendor releases do not work at all, because the third party cannot ship vendor written code.
Coverage matrix: what a typical third party support contract includes
| Category | Vendor support | Third party support | Notes |
|---|---|---|---|
| Break fix on production issues | In scope | In scope | Often with stronger response time SLAs |
| Customization support | Out of scope | In scope | A core benefit on heavily customized estates |
| Tax, legal, and regulatory updates | In scope | In scope | Provider engineers updates without vendor patches |
| Performance tuning | Light scope | In scope | Engineering hours, not portal triage |
| Security advisory and mitigation | Vendor patches | Advisory plus mitigation | Different model, same goal |
| New vendor releases | In scope | Out of scope | Locked to current release line for term |
| Operating system and middleware changes | Vendor patches | Compatibility engineering | Workaround engineering, not vendor patches |
Providers do not ship vendor patches. They engineer compensating controls, configuration changes, and workaround code that mitigate the same vulnerabilities. The result is a different model, with the same operational outcome on mature products.
Regulatory and tax updates work in the third party model because the provider engineers the update directly from the published source, not from the vendor. This is a strong fit for stable ERP estates that need annual payroll and tax content.
When the database vendor or operating system vendor ships a change, the third party engineers compatibility for the supported application release. The customer keeps moving the rest of the stack forward without the vendor patch chain.
The limit is when the application release line itself is end of life and the supporting platform vendors withdraw their own support. At that point the customer is increasingly dependent on the third party's engineering to bridge the gap.
The most important exclusion is new vendor releases. A third party customer cannot install a future vendor major release without first reinstating vendor support. That reinstatement is rarely free and is usually material.
For customers whose strategy is to stay on a known stable release line for the next three to five years, the exclusion is invisible. For customers on the path to a vendor mandated reset, it is a hard constraint.
The strongest fits share three traits. A stable installed release line, a high vendor support premium, and a customer estate that is not on a near term vendor mandated platform change. The classic candidates sit in the Oracle and SAP on premise portfolios.
Oracle Database, Oracle E Business Suite, Oracle JD Edwards, and Oracle PeopleSoft are the most established candidates. The combination of long stable releases, heavy customization, and a high support fee has fit the third party model for years.
Oracle has actively pushed back on third party support and has litigated providers, but customers continue to move and the underlying economics remain. The Oracle stance is captured in its Lifetime Support Policy, which the buyer should read alongside any provider proposal.
SAP ECC on premise estates are the most active SAP candidates. SAP has published its support strategy with mainstream maintenance for ECC running through 2027 and extended maintenance available through 2030 at a premium.
The SAP support timeline is the central variable. A customer that intends to remain on ECC for the full extended window is a strong fit. A customer planning a move to S/4HANA in the near term should weigh third party support against the migration path, not against the current SAP fee.
Selected IBM middleware and software product lines are addressable, particularly mature DB2, WebSphere, and similar releases that customers run unchanged for long periods. Coverage depth varies by provider.
Outside Oracle, SAP, and IBM, the market is narrower. Third party providers cover some Microsoft on premise products in limited form, and Broadcom VMware now sits in an awkward category where the move is more often used as a renewal lever than as an exit.
Subscription SaaS platforms are not in scope for third party support. The vendor controls the running software and the platform, and the model assumes the customer owns the licensed binary. Workday, Salesforce, and ServiceNow renewals are managed through right sizing and contract levers, not through this report.
The financial picture is more nuanced than the year one saving suggests. A five year model captures the savings, the cost of any reinstatement, and the option value of the alternative as a renewal lever. Buyers who run this model honestly tend to commit faster.
The single largest variable is whether the customer expects to remain on the current release line for the full term. A clear five year stay turns the year one saving into a compounding outcome. A planned upgrade in year three or four converts the saving into a partial recovery against reinstatement cost.
A defensible base case for a strong fit estate looks like this. Year one saves 40 to 60 percent of the vendor support fee. Years two through five repeat that saving, with the provider fee escalating at a contractual cap below the vendor support trajectory. The compounding gap widens each year.
Across our engagement file, the cumulative five year saving on a strong fit estate typically lands between two and three times the year one figure, before any reinstatement cost. That is the planning anchor finance teams should carry into a board conversation.
The reinstatement scenario is where the analysis gets honest. The vendor will usually recover the missed maintenance for the third party period, then add a penalty of 5 to 30 percent depending on vendor, time elapsed, and the customer's standing. The combined recovery is the cost of returning.
The mitigation is to price the reinstatement worst case into the day one decision. A customer who plans to return to the vendor in year four should net the full reinstatement cost against four years of savings. Even on that conservative model, a strong fit estate usually still nets positive.
The credible option carries its own value, separate from any actual move. In the engagements where the customer never switched, the realized vendor renewal landed 4 to 8 percentage points lower than the comparable case without a credible alternative. That delta, compounded over a multi year contract, is real money.
The option value does not show up in a single year saving. It shows up in the renewal arithmetic at every cycle, which is why the costed third party proposal is worth building even when the buyer is firmly inclined to stay with the vendor.
The audit posture is the most over interpreted part of the decision. Leaving vendor support does not change the underlying license entitlements or the customer's compliance obligations. It changes who provides post sale maintenance, not what the customer is licensed to run.
Audit risk is structural and predates the support decision. A customer that is well documented and well managed remains so after a move. A customer with hidden compliance gaps carries those gaps with or without third party support.
The right sequence is to build the entitlement baseline before any support decision is made. A clean baseline, agreed across procurement, IT, and the relevant business owners, defines what is in scope under the existing license and what is not.
This baseline becomes the reference document for any future vendor audit, regardless of who is providing support. Building it early removes the most common source of post move turbulence, which is the discovery of a compliance issue after the fact.
Vendors retain audit rights under the master license agreement, and those rights survive the support decision. Vendors do typically increase post audit attention on customers who have moved to a third party, but the audit itself works the same way it always did.
The realistic frame is that the audit risk is incremental, not new. A customer who was well managed before the move will be well managed during it. The provider can help interpret entitlement data, but the customer remains the party responsible to the vendor under the original agreement.
The trade offs are not the ones the vendor account team usually leads with. The day to day support experience is rarely the issue. The strategic constraints are.
The two trade offs that matter are roadmap access and reinstatement economics. Both can be managed, but neither should be ignored. The buyer who treats third party support as a permanent decision wins. The buyer who treats it as a year by year choice loses.
A third party customer cannot install a future vendor major release without returning to vendor support. The decision is a multi year commitment to the current release line, not a year by year toggle, and the planning horizon has to match.
For products that run unchanged for a decade, this is a low cost trade. For products on an active vendor roadmap that the customer intends to follow, this is the hard constraint that excludes the move.
The third party security model relies on advisory and mitigation rather than vendor patches. For most mature on premise products this is operationally equivalent, but it is not identical. The buyer has to be comfortable with the difference.
The provider's published vulnerability process is the right thing to read in detail. A weak process is a deal breaker. A mature one removes the most common objection to the move.
Returning to vendor support is possible, but it is rarely free. Vendors typically recover the missed maintenance fees for the third party period, then add a penalty. The combined cost can erase several years of savings if the move is timed poorly.
The mitigation is to plan the reinstatement cost into the original decision. A customer who knows they will need vendor support again in year four should weight the savings against the year four reinstatement cost from day one.
The internal team changes how it works. Tickets stop flowing to the vendor portal and start flowing to the provider. The vendor account team usually escalates pressure on related contracts. Both are manageable, but neither is invisible.
The standard view is that leaving vendor support is too risky to consider seriously, that the comfort of the vendor patch chain is worth the premium, and that the option is a last resort for cost desperate buyers. We disagree as a blanket position. In the estates we have benchmarked, buyers who built a costed third party support option, whether they ultimately switched or not, won materially better terms at the next vendor renewal because the alternative was real. The buyer side move is to treat third party support as a benchmarked alternative in every major on premise vendor relationship, not as a last resort, because the credible option is what holds vendor support pricing honest.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
A vendor support fee is the price of a roadmap the customer is not consuming. Third party support is the price of the maintenance the customer is actually using. The difference is the buyer's leverage at every renewal.
It changes it materially. In our engagement file the costed third party option, used as a benchmarked alternative, lowered the realized vendor renewal in 30 to 50 percent of cases. The customer never switched, and still paid less to the vendor.
The mechanism is not a threat. The mechanism is a number. A vendor quote that lands above a credible third party cost, evidenced by a real proposal, becomes a number the vendor has to defend at the table rather than a position the customer has to accept.
The leverage only works if the third party proposal is real. A vague conversation with a provider does not produce a number a vendor account team will respect. A proper proposal, with scope, term, and price, does.
The work of getting a real proposal is also the work of understanding your own estate. The provider needs the same information the vendor uses to price its own renewal, and that information is the basis for any benchmark in either direction.
The credible option only works when the vendor knows it exists. The point is not to bluff. It is to be honest about the alternative, so the vendor prices the renewal against a buyer who can credibly walk, not one who cannot.
The most effective customers do this without drama. They state that a third party proposal exists, share the headline scope, and let the vendor decide how to respond. Theatrical tactics rarely produce a better outcome than a calm, evidenced position.
The clearest case to move is a stable estate, a high vendor support fee, no near term release dependency, and a customer leadership comfortable with a multi year commitment. The decision becomes operational, not strategic, once those four are in place.
The clearest case not to move is a planned upgrade inside the next three years. In that case the credible option still has value as a renewal lever, but the move itself rarely pays back against the eventual reinstatement.
Score them on five dimensions. Track record on the specific product line, security and regulatory update process, scope of break fix and customization coverage, exit terms back to the vendor if needed, and total cost over a three to five year term.
The cheapest provider is rarely the best choice. The provider with the strongest exit terms usually is, because the value of the move is preserved if circumstances change.
A provider's general capability is less informative than its capability on your specific products and releases. A strong Oracle Database provider is not automatically a strong PeopleSoft or JD Edwards provider. Read the references that match your release, not the marquee names.
The right question is how many customers run the same product version on the provider, what their renewal rate is, and what their reported issues look like in production. Avoid providers whose references all run a different product line.
The published vulnerability process is the document to read in detail. It should describe how the provider triages new vulnerabilities, how it engineers mitigations, what its disclosure cadence looks like, and how it handles a critical zero day in a product the vendor would normally patch.
Regulatory updates should be similarly documented. The provider should be able to show, by jurisdiction, what it has shipped over the last several payroll or tax cycles, with timing and content evidence.
Map the provider's standard scope against the issues your team actually files with the vendor today. Look for gaps. A customization heavy estate that mostly files customization tickets has different needs from a stock estate that mostly files break fix.
Response time SLAs vary by tier. The cheap tier is often slower than vendor support. The standard tier is typically faster. Match the tier to your operational reality, not to the headline price.
The strongest providers have the cleanest exits. Read the term carefully. Look at how the contract handles a return to vendor support, a switch to a different third party, and the reinstatement assistance the provider will provide if a future upgrade forces a return to the vendor.
A provider that hedges its exit terms is a provider that is asking for a multi year lock with no path back. That is not the buyer side posture, and it usually signals a provider whose unit economics depend on long lock in rather than on continuous renewal.
Compare on the same three to five year horizon as the vendor proposal. Include the provider fee, any one time onboarding cost, the reinstatement cost in a worst case scenario, and any internal change cost. The headline annual saving is the start of the analysis, not the conclusion.
The realized value of the move is decided in the contract, not in the marketing deck. A few terms move the outcome materially. The rest are noise.
The contract conversation should focus on five clauses. The term length, the price cap, the scope statement, the exit terms, and the security and regulatory commitments. Each is worth more than any headline saving.
Three to five year terms are the most common shape, with longer terms unlocking deeper discounts. The cap on annual price escalation should be a flat percentage, not tied to a moving index, because indexed caps can climb fast in inflationary cycles.
The combination of term and cap is what locks the saving. A long term with no cap defers the question. A short term with a cap revisits the question too often. The right shape is multi year with a flat percentage ceiling.
The scope statement defines what the provider actually delivers and how. A vague scope statement is the single most common source of post signature dispute, because the customer and the provider then read the same words differently.
The right scope statement names the products, the releases, the response time tiers, the security advisory model, and the regulatory update jurisdictions explicitly. Generality at signing becomes friction in operation, and the cost of clarifying it later usually exceeds the cost of writing it precisely now.
The exit clause is the most important one a buyer side advisor reads. The customer needs a clean route back to the vendor and a clean route to another third party. The provider should commit to data return, knowledge transfer, and reinstatement assistance with defined timelines.
The strongest providers offer the cleanest exits because they win on continuous renewal rather than on long lock in. A reluctance to commit to exit assistance is a structural signal about the provider's economics and should be treated as one.
Both commitments should be specific. The security clause should describe vulnerability triage, advisory cadence, and remediation timelines for critical issues. The regulatory clause should name the jurisdictions covered, the publication source the provider tracks, and the contractual remedy if a required update is late.
These two clauses are where the customer's downside risk lives. Strong language here is cheap insurance. Weak language here is a future incident waiting for a context. Read both with the same care reserved for the price escalation cap.
Some moves work and some do not, and the difference is usually visible months ahead. A handful of signals reliably flag a third party move that will land well, and the absence of those signals flags one that will struggle.
The clearest positive signal is a release line the customer intends to remain on for the full term. A team that has run the same release for five years and plans to run it for another five is the textbook fit. The decision becomes a question of price, not a question of strategy.
The clearest negative signal is a planned upgrade inside the term. A customer that expects to move to a new vendor release within three years is rarely a candidate for the move itself, although they may still benefit from a credible option as a renewal lever.
Heavily customized estates are stronger fits because the customizations are in scope for the third party and out of scope for the vendor. The provider becomes a true extension of the support team, and the operational improvement runs alongside the cost saving.
Less customized estates can still fit, but the value proposition narrows to price. The provider is simply a cheaper version of the same vendor service, and the operational picture has less upside to offer.
The team's readiness to manage the change is the most under estimated signal. A team that is already running its own incident triage and has strong vendor management discipline adapts quickly. A team that depends on the vendor for triage will struggle, regardless of how good the provider is.
The fix is to invest in the team's capability before the move, not after. A team that runs cleanly inside vendor support runs cleanly inside third party support. A team that does neither needs to fix that first, support decision aside.
Third party software support is independent maintenance from a firm other than the original software vendor. The buyer keeps the license, drops vendor support, and pays the provider a lower annual fee for break fix, regulatory updates, configuration help, and security advisory work on the existing release line.
Annual savings typically fall in the 40 to 60 percent band against the vendor support bill. Providers commonly quote 50 percent against vendor list as a planning anchor. The realized number depends on product mix, term length, and scope, and the strongest comparisons normalize for all three.
A mature contract covers break fix, tax and regulatory updates, performance tuning, configuration help, customization support, and a defined level of security advisory. It does not deliver new vendor releases or vendor written feature patches. Operating system and middleware change is covered through compatibility engineering rather than vendor patches.
It is safe for stable products not approaching a near term major version change. The control points are the provider's track record, the strength of its security advisory and mitigation process, and the coverage of regulatory updates. Risk rises sharply when the product is approaching an architectural reset.
Oracle Database, Oracle EBS, PeopleSoft, JD Edwards, SAP ECC, and selected IBM middleware are the strongest fits. These products run stable releases for long periods, carry heavy customization, and have high vendor support fees. Products on rapid release cadences or active platform resets are weaker fits.
The trade offs are access to new vendor releases, vendor written patches, and direct vendor roadmap influence. A third party customer cannot install a future vendor major release without reinstating vendor support, and reinstatement is rarely free. The decision is a multi year commitment to the current release line.
Yes. A costed third party option, used as a credible alternative, has lowered the realized vendor renewal in roughly 30 to 50 percent of the engagements we have benchmarked, even when the customer never switched. The option to leave is what holds vendor support pricing honest, and it does not have to be exercised.
Score them on five dimensions. Track record on your specific product line, security and regulatory update process, scope of break fix and customization coverage, exit terms back to the vendor, and total three to five year cost. The cheapest provider is rarely best; the one with the cleanest exit usually is.
The vendor by vendor savings bands, the coverage matrix, the reinstatement model, and the renewal clause checklist that turns the third party option into vendor side leverage even when you never switch.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement and finance leaders running the next on premise renewal cycle.
Vendors set the support fee. The market sets the floor. Buyers who carry a real third party option, used or not, pay closer to the floor every cycle.
