Moving from Oracle’s Premier Support to an independent third-party support provider can result in significant cost savings and increased flexibility. However, it also introduces complex licensing risks and compliance challenges that CIOs and IT procurement leaders must manage.
This advisory article breaks down the key risks – from Oracle’s restrictive support policies to post-support audit tactics – and provides practical tips to mitigate them.
The goal is to help organizations safely exit support while maintaining license compliance and avoiding costly pitfalls.
Licensing Risks When Switching to Third-Party Support
When you drop Oracle Premier Support in favor of a third-party vendor, you retain the right to use your Oracle software (perpetual license) but lose Oracle’s support entitlements.
Below are the main licensing risks to plan for:
- Oracle’s “Matching Service Levels” Policy: Oracle contracts include a Matching Service Level clause that prevents partial support on a license set. In Oracle’s own words, “All licenses in any given license set must be supported under the same technical support service level… You may not support a subset of licenses within a license set; the license set must be reduced by terminating any unsupported licenses.”. In practice, this means that if you have a product family, such as Oracle Database Enterprise Edition with related options like Partitioning, you cannot drop support for just one component. It’s all or nothing for that product family. For example, you cannot decide to support 50 out of 100 database licenses; Oracle would insist that you either keep support for all 100 or terminate (give up) the support for the 50 licenses you want to be unsupported. This policy often forces customers to pay for support they don’t need with every license. Tip: Identify which licenses are grouped in the same “license set” and plan to move the entire set to third-party support to stay compliant. If you only want to drop support for part of a product set, you may need to negotiate an exception or terminate those licenses entirely; otherwise, you risk breaching the contract.
- Loss of Oracle Patches and Proprietary Updates: Terminating Oracle support cuts off access to Oracle’s proprietary patches, updates, and new releases. Oracle will no longer provide security patches, bug fixes, or version upgrades once you leave Premier Support. You must not use Oracle-issued patches dated after your support termination – doing so without an active support contract would violate Oracle’s IP rights. However, you can continue to run any patches or updates you have already applied or downloaded while you were supported. Savvy customers often archive all available Oracle patches and documentation before support lapses. Third-party support providers cannot legally distribute Oracle’s patches, but they develop their fixes and workarounds for bugs and security issues. Tip: Before your Oracle support ends, download and archive all necessary patches, updates, and knowledge base articles to which you are entitled up to that point. You can legally use those pre-existing patches in the future, and your third-party provider can help apply them or craft alternate solutions for new issues. Be aware that after switching, any new Oracle version or feature release is off-limits unless you return to Oracle support or license the new version separately.
- Termination of Support Entitlements: When you leave Oracle support, you forfeit all support services and entitlements tied to it. This includes access to Oracle’s My Oracle Support portal, technical helplines, and future product enhancements. Your Oracle licenses remain perpetual, so you can continue using the software at your current version. But you lose the right to upgrade to newer major versions or to apply new fixes from Oracle. For instance, if you were entitled to upgrade from Database 12c to 19c under support, that right ends with the termination of support. Any upgrade would require re-enrolling in support or purchasing new licenses.Additionally, Oracle’s support policies state that if you later decide to rejoin Oracle support, you will be subject to steep reinstatement fees. Oracle typically charges backdated support fees for the lapsed period, plus a 50% penalty (often 150% of your last annual fee, plus the unpaid years), to reinstate support. This is a deliberate deterrent against temporarily dropping support. Tip: Treat the move to third-party support as a long-term or permanent decision. If there’s any chance you might need to return to Oracle’s fold for an upgrade or project, factor in these reinstatement costs. It may be wiser to opt for minimal Oracle support for those specific products rather than incur Penalties.
Oracle Audits After Support Termination
One common concern is that Oracle may retaliate or increase audit scrutiny once you leave their support.
While Oracle cannot revoke your licenses simply because you left support, they can certainly audit your deployment to ensure you are not in breach of license terms.
Industry experts observe that Oracle sometimes targets former support customers for audits, hoping to find compliance gaps and recover revenue through penalties.
How Oracle Audits Work Post-Exit: Oracle’s License Management Services (LMS) or Global Licensing and Advisory Services (GLAS) teams may initiate an audit to verify you’re using the software within the limits of your license agreements. If you dropped support, Oracle reps know you’re trying to save money – they may suspect you’ve also trimmed licenses or might be using features without proper licenses.
Oracle has an incentive to find any shortfall or unauthorized usage, since that can lead to hefty back-license charges or forcing you back onto a contract. Some organizations have reported receiving audit notices soon after declining a support renewal.
For example, in the context of Unlimited License Agreements (ULAs), Oracle has explicitly threatened audits as customers attempt to exit the ULA and certify their usage.
One Oracle customer that certified out of a ULA received an aggressive letter stating that Oracle was immediately auditing them and would demand more money if any discrepancy was found – even implying the customer could owe more if they deployed “too many” or “too few” licenses in Oracle’s view, which was described as nonsense.
This illustrates Oracle’s hardball approach: when a big support stream is at stake (as with ULAs), Oracle may use the audit process to intimidate and squeeze customers into compliance or renewed agreements.
Audit Mitigation Strategies: Prepare before and after the support exit to withstand an audit. Before leaving Oracle, conduct a thorough internal license audit or hire an independent licensing expert to assess your Oracle usage against your entitlements. Identify any areas of non-compliance (e.g., deploying extra processors beyond what was purchased, using unlicensed database options or packs, or Java usage) and resolve them proactively.
The goal is to enter the third-party support phase with a clean license position, depriving Oracle of easy audit targets. After switching, continue to self-audit regularly. Track your deployments and ensure no one enables Oracle features you didn’t license.
For instance, Oracle Database options like Advanced Compression or Tuning Pack can be inadvertently activated – ensure they remain off if you are not licensed for them. Maintain careful records of your entitlements, including license contracts, ordering documents, and deployment records. If audited, you want to be able to readily demonstrate compliance.
Also, document that your move to third-party support is within your rights – Oracle’s standard license agreement does not forbid using a third-party for support as long as you don’t use Oracle’s IP beyond your license.
Many companies have successfully passed audits after moving to third-party support by being diligent with compliance. And as always, involve your legal team if Oracle initiates an audit. They can help ensure Oracle follows the contract’s audit clauses (for example, audits should be scheduled with notice and minimize business disruption).
In short, expect Oracle may “verify” your compliance when you stop paying them, but if you’ve done your homework, an audit should find nothing amiss. Oracle cannot penalize you for leaving support; they can only penalize unlicensed usage, which you will have safeguarded against.
ULA-Specific Risks (Unlimited License Agreements)
Oracle ULA customers face special considerations when moving to third-party support. An Oracle ULA is a time-bound contract that allows for the unlimited deployment of certain products, with a fixed fee that includes licenses and support.
After the ULA term, you either renew it or “certify” your deployments to obtain perpetual licenses. Both paths involve support commitments that make it complicated to switch to independent support.
Key risks include:
- Certification Timing and Audit Traps: Oracle’s interest is in having ULA customers renew rather than certify out, as certification converts their unlimited use into fixed, perpetual licenses (and often ends a lucrative support stream for Oracle). If you announce plans to exit a ULA, be prepared for Oracle to scrutinize your reported usage. Oracle may even use the audit process as leverage during ULA certification. As mentioned, Oracle has pressured customers at ULA’s end-of-term with immediate audits and claims that any variance in certification could trigger additional fees. The risk here is that if your certification is mishandled – for example, you underreport or overreport your usage – Oracle might challenge it. An under-report (certifying fewer licenses than you use) would leave you under-licensed post-ULA. At the same time, an over-report might prompt Oracle to claim you owe support on licenses you never deployed. Tip: Start preparing for ULA certification well in advance. Inventory all deployments of ULA-covered products and get a third-party audit or expert validation of the numbers. Certify at the last possible moment of your ULA term to maximize your counts (since any deployments after certification won’t be counted). Ensure Oracle acknowledges your certification in writing. Only once the certification is accepted and you have your perpetual license grants should you consider terminating Oracle support for those licenses. Proper timing and documentation will minimize Oracle’s ability to dispute your post-ULA position.
- Embedded Support Requirements in ULAs: During the ULA period, you are contractually required to keep paying Oracle’s support. Oracle aggregates your previous support contracts into a Total Support Stream for the ULA. This support fee must be maintained throughout the ULA term. Standard ULA terms state that if you stop paying support during the term, you must immediately certify, which effectively ends the ULA early. This is an embedded support obligation – you cannot drop Oracle’s support while the ULA is in effect. Therefore, switching to third-party support mid-ULA is not an option. You must first exit the ULA. Moreover, when you do certify out and get perpetual licenses, Oracle will typically offer to continue support on those licenses (often at the same total annual fee you were paying). If you decline and opt for third-party support at that point, be aware of a few things: (1) Support Fee Locks: Oracle typically calculates your post-ULA support fee based on your certification counts, often maintaining the previous total cost. If you don’t want Oracle support, you are not obligated to sign a new support contract after certification. However, Oracle may require that any future support re-enrollment for those licenses will cost the full amount, with no partial payment. (2) Staying Compliant Post-ULA: Once off support, you cannot deploy new instances of those Oracle products beyond what you certified. ULA customers sometimes mistakenly think they can continue to deploy software indefinitely, but after certification, your usage is capped at the certified quantities. If you later exceed those and Oracle audits you, it’s a compliance violation. Thus, treat those like any other licenses with a fixed count. Tip: If you’re in a ULA and considering third-party support, plan to do so only after the ULA term ends, not during. Work with Oracle (or advisors) to ensure a smooth certification that yields sufficient licenses for your future needs, since you won’t be getting more from Oracle easily afterwards. Factor in the audit risk around the ULA exit – Oracle may include special audit cooperation clauses in ULA contracts. Still, it has no right to audit the certification beyond its normal license audit rights. Knowing that, stand your ground if Oracle tries to overstep. Once certified and off support, manage those licenses diligently as a fixed pool.
- Post-ULA Support Considerations: Some ULAs involve Oracle hardware or cloud credits. Generally, for on-premises ULAs, once you’ve certified and left support, the situation is similar to that of any other customer on third-party support. One caveat: if your ULA included unlimited use of certain options or packages, after certification ,you might find you only need a subset actively. You can potentially terminate unused licenses to reduce Oracle support costs. Still, since you already left Oracle support entirely, this is moot unless you ever return to Oracle’s support on some of the products. Also, note that if you have an Unlimited Agreement followed by a separate Unlimited “Extended” agreement or another Unlimited Agreement (ULA), these can become complicated for support and compliance. Seek expert help to untangle them before making a switch.
License Compliance Strategies Before and After Switching Support
Maintaining license compliance is the cornerstone of a safe transition to third-party support. Oracle will no longer advise or monitor your license usage (except for formal audits), so your organization must take full ownership of compliance.
Here are strategies to employ:
Before Leaving Oracle Support:
- Conduct a License Review & Cleanup: Before your support termination date, thoroughly review your Oracle license deployments against what you own. This means checking installations, usage of options, processors vs. licenses, user counts, etc., for each Oracle product. Identify any gaps or excesses. For example, if you discovered that a DBA enabled Oracle Database Partitioning on a server. Still, you never licensed that option; address it now (either disable it or procure a license) while you still have a relationship with Oracle. Similarly, remove or stop using any Oracle programs you don’t have licenses for. The goal is to start third-party support with zero compliance debt. Many organizations engage an independent Oracle licensing consultant to perform an audit simulation – this can reveal non-compliance areas that Oracle’s auditors might miss. Resolve these issues (and consider certifying any ULAs, as discussed) before ending Oracle support.
- Ensure Contract Clarity: Verify that nothing in your contracts prohibits using third-party support. Oracle’s standard terms generally do not forbid it, but check if you signed any special amendments. Also, understand any ongoing obligations. For instance, if you have a ULA or a pool of term licenses, ensure that moving away from Oracle support won’t violate those terms. If in doubt, get legal advice. Additionally, document your entitlements – keep copies of all your licenses and support agreements, including proof of ownership for each license. This documentation serves as your defense in an audit and guides your third-party support provider on what you are entitled to use.
- Isolate and Plan by Product: Decide which Oracle products/environments you will move to third-party support and which (if any) you might keep with Oracle. Some companies adopt a hybrid approach initially – for example, keeping a mission-critical system on Oracle support for a bit longer (if an upgrade is planned soon) but moving less critical or older systems to third-party support now. Oracle’s Matching Service Levels policy means you usually have to move an entire product family at once, but you can stagger the move by product line. For example, you might switch Oracle E-Business Suite and Database to a third-party this year, but retain Oracle support for WebLogic if you plan to migrate it to the cloud next year. Coordinate the timing with your support renewal dates to avoid overlap fees. If your Oracle support contracts have different end dates, don’t despair – you can co-terminate or phase the transition contract by contract . Just be careful not to have licenses for a product on Oracle and on a third-party platform at the same time, as this would violate the matching policy. Plan a clean cut-over for each license set.
- Archive Knowledge and Patches: Before your access to Oracle’s support portal expires, download any critical patches, updates, and documentation that your teams may need in the future. This includes the latest patchsets, upgrade scripts, release notes, and Metalink knowledge base articles relevant to your environment. Third-party support providers often assist with this archive process, sometimes referring to it as a “knowledge transfer” or “patch archive” service. As long as you download these materials while you are still entitled to (i.e., under active support), it is generally within your rights to retain them for reference. This archive will be invaluable since your third-party provider cannot get new Oracle patches on your behalf. They will instead use these archives, plus their expertise, to address issues in the future. Tip: Also ensure you have up-to-date system documentation, configuration information, and any Oracle SR (Service Request) histories exported, so the new support team can quickly come up to speed on your environment.
After Switching to Third-Party Support:
- Maintain Vigilant License Tracking: Without Oracle’s involvement, you must self-police your Oracle deployments. Implement processes to track any changes in your Oracle environment. If you spin up a new Oracle database instance, ensure an existing license covers it. If you enable a new feature, such as RAC or Multi-tenant, verify that you have the required license. It’s wise to run Oracle’s license measurement tools (LMS scripts) periodically, even after switching to support, to check for any unintentional usage. Treat compliance as an ongoing practice, not a one-time effort. Tip: Assign an internal “Oracle license steward” or team responsible for approving and documenting any Oracle software changes.
- Limit Software Changes to Mitigate Risk: One advantage of third-party support is that you’re likely running stable, older software and avoiding disruptive upgrades. However, be mindful of changes that could introduce compliance risk. For example, applying a third-party vendor’s custom patch – ensure it doesn’t inadvertently enable a feature you don’t license. Or if you decide to consolidate servers or virtualize after leaving Oracle support, pay attention to Oracle’s licensing rules in virtual environments (Oracle has strict policies on partitioning, hard vs. soft partitioning, etc., that still apply). It’s often safest to keep your Oracle footprint as stable as possible after the switch. Major changes in deployment might warrant a fresh compliance check.
- Stay Informed on Oracle Licensing Policy: Even if you aren’t buying Oracle support, Oracle’s licensing rules can evolve (e.g., changes in cloud policy, virtualization, named user definitions, etc.). Keep an eye on Oracle’s official policy documents or consult with licensing experts annually to ensure no new rule catches you off guard. For instance, Oracle’s rules for Java licensing have changed recently; if you use Oracle Java, you should be aware of how this might affect you. Being on third-party support doesn’t shield you from Oracle’s license terms – you must comply with the versions of the contracts you have, and understand any generically applicable policies (like technical support policies if they indirectly affect you).
- Prepare for (and don’t fear) Audits: As discussed, audits may come. If you’ve maintained a strong compliance discipline, you can approach audits with confidence. Some companies even engage in an independent audit after a year to get a third-party perspective on their support. The key is to treat compliance as business as usual. Oracle software is still running your business, so honor the license terms as if you were still under audit – because effectively you always are. Also, ensure that your third-party support provider is not doing anything that could put you in legal jeopardy. Reputable providers will only use Oracle intellectual property that you, the customer, have legitimately obtained (such as patch archives from your environment). There have been cases (e.g., Oracle’s lawsuit against Rimini Street) where Oracle sued a third-party support firm for illegally downloading Oracle materials using customer credentials . You want to ensure that your provider follows all legal guidelines so that you, as the customer, are not implicated in any intellectual property infringement. Stick with providers who have a clean record and clear protocols.
Contractual Clauses and Negotiation Traps to Avoid
If you are planning an Oracle support exit, carefully review your contracts and be aware of Oracle’s tactics. Several contractual clauses and “traps” can snare the unwary, potentially negating your savings or complicating your exit.
Here’s what to watch out for:
- Matching Service Levels Clause: We’ve emphasized this, but it bears repeating as a contractual gotcha. The Matching Service Levels clause in your Oracle Support Policies means you cannot partially terminate support in a license set without terminating those licenses. A trap some fall into is attempting to drop support on unused licenses while keeping others, thinking they’ll save money. Oracle will invoke this clause and tell you that you must either pay support on all or terminate the ones you don’t support (i.e., you lose the licenses). Avoidance: If you plan to drop some licenses from support, be prepared to sign an Oracle termination letter for those licenses, which means you give up your rights to use them. If you still need those licenses in production, you effectively can’t drop their support under standard rules. One workaround is to segregate products in separate contracts ahead of time. For instance, don’t combine all your databases and middleware if you intend to discontinue support for one product line but not the other. Keep them on separate orders or CSIs so that each can be treated as a distinct license set. Oracle’s policy applies within a license set/product family, not across different products. Negotiating your contracts into well-defined product bundles can give you flexibility (e.g., treating databases separately from middleware).
- Repricing of Remaining Support: Oracle has a little-known policy of repricing your support costs if you terminate a subset of licenses on a support contract. If you drop licenses, the support fee for the remaining licenses may increase, and you will lose any volume discount. Oracle often recalculates the support price based on the list price of what’s left, which can erode the savings from dropping a few licenses. Avoidance: When planning to terminate licenses, try to do it in bulk and at renewal time, when you can negotiate. Oracle might be willing to maintain a discount if you are doing a larger consolidation, but if you reduce piecemeal, they will likely remove the discounts. This repricing won’t affect you if you fully exit Oracle support for that product (since you then pay Oracle $0), but it matters if you, for example, drop 30% of licenses and continue to pay support on 70%. Always ask Oracle how the support fee for remaining licenses will be recalculated if you terminate some – get those numbers before you decide. Sometimes the math shows you save a little unless you terminate a lot of licenses.
- Reinstatement and Back Support Penalties: As mentioned earlier, Oracle’s contracts allow them to charge hefty reinstatement fees if you let support lapse and later want to rejoin. This is not so much a trap as a stated policy, but companies sometimes don’t realize the magnitude: the typical charge is 150% of the last support fee plus all fees for the lapsed period. Oracle can also require you to purchase support for all your licenses if you want to reinstate any (again, matching the levels). Avoidance: The practical advice is simply not to count on going back to Oracle support for a short-term need without incurring a cost. If you suspect you might need Oracle’s help with an upgrade in two years, consider alternatives such as negotiating a short-term Oracle support extension now or budgeting for the penalty. Do not drop support, expecting to be able to easily resume later – Oracle holds the cards in that situation.
- Contractual Ties Between License and Support: Oracle’s standard perpetual license contract states that technical support is optional, but strongly encouraged. However, be wary of any non-standard terms you might have accepted. Sometimes, as part of a deal, Oracle might bundle things or add custom clauses. For example, some Oracle agreements (especially older ones or special programs) may bundle support with a license in a way that if you cancel one, it affects the other. Or Oracle might have given you a discount on licenses in exchange for a support commitment. One example: Oracle occasionally offers extra license grants or cloud credits if you continue to pay support for certain products. If you break that support commitment, those extras might disappear, negating your savings. Avoidance: Review your Oracle ordering documents and Terms and Conditions for any language that ties pricing or discounts to maintaining support. If you find any, adjust your plan or renegotiate those terms if possible. It’s safer to separate license purchase negotiations from support renewal negotiations so one isn’t contingent on the other.
- ULA Contract Clauses: If you’re under a ULA, the contract likely stipulates the sharing of deployment information and possibly cooperation with Oracle on certification. Oracle may attempt to assert audit-like rights during certification (as noted earlier). Also, the ULA likely has a clause requiring you to maintain the Total Support Stream. Avoidance: Follow the ULA terms exactly when exiting. Do not stop paying support until the term is over. If Oracle’s newer ULA contract includes any post-certification obligations, review it carefully with counsel – push back on any broad audit rights that exceed normal requirements. In general, negotiate ULAs carefully if you’re still in one. For instance, ensure that the certification process and exit rights are clearly defined, because a poorly negotiated ULA could make a third-party support move impossible or very costly.
- Verbal Misinformation and Pressure Tactics: A softer trap to avoid is taking Oracle representatives’ statements at face value without verifying against your contract. It has been observed that Oracle sales reps sometimes mislead customers about support policies – for example, incorrectly claiming that if you drop support for one Oracle product, you will lose support for all Oracle products. This is not true; Matching Service Levels applies within product families, not across all your Oracle licenses. Oracle may also suggest that third-party support is illegal or that you will be non-compliant by default – also not true, as long as you abide by the license terms. These tactics are meant to sow fear, uncertainty, and doubt (FUD). Avoidance: Always request any critical assertions from Oracle in writing. Often, their tune changes when asked to put it into words. Rely on the written contract, not sales talk. If something sounds fishy (“you can’t use those licenses if unsupported” or “we’ll terminate all your licenses”), double-check with legal advisors and independent experts. You’ll often find the contract doesn’t say that, and Oracle won’t put such claims in writing.
Isolating Support Scope from Licensing Scope
A key principle for mitigating risk is to decouple your support agreements from your licensing as much as possible. In Oracle dealings, support and license sales are intertwined, but you can take steps to isolate them, giving you more flexibility:
- Separate Contracts by Product or Business Unit: If possible, avoid bundling every Oracle product into a single, giant support contract. Instead, maintain separate support contracts for different product sets, such as database, middleware, applications, etc. This way, you have the option to terminate support for one set (and possibly move it to a third party) while leaving others untouched. Oracle’s matching policy won’t allow splitting within a contract, so structuring your agreements smartly ahead of time is key. For example, one CIO ensured that an acquired company’s Oracle licenses were kept on a distinct agreement from the parent company’s licenses, so they could drop the acquired environment’s support when retiring it, without affecting the parent’s Oracle support.
- Preserve Perpetual License Rights: Make sure your license entitlements are perpetual and fully paid. If you’re using any term-based licenses or subscriptions (including cloud services or Oracle SaaS), those are not owned licenses and can’t be taken to third-party support in the same way – they expire if you stop paying. Thus, the discussion of third-party support is generally for perpetual on-premises licenses. As a strategy, convert any critical term licenses to perpetual before making a support switch, if possible. This might involve buying out a term or switching to a perpetual metric. The goal is that your ability to run the software is not tied to ongoing payments. Support should only be available if you are intentionally switching to an alternative provider.
- Explicitly Delineate Support vs. License in Agreements: In any negotiation with Oracle, be conscious of language that blurs the line between licensing and support. For instance, ensure that any promises from Oracle about future usage (like the right to deploy in certain ways) are not conditional on having active support unless you can live with that. Sometimes Oracle includes features or extra benefits “only for supported customers.” If those are important, you might carve them out and accept Oracle support for that piece, or at least know the impact if you lose them. Keep license scope decisions separate from support discussions. A practical example: if negotiating a new license purchase, you could negotiate the price of the license and decide on support later, rather than letting Oracle assume you’ll attach support immediately. This separation can give you leverage; maybe you opt to put that new license on third-party support immediately if it’s a product you’re decommissioning soon. The bottom line is to treat support as an add-on service that you can replace, and ensure Oracle’s paperwork doesn’t make support a prerequisite for using the licenses you bought (aside from the matching policy constraints).
- Organizational Separation: Some companies even separate the teams managing licenses from those managing support vendors. Your procurement and licensing team handles compliance and license inventory, while another team manages the relationship with third-party support vendors. This ensures that even after leaving Oracle’s support, license governance remains a focus. It’s easy for organizations to become complacent once Oracle isn’t hovering with renewal reminders, but you should have an internal mechanism to continually monitor and govern Oracle license usage. Think of it as isolating “support scope” (day-to-day issue resolution and patching handled by the third party) from “licensing scope” (how software is deployed and counted, managed by your asset management function). Clear delineation of these responsibilities prevents confusion. For example, your third-party support provider should not be the one deciding if you can deploy software on a new server – that’s your licensing team’s call. By keeping these scopes separate, you reduce the risk of accidentally breaching licenses while the support provider is just trying to fix a problem.
Recommendations for CIOs and IT Leaders
In summary, moving to third-party support for Oracle is a viable strategy if executed with diligence.
Here are actionable recommendations to mitigate risks:
- 1. Know Your Contracts and License Position: Before initiating any support switch discussions, deep dive into your Oracle agreements and deployments. Identify contractual restrictions, such as the matching service level clause, and ensure you have a complete and accurate view of your license entitlements versus usage. Resolve any compliance issues proactively – consider a third-party license assessment to verify your position.
- 2. Align the Exit with Contract Dates and Terms: Time your move to coincide with the end dates of your support contracts to avoid extra fees. Avoid mid-term termination unless necessary, and be aware of any penalties that may apply. Plan to transition entire product sets at once to respect Oracle’s policies – don’t attempt a partial move that violates contract terms. If you have a ULA, wait until it is certified or expires before switching, and follow the ULA terms strictly.
- 3. Engage Expertise and Legal Counsel: Treat this transition as a major licensing project. Engage experienced Oracle licensing advisors or your procurement experts who have experience with this. They can help navigate Oracle’s tactics and ensure you don’t agree to unfavorable terms during negotiations. Have legal counsel review any notices to terminate support to confirm you aren’t inadvertently forfeiting rights. Also, involve your security and compliance teams to address any concerns about not receiving Oracle’s patches. Show them the plan with the third-party provider for security updates, etc., to get their buy-in.
- 4. Archive Oracle Materials and Prepare Your Team: Before support ends, download all needed Oracle patches, updates, and documentation. Verify that your IT team (and the new support provider) have everything needed to support the systems, including installation media, license keys, etc. Educate your IT staff that after the switch, they should not log new tickets with Oracle or download Oracle patches – all support will go through the new provider. Everyone must know the “rules of engagement” to avoid accidental contract breaches, such as an engineer contacting Oracle for support out of habit.
- 5. Choose a Reputable Third-Party Support Provider: Not all third-party support vendors are equal. Research the track records and methods of the providers. Steer toward providers with no history of IP litigation with Oracle (to keep you safe) and those who have solid processes for custom patching, regulatory updates, and support of customized environments. Ask for client references in your industry. The provider should ensure compliance with Oracle’s licensing (many will explicitly state that they use customer-provided patches only, etc.). A good provider will also assist with knowledge transfer and offer guidance on best practices in the transition.
- 6. Implement Strong Internal Governance Post-Switch: After leaving Oracle’s support, institute a governance model for Oracle license use. Track deployments and usage diligently, perhaps more frequently than you did before. Schedule periodic internal audits. Keep a close eye on things like virtualization and cloud deployments of Oracle tech – these can introduce compliance challenges. Ensure that any new Oracle purchases, if made in the future, are carefully evaluated. Some organizations ban new Oracle software acquisitions unless necessary, once they have transitioned to third-party solutions, to avoid entanglement.
- 7. Be Prepared for Audit Defense: Have a plan ready for responding to audits. This includes documentation of your licenses, records of usage, and the results of any internal audits you have conducted. If Oracle announces an audit, engage experts immediately to help (if you’re not already working with some). Since you won’t have an active Oracle support relationship, any audit is purely a compliance check – approach it professionally and stick to the contractual scope of the audit. Do not volunteer information beyond what is required, and insist that Oracle honors the contractual audit process. Demonstrating that you are well-prepared and knowledgeable often discourages Oracle from aggressive tactics.
- 8. Keep Support and Licensing Separate in Mind and Practice: Remember that you’ve essentially split the role Oracle used to play into two: Oracle still defines your license rights, but a third party provides support services. As long as you respect Oracle’s license boundaries, you are entitled to have anyone you choose support your systems. Remind stakeholders (especially IT ops and finance) that different parties now handle licensing and support. This clarity will help everyone make decisions that don’t inadvertently breach either one. For example, if considering an upgrade to a new Oracle version, that’s not just a support question (since your third-party vendor might support the old version only) but a licensing question (the new version might require Oracle support or new licenses). Always evaluate both angles.
By following these recommendations and fostering close cooperation among your licensing, legal, and IT teams, you can confidently leverage third-party support to cut costs while staying compliant with Oracle’s requirements.
Many enterprises have successfully executed this strategy, achieving 50 %+ support cost savings and improved service, but they did so with meticulous planning and oversight. With careful attention to the risks outlined above, CIOs can turn third-party support into a big win for the organization’s budget and maintain peace of mind regarding Oracle licensing.
