Oracle Practice
$8M saved on WebLogic support. The Avis third party support case.
Stable WebLogic releases, shrinking patch consumption, compounding support uplift. The exit math wrote itself; the execution needed six months.
Stable WebLogic releases, shrinking patch consumption, compounding support uplift. The exit math wrote itself; the execution needed six months.
Avis Car Rental moved a stable Oracle WebLogic estate to third party support, saving roughly 8 million dollars over three years, with the license position verified before the exit notice and the Java SE question answered before it could become an audit.
Avis Car Rental operates across more than one hundred and seventy countries, with reservation, fleet, and pricing platforms running on Oracle WebLogic Server alongside Oracle Database and E Business Suite financials. The WebLogic estate sat on stable, mature releases with limited demand for new vendor patches.
At renewal, Oracle quoted the Premier Support stream with an annual uplift compounding across a multi year envelope. The decision was binary: pay the uplift for patch streams the estate barely consumed, or exit to third party support.
The business case needed no spreadsheet gymnastics. Third party support for a middleware estate typically prices near half of vendor maintenance, and the exit also removes the annual uplift from the compounding base for the whole term.
Set against a stable estate consuming few patches, that produced the eight million dollar, three year figure this engagement is named for. The number is large because the estate was large; the logic transfers at any size.
The estate ran proven versions years from forced upgrades, consumed few new patches, and had no roadmap dependency on new WebLogic features. Perpetual license rights stayed intact after exit; only the vendor patch and upgrade stream lapsed.
Middleware earns its reputation as the cleanest exit category for a structural reason. An application server that has run the same workload on the same release for years asks very little of vendor support, while its maintenance bill assumes it asks for everything.
A full license position review preceded the exit notice, because support exits draw audit attention. The estate entered the switch with a verified compliance position and a documented DR counting posture.
Avis had separate history here worth one pointer: a distinct Oracle Java audit, resolved at no cost, is documented in the Avis Java advisory case study. This page stays with the WebLogic support decision.
The provider takes over break fix, custom fixes, and security workarounds, while the vendor only rights, new versions, certified patches, and My Oracle Support access, end at the boundary. Perpetual license rights belong to neither column; they are yours and unaffected. Getting these three categories straight is most of the transition design.
The recurring mistake is treating the exit as a procurement swap rather than an operating model change. The provider does not impersonate Oracle; it supports a frozen estate differently, through fixes built for your configuration instead of patches built for everyone.
Teams that internalize this before the switch design better contracts. Teams that discover it afterward file their disappointment as a support quality issue when it was a scoping issue all along.
Perpetual licenses survive the exit untouched, along with every patch and artifact lawfully downloaded while support was active. That is why the archive step below is not optional. It converts an entitlement that expires into a baseline that does not.
The freeze costs you the forward path: the estate stays on its current release, and returning to Oracle's upgrade track later carries a priced penalty. For a stable estate that cost is mostly theoretical, but it must be priced, not assumed away. The freeze is the real tradeoff in every middleware support exit.
Day to day, little changes. The provider supports the release indefinitely, including beyond Oracle's own lifetime support windows, which is precisely where vendor support was losing its value anyway. What disappears is optionality, not stability.
The discipline the freeze does demand is inventory hygiene. A frozen estate must know exactly which versions it runs and where, because the provider's fixes and the security case are both built on that record.
The screen looked for the events that could force re entry inside the term: an operating system refresh the frozen release is not certified for, a security accreditation demanding vendor patches, or an acquisition importing a different standard. None applied inside the three year horizon, and that finding, documented, is what made the exit defensible to the board.
The Java SE rights themselves do not move, because WebLogic licenses include restricted use Java SE rights for running that product, and those rights ride with the perpetual license, not with the support contract. What changes at the exit is the update stream and the audit surface. Both had to be answered before the notice went out.
Java SE remains licensed for use with WebLogic after the support exit, within the restricted use grant the product carries. Oracle's own Java SE licensing FAQ frames these product bundled rights. The boundary is the word restricted: the grant covers Java serving WebLogic, nothing beyond it.
Java patches for that restricted use arrived through the Oracle support agreement, so the exit ends them along with the WebLogic stream. The transition plan treated the JDK underneath WebLogic as part of the supported estate: archived with everything else, then covered by the provider's fixes and mitigations going forward.
A provider that quotes for WebLogic but goes quiet on the JDK beneath it has not priced the whole job. That question belongs in provider selection, not in the first incident call.
Any Java running outside the WebLogic restricted use scope was separately licensable before the exit and remains so after it, under Oracle's employee based Java SE subscription model. The exit changes the temperature, not the rule, because a support departure invites a closer look at everything adjacent.
The license position review therefore mapped where Java ran relative to the WebLogic grant before any notice was given. The wider coupling problem, and how it ambushes middleware migrations, is dissected in the hidden Java SE coupling guide.
The practical output was a one page map: which JDK installs served WebLogic, which served anything else, and what the anything else needed instead. Ten lines of clarity, and the most common middleware audit angle was closed.
The exit ran in four phases over six months: license position verification, provider selection, patch and artifact archival, then the support transition at the renewal boundary. Each phase closed with a written deliverable before the next opened, because a support exit is unforgiving of half finished steps.
Six months is a realistic floor for an estate of this scale. Compressing the calendar compresses exactly the phases, verification and archival, whose omissions surface a year later.
Vendor support versus third party support for this estate
| Dimension | Oracle support | Third party support |
|---|---|---|
| Annual cost | Full maintenance plus annual uplift | Roughly half of vendor list |
| Patches | Vendor patch stream | Custom fixes and virtual patching |
| Upgrades | Included while supported | Not included; estate stays on current versions |
| Coverage scope | Supported versions only | Including versions Oracle had desupported |
| Audit posture | Standard | Verified position before exit notice |
Before support lapsed, the team archived every entitled patch, update, and support artifact downloadable under the active agreement per Oracle support policies. After the lapse, that archive is the baseline the provider supports against.
The confirmation in writing matters as much as the download. A year later, nobody should have to reconstruct from memory what was captured, when, and under which entitlement.
Provider selection turned on evidence, not brochures. Three tests separated the field.
The independent screen for this decision, provider by provider, is maintained in the third party support provider guide.
A transition plan should define, in advance, what success looks like once the switch flips. Here it named three proofs.
Defining the proofs before the switch removes the ambiguity that otherwise surfaces in the first hard incident. It also gives the board a review checkpoint that is evidence, not sentiment.
The standard advice is that mission critical estates cannot leave vendor support. We disagree. In roughly 20 to 30 evaluations we ran in 2024 to 2025, mission critical but version stable estates were precisely the best candidates, because their patch consumption was lowest relative to maintenance cost. The estates that should stay are the ones with forced upgrades or vendor dependent roadmaps inside three years, not the ones that happen to be important. The buyer side move is to screen on version trajectory, not criticality.
Source: Redress Compliance advisory engagement file, middleware support exits 2024 and 2025.
Paying full maintenance for a patch stream you no longer consume is the most expensive insurance policy in enterprise IT.
The switch saved approximately eight million dollars over three years against the quoted Oracle support envelope, with service levels maintained on the stable estate and the compliance position verified before and after the move. The estate that left was the estate the screen said could leave, which is why the outcome held.
Just as telling is what did not happen. No compliance claim landed after the exit, because the position review had closed the questions an exit normally opens.
Screen on version stability, upgrade horizon, audit posture, and the Java boundary before any exit. The third party support decision framework formalizes the screen, and the Oracle support cost reduction guide covers the alternatives if the screen says stay.
For estates where the freeze is the sticking point, the honest comparison is not vendor support versus third party support. It is third party support versus funding the migration off the product entirely, and the answer differs by estate, not by philosophy.
For a stable middleware estate renewing onto another uplift cycle, five recommendations follow from this engagement. Together they are the difference between a support exit that compounds savings and one that compounds regret.
More outcomes in the case study library. Start with the Oracle practice or the Oracle knowledge hub.
By exiting Oracle support for a stable WebLogic estate and moving to third party support at roughly half the vendor maintenance cost, eliminating compounding annual uplifts across a three year term, after verifying the license position first.
Yes. Perpetual license rights survive a support exit. What lapses is the vendor patch, update, and upgrade stream, which third party providers replace with custom fixes and virtual patching.
Yes, within the restricted use grant. The Java SE rights for running WebLogic ride with the perpetual product license, not the support contract. What ends is the Java update stream, which the third party provider must cover.
Exit notices correlate with audit activity, which is why a full license position review precedes any exit signal in our engagements. Entering the switch with a verified position turns the audit risk into a planned event.
Version stable estates with low patch consumption and no forced upgrades inside roughly three years. Criticality is not the screen; mission critical but stable estates were among the best candidates we evaluated in 2024 to 2025.
Archive every patch, update, and artifact the agreement entitles you to download, document the license position, and time the transition to the renewal boundary so no mid term gap opens.
Oracle prices reinstatement from the last annual fee you paid, adding an uplift plus back charges for the lapsed period. In long lapses, repurchase or migration off the product can be cheaper; price all three before exiting.
The four question screen, audit preparation steps before exit notices, patch archival method, and provider SLA comparison framework.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
