Annual vendor maintenance typically runs 20 to 22 percent of net license fees, and dropping it for third-party support usually cuts that bill by 50 to 60 percent, which is why the decision is tempting and why the risks deserve a clear-eyed look before you act. The savings are real and well documented, but so are the exposures, and the buyers who get burned are the ones who counted the savings without pricing the risks of losing patches, upgrade rights, and audit cover all at once.
Why buyers consider dropping support
Maintenance is the most profitable line a software vendor sells, because it is near-pure margin on software that is already built, and it rises every year while the value delivered often does not. A buyer running stable, mature software that needs no new features is paying a fifth of the license cost annually for the right to patches they rarely apply and upgrades they do not want. Third-party support providers undercut this by 50 percent or more and frequently offer faster response and support for customized code the vendor will not touch. For a stable, end-of-roadmap product, the economics of dropping vendor maintenance can be compelling, which is why the question comes up most on mature ERP and database estates. The same margin dynamic is why vendors defend maintenance so aggressively, a pattern covered in our discount erosion at renewal guide.
The four real risks
Four exposures matter, and they are not equal. The table separates the real risks from the ones vendors overstate.
| Risk | Severity | Who it hits hardest |
|---|---|---|
| Loss of security patches | High | Internet-facing, regulated workloads |
| Loss of upgrade rights | Medium | Estates planning a major version move |
| Reinstatement penalty to return | High | Anyone who may go back to the vendor |
| Audit and compliance exposure | Medium | Buyers with messy entitlement records |
The loss of security patches is the exposure that should drive the decision, because an unpatched, internet-facing system in a regulated environment is a risk no support saving justifies. For an isolated, internal, stable system, the same loss is close to immaterial. The decision is therefore workload by workload, not a single estate-wide choice.
The reinstatement trap: If you drop maintenance and later want to return, most vendors charge back the fees you skipped plus a penalty, often 150 percent of the lapsed maintenance, before they will reinstate you. This back maintenance charge can erase years of third-party savings in a single payment, so the move to third-party support should be treated as difficult to reverse. Model the reinstatement cost before you leave, and only drop support on workloads you are confident you will not bring back to the vendor. The mechanics are covered in our back maintenance charges guide.
The security question, answered honestly
The vendor's strongest argument against dropping support is security: without vendor maintenance you lose access to official patches, and for a vulnerability in the core product there may be no fix you can apply. This is a genuine risk and it is the one to take seriously. Third-party providers mitigate it with virtual patching and compensating controls, which protect the application at the network and configuration layer rather than in the code, and for many workloads this is sufficient. But virtual patching is not the same as a vendor fix, and for systems exposed to the internet or subject to strict regulatory patching requirements, the gap can be unacceptable. The honest rule is to keep vendor maintenance on the workloads where an unpatched core vulnerability would be a serious incident, and drop it where compensating controls genuinely cover the exposure.
Losing the right to upgrade
Dropping maintenance also ends your right to new versions, so the version you run when you leave is the version you keep. For an estate at the end of its roadmap that is fine, because you did not want the next version anyway. For an estate that may need a major upgrade within a few years, it is a problem, because returning to the vendor to regain upgrade rights triggers the reinstatement penalty. The decision therefore depends on your version roadmap: drop support when you intend to run the current version to its end of life, keep it when a major upgrade is plausibly in your future. Mapping the roadmap honestly is part of the license management discipline in our software license management guide.
The audit and compliance angle
Leaving vendor support does not end your license obligations, and vendors sometimes respond to a maintenance cancellation with a compliance audit, on the theory that a departing customer is a likely source of a settlement. A buyer who drops support with disorganized entitlement records invites exactly this, because the audit will find the gaps. Before dropping maintenance, establish a clean effective license position so that any audit triggered by the move finds you compliant. Our vendor audit defense practice handles audits that follow a support change, and the broader exposure is covered in our back maintenance charges guide, which explains how the reinstatement penalty and the audit threat work together to keep buyers on maintenance.
How to manage the move safely
A safe move to third-party support follows a sequence. First, segment the estate and drop support only on stable, low-exposure workloads, keeping vendor maintenance where security or upgrade needs justify it. Second, model the reinstatement penalty so the irreversibility is priced in. Third, clean up entitlement records and confirm a compliant position before cancelling, so an audit triggered by the move finds nothing. Fourth, secure transition assistance and access to existing patches before the maintenance term ends, because once it lapses the vendor has no obligation to help, a point covered in our exit and transition assistance guide. Done in this order, the move captures the saving without the exposure; done as a blanket cancellation to chase the headline number, it creates the very risks the savings were supposed to justify.
Choosing and vetting a third-party provider
Not all third-party support is equal, and the provider you choose determines whether the savings come with real protection or a hidden gap. The questions that matter are concrete: what is the guaranteed response time for a severity-one issue, who actually delivers the support and what is their depth on your specific products, how do they handle security through virtual patching and compensating controls, and what indemnification do they offer if their advice causes a problem. A serious provider answers all four in writing and provides reference customers running estates like yours. A weak one sells the price and is vague on the rest. Because the move away from vendor maintenance is hard to reverse, the provider relationship has to be durable, which means vetting their financial stability and track record as carefully as their rate. The license-position discipline that supports this evaluation sits in our software license management guide.
The hybrid model most buyers should run
The decision is rarely all vendor support or all third-party, and the strongest position for most estates is a deliberate hybrid. Keep full vendor maintenance on the workloads that are internet-facing, regulated, or heading for a major upgrade, where patches and version rights are worth the premium. Move stable, internal, end-of-roadmap systems to third-party support, where the saving is real and the risk is contained. This split captures most of the available savings while keeping the vendor relationship intact where it matters, which also preserves negotiating goodwill for the contracts you still hold with that vendor. A blanket cancellation, by contrast, can sour the entire relationship and invite the audit and reinstatement pressure described above. The hybrid is harder to administer because it requires knowing exactly which workload sits in which category, but that knowledge is precisely the effective license position every well-run estate should already maintain, and the audit protection it provides is covered by our vendor audit defense practice.
A worked savings-versus-risk calculation
The decision becomes concrete once the numbers are on the page. Take an estate with $5,000,000 in net license value paying 22 percent annual maintenance, a $1,100,000 yearly bill. Moving the stable, internal two-thirds of that estate to third-party support at roughly half the rate saves about $363,000 a year, while the remaining third stays on vendor maintenance because it is internet-facing or heading for an upgrade. Against that annual saving, weigh the one-time reinstatement exposure if you ever return, which at 150 percent of lapsed fees on the moved portion could reach several hundred thousand dollars, and the cost of the compensating security controls the moved workloads now need. For an estate genuinely at the end of its roadmap, the saving compounds year after year while the reinstatement risk stays hypothetical, so the move pays for itself quickly. For an estate likely to return to the vendor within two years, the reinstatement penalty can erase the saving entirely, which is why the version-roadmap question decides the calculation as much as the headline rate does.
How to communicate the change to the vendor
How you tell the vendor you are dropping maintenance shapes how they respond, and a careless announcement can trigger the very audit you want to avoid. Frame the decision as a considered portfolio choice rather than a grievance, keep it factual, and avoid signaling that the rest of your estate is up for grabs. Confirm your compliance position is clean before the conversation, so that if an audit follows, it finds nothing. Time the notice to your contractual obligations precisely, because missing a cancellation window can lock you into another full maintenance term. And keep the door open on the products you are retaining, because the goodwill you preserve on those contracts is worth more than any satisfaction from a pointed exit. A vendor told carefully that a stable, end-of-roadmap product is moving to third-party support while the strategic products stay is far less likely to retaliate than one told the whole relationship is under review. The audit exposure this manages is handled through our vendor audit defense practice.
The buyer's takeaway
Dropping vendor support is a legitimate way to cut a large, low-value cost, but it is a workload-level decision, not an all-or-nothing one. Keep maintenance where unpatched vulnerabilities or future upgrades would hurt, drop it where compensating controls cover the risk and the version is stable, and in every case model the reinstatement penalty and clean up your compliance position before you act. The saving is real, the risks are real, and the difference between a good outcome and a costly one is the order and discipline of the move. We model and structure these decisions through our software licensing advisory practice. The right answer is rarely keep everything or drop everything; it is keep what protects you and drop what does not, decided workload by workload with the reinstatement penalty and the security exposure both priced in. Run that segmentation honestly and the maintenance line stops being a fixed cost you accept and becomes a portfolio you manage.