Oracle Third-Party Support: A Strategic Playbook for IT Leaders

Introduction: Third-party support for Oracle software refers to maintenance and support services provided by an independent provider, rather than Oracle’s support organization.

In practice, companies with valid Oracle licenses can choose to pay a firm like Rimini Street or Spinnaker Support to handle their Oracle product support needs, covering issue resolution, bug fixes, and guidance, without an active support contract with Oracle​.

These third-party providers cannot ship Oracle’s proprietary patches or new version upgrades, but they offer workarounds, custom fixes, and dedicated assistance to keep existing systems running smoothly.

In recent years, this alternative support model has gained significant traction as a legal and viable option, driven by organizations seeking relief from high vendor maintenance fees and looking for more flexible support solutions. Gartner research noted that third-party support deals accounted for 45% of all enterprise software support contracts in 2021 – a significant increase from 27% the previous year​.

Third-party support now serves all major Oracle product categories – from enterprise applications such as E-Business Suite, PeopleSoft, JD Edwards, and Siebel, to Oracle Database and middleware platforms.

For IT leaders, considering third-party support is a strategic decision that can yield substantial cost savings and service benefits, but it also comes with trade-offs and risks that must be managed.

This playbook presents a procurement-oriented toolkit of key considerations, including an overview, best practices, pitfalls, and recommended actions, to help you evaluate and navigate Oracle third-party support for your environment.

Use these 13 considerations as a guide to make an informed decision and to plan a successful third-party support strategy.

Consideration 1: Build a Clear Understanding of Third-Party Support

Overview: Ensure all stakeholders grasp what Oracle third-party support entails. Unlike Oracle’s Premier Support, independent support vendors maintain your existing Oracle software without Oracle’s direct involvement.

You retain your perpetual Oracle licenses, but Oracle will no longer provide updates or help – the third-party provider takes over that role​. This means you lose access to Oracle’s support portal and official patches once you leave Oracle’s support​.

The third-party firm instead offers its services: troubleshooting issues, developing bug fixes or workarounds, supporting customizations, and in some cases, providing regulatory and tax updates for Oracle applications.

It’s important to note that using third-party support is completely legal as long as you stay within your license terms – Oracle cannot cancel a perpetual license just because you switch to a third-party support​provider. Many third-party providers even employ former Oracle engineers and maintain knowledge bases to resolve issues without Oracle’s direct input​.

Best Practices:

• Educate and Align Stakeholders: Communicate the meaning of third-party support. Emphasize that it replaces Oracle’s support, but not the software itself. Help stakeholders understand the capabilities (e.g., personalized support, support for custom code) and limitations (no new Oracle patches or upgrades) upfront.
• Verify License Status: Confirm that you have valid, perpetual Oracle licenses for all relevant products. Most Oracle enterprise licenses are perpetual. This ensures you have the legal right to use the software with independent support. Keep documentation of your entitlements handy​.
• Set Realistic Expectations: Align on the scope of third-party support. For example, know that if you encounter a new bug, the third-party provider will attempt a fix or workaround, but you won’t be downloading a patch from Oracle. Ensure your team understands this different support model (more hands-on help for current systems rather than access to Oracle’s future releases).

Pitfalls to Avoid:

• Misconceptions about Legality: A common myth is that switching to third-party support is not allowed or that Oracle will revoke your licenses. In reality, as long as you comply with your license agreement, independent support is a legitimate option that courts uphold. Avoid being swayed by FUD (fear, uncertainty, doubt) on this point.
• Assuming Feature Parity with Oracle: Don’t assume third-party support will provide the same deliverables as Oracle’s Premier Support. For instance, you will not receive new product features, version upgrades, or patches from Oracle​. Failing to recognize this can lead to confusion or unmet expectations later.
• Overlooking Exclusions: Be aware of what you might lose when leaving Oracle support, such as access to the My Oracle Support portal, certified updates, and Oracle’s knowledge articles. Ensure that this trade-off is understood and documented as an informed decision.

What IT Leaders Should Do: Champion an internal awareness campaign about third-party support. Before making any switch, hold informational sessions or workshops to explain how third-party support works in general terms.

Provide case examples of other companies (if available) that successfully use third-party support to build confidence that this is a mainstream strategy and not an unorthodox gamble. Ensuring everyone, from your CIO and CFO to your Oracle system admins, understands the model will lay the groundwork for a smoother evaluation and transition.

Consideration 2: Quantify Cost Savings and Business Value

Overview: The primary driver for moving to third-party support is typically cost savings. Oracle’s annual support fees are substantial – roughly 20–22% of the software license price every year, often with an automatic 3-4% uplift annually​.

By contrast, third-party support providers usually charge around 50% of Oracle’s fees for equivalent support​. In other words, organizations can often cut their Oracle support bills in half, which can translate into millions of dollars saved for large enterprises​.

These savings are not just theoretical: Gartner and other analysts have observed that independent support can immediately reduce IT operating expenses and help meet budget reduction targets​.

Freed from Oracle’s costly support, many companies reallocate the saved funds into strategic projects, such as digital transformation, cloud initiatives, or the development of new capabilities​.

From a business standpoint, third-party support offers a way to increase the ROI of your existing Oracle investments: you continue using the software reliably while paying much less for its upkeep.

However, building a strong financial case is crucial to justify the change, as there may also be indirect costs or future considerations, such as potential fees to return to Oracle support down the line.

Best Practices:

• Calculate the 5-Year Impact: Model out the cost savings over a multi-year period. Include Oracle’s projected support fee increases versus a third-party provider’s flat or lower fees. Many organizations achieve over 50% annual savings, which, over five years, can result in a significant budget reduction. Present these numbers to leadership and finance in terms of total savings and the percentage of the IT budget that is freed.
• Identify Reinvestment Opportunities: Determine where to allocate the saved funds. Best practice is to reinvest savings into innovation – for example, funding cloud migration, new modules, or other IT initiatives that were previously constrained by budget. This demonstrates that third-party support not only cuts costs but also enables business value (through those reinvestments). Have a plan ready to use the savings for high-priority projects.
• Consider Multi-Year Contracts: Third-party vendors often allow you to lock in rates for multiple years. This can provide cost predictability and eliminate the yearly uplift that Oracle imposes​. Negotiate multi-year deals with no or minimal annual escalations. This ensures your cost remains flat or declines over time relative to staying with Oracle.

Pitfalls to Avoid:

• Ignoring “Hidden” Costs: While the direct cost savings are clear, be mindful of any costs associated with switching. For example, if you foresee needing to upgrade in the future, note that rejoining Oracle support later may incur back-support fees (we’ll cover this in the licensing section). Also consider any one-time transition costs or internal resources needed during onboarding. These are usually small relative to the savings, but they should be acknowledged in your financial analysis.
• Overemphasizing Cost at the Expense of Value: Cost is crucial, but don’t focus solely on the lowest price. An extremely cheap quote from a lesser-known vendor might come with service trade-offs. The quality of support matters (to avoid costly downtime). Ensure your cost-benefit analysis also accounts for service quality differences – a slightly higher fee may be worth it for a more reliable provider.
• Failing to Validate Assumptions: Double-check the assumptions in your business case. For instance, confirm that the third-party fee covers everything you expect. Some providers may charge extra for add-on services, such as advanced monitoring or tax updates. Ensure the scope of support in the quote is apples-to-apples with Oracle’s support so that savings are genuine.

What IT Leaders Should Do: Treat the evaluation of third-party support as both a cost-saving initiative and a strategic investment decision. Prepare a business case document that quantifies the expected savings and outlines how they will be utilized. Present this to executive stakeholders (e.g., the CFO and CIO) to build buy-in.

Make it clear that the decision will optimize spend without increasing risk by highlighting how the organization can achieve the same (or improved) support service at a much lower cost. Gaining financial approval early will pave the way for the next steps in vendor evaluation and negotiations.

Consideration 3: Evaluate Support Scope and Service Quality Differences

Overview: Switching to a third-party provider is not just a cost play – it also changes the nature of your support service. It’s essential to assess how the scope and quality of support differ from Oracle’s standard support and whether these differences are beneficial for your organization.

Notably, third-party support vendors often pride themselves on offering more personalized, responsive service compared to Oracle. Under Oracle Premier Support, customers typically navigate a ticket system with severity levels. They may receive generic guidance, such as “apply patch X” or “upgrade to the next version,” rather than hands-on fixes.

In contrast, a good third-party provider will assign named engineers or a dedicated team that becomes familiar with your environment and works directly on solving issues, including issues arising from customizations or integrations that Oracle might deem “out of scope.”​​

Additionally, third-party support will continue to fully support older product versions long after Oracle’s official end-of-support date, which is a major advantage if you run legacy systems​. However, independent support will not provide new software features or enhancements – its focus is on keeping your current systems stable and optimized.

Evaluating this support model is about ensuring the vendor can meet your needs for day-to-day issue resolution, performance tuning, and guidance, even if they don’t deliver new releases.

Best Practices:

• Assess Customization Support: If your Oracle systems, especially ERP systems like EBS, PeopleSoft, or JD Edwards, have custom code or extensive modifications, verify that the provider will support them. Oracle’s support often refuses to troubleshoot customizations beyond the standard delivered code, whereas third-party vendors usually include support for custom code as part of their offering. This can be a huge benefit – confirm the vendor has expertise in your specific custom modules or extensions.
• Review Service Level Agreements (SLAs): Examine the proposed SLAs to ensure response and resolution times are reasonable. Third-party providers commonly offer strict service-level agreements (SLAs) that may be more aggressive than Oracle’s. Oracle typically does not guarantee resolution times in standard support. Ensure the SLA aligns with your business requirements for critical incidents. For example, you might get a 30-minute response guarantee for priority 1 issues from a third-party vendor. Favor providers who can commit to measurable service quality.
• Look for Proactive and Preventive Services: High-quality third-party support may include proactive services that Oracle’s basic support doesn’t offer. This could include regular health checks, performance tuning advice, or personalized roadmaps to improve the stability of your Oracle environment. Evaluate if the vendor goes beyond reactive break-fix support to help optimize and extend the life of your system. This kind of value-add can significantly improve your IT operations.

Pitfalls to Avoid:

• Equating “No Upgrades” with “No Support”: Be careful not to confuse the lack of new Oracle versions with a lack of support. Third-party support will keep your current system running through bug fixes and workarounds; they simply won’t provide brand-new features. Some stakeholders might worry that without Oracle patches, the system will degrade. In practice, a reputable provider will address issues in other ways (and often provide support longer than Oracle would). Make sure everyone understands that “no upgrades” does not mean “no fixes.”
• Overlooking Regulatory Updates (for Applications): If you use Oracle applications in areas like HR, payroll, or finance (e.g., PeopleSoft HCM, Oracle EBS Financials), consider how tax and regulatory updates are delivered. Oracle provides these updates for supported customers. Many third-party providers also create and supply regulatory patches, such as updated tax tables and changes in legal compliance, as part of their service. Don’t assume all providers do this – verify it. A pitfall would be choosing a provider that doesn’t offer needed compliance updates for your application, leaving your business at risk.
• Ignoring the Knowledge Transfer:* When you leave Oracle support, you lose Oracle’s knowledge base access​. A pitfall is not ensuring the third-party vendor can fill that gap. The best providers have extensive internal knowledge repositories and experienced staff. If a vendor seems to lack depth in Oracle-specific knowledge or is vague about how they handle complex problems, that’s a red flag on support quality.

What IT Leaders Should Do: Perform a side-by-side comparison of Oracle vs. third-party support services for your specific products. Make a checklist of what Oracle provides (patches, updates, support hours, response times, coverage for customizations, etc.) and what the third party promises.

Identify any gaps and ask the vendor how they will address them (e.g., “How will you handle security vulnerabilities since you can’t give us Oracle’s patches?” or “Will you support our custom PL/SQL code in the Oracle EBS module?”).

Engage your application managers and DBAs in these discussions – they can provide real examples of past support issues to see how the third-party would handle them differently.

The goal is to ensure that, for your operational needs, the support experience will be equal to or better than what you get from Oracle. If the provider demonstrates they can resolve issues faster, support custom setups, and keep you compliant, then the service quality hurdle is cleared.

Consideration 4: Plan for Upgrades and Product Roadmap Impacts

Overview: One of the most significant trade-offs in moving to third-party support is the loss of access to new software releases, feature updates, and upgrade scripts from Oracle. ​

Under Oracle support, you have the right to upgrade to newer versions (for example, moving from Oracle Database 19c to 21c, or E-Business Suite 12.1 to 12.2) as part of your maintenance fees.

With a third-party support contract, you can continue using your current version indefinitely, but you won’t receive the rights to upgrade to a version released after your support lapses. In effect, organizations that rely on third-party support often adopt a strategy of “freezing” their Oracle environment at a stable version that meets all their current needs.

This is ideal for companies that have no near-term business need for new features – it avoids forced upgrades just because Oracle’s support timeline dictates so. However, IT leaders must strategically evaluate how long they can stay on the current version and what the plan is if eventually an upgrade or new functionality is required.

It’s not a permanent one-way street; some organizations stay on third-party support for several years and later choose to upgrade, which may involve resubscribing to Oracle support or licensing new versions. Thus, planning your product roadmap and aligning it with your support model is a key consideration to avoid future disruption.

Best Practices:

• Choose a Stable Baseline Version: Before leaving Oracle support, it’s wise to upgrade to the latest stable version you are entitled to (if you haven’t already). For example, if Oracle is ending support for Database 12c, you might upgrade to 19c while still under Oracle’s support, and then transition to third-party support for 19c. This way, you start your third-party support period on the newest release for which you have rights. It gives you more runway before any future upgrades are needed.
• Map Out a 3-5 Year Roadmap: Work with your business stakeholders to forecast whether any upcoming business requirements would demand an Oracle software upgrade or new Oracle products. If, say, regulatory changes or growth plans mean you’ll need a feature only available in a newer release, factor that into your decision. Ideally, commit to third-party support when you expect a relatively steady-state period for the affected systems. If a major change is on the horizon in a year (e.g., a necessary ERP modernization), you may consider delaying third-party support until after that or switching to other systems.
• Have an Exit Strategy (Re-entry Plan): While not common, you should plan for the possibility that you might need to return to Oracle’s fold in the future for a particular system, for instance, to perform a major version upgrade after several years on third-party support. Oracle’s policy typically requires you to pay any “missed” support fees plus a penalty to reinstate support​. Calculate this potential cost so it’s not a surprise. You might even negotiate upfront with Oracle for better reactivation terms, although Oracle is often firm on this. Having a budgetary and technical plan for rejoining Oracle support, if needed, ensures that choosing a third-party solution isn’t a permanent decision. Many companies never go back, but it’s wise to know you can if needed.

Pitfalls to Avoid:

• Getting Stuck on an End-of-Life Product: If your Oracle product version is already very old or nearing its absolute end of life, be cautious. While third-party vendors will support it beyond Oracle’s timeline, you need to consider if the technology itself will become obsolete or incompatible with other systems. Don’t use third-party support as an excuse to never upgrade ever – use it to delay or avoid unnecessary upgrades until there’s a genuine business case. Eventually, you may need to move to a new platform or a SaaS alternative; have awareness of that long-term possibility.
• Not Receiving Critical New Features: In rapidly evolving areas, such as Oracle cloud applications or new database security features, being out of Oracle support could mean missing out on advancements that competitors adopt. If a new Oracle feature could significantly benefit your business, the value of staying current might outweigh the savings of third-party support. A pitfall is ignoring this and later realizing you’re behind. Avoid this by staying up to date with Oracle’s product roadmap and weighing the business value of the new features you’re forgoing.
• Unplanned Urgent Upgrades: Perhaps the worst scenario is needing to upgrade urgently due to an unforeseen issue, such as an operating system (OS) incompatibility or a major regulatory change that your current version cannot support. If you’re on third-party support and such a need arises, you might have to make a rushed decision to upgrade without Oracle’s help or to pay to reinstate support under pressure. To avoid this pitfall, keep an eye on industry and technical trends that could force an upgrade. The earlier you detect a potential need, the more smoothly you can plan for it.

What IT Leaders Should Do: Align your IT roadmap with your support strategy. Convene a roadmap review for all Oracle-based systems in scope: ask application owners and enterprise architects about the longevity of the current versions and any anticipated needs for change.

Document the findings – e.g., “Our PeopleSoft 9.2 will meet needs for at least 5 years with no expected new module requirements” or “Our Oracle database can remain on 19c through 2026, after which we may consider cloud options.” Use these inputs to decide if third-party support is a good fit now, and if so, how to schedule the switch.

Communicate to your business that by choosing third-party support, you are intentionally accepting a feature freeze on those systems for a period, and that this is a conscious decision made for cost and stability benefits.

When everyone understands and agrees on this trade-off, you can proceed confidently, knowing that the lack of upgrades is accounted for in your plans.

Consideration 5: Review Licensing and Contract Implications

Overview: Before switching support, review your Oracle licensing and contracts to understand the implications of leaving Oracle’s support program. The good news is that if you have a valid, perpetual license for Oracle software, that license remains yours even if you drop Oracle’s support – Oracle cannot revoke it simply because you chose another support provider​.

However, your Oracle contracts may contain certain policies that affect how you can drop support. One such policy is Oracle’s “matching service levels” clause, which generally requires that if you maintain support on certain licenses, you must maintain it on all licenses of that product family under the same agreement​.

In practice, this means you often cannot partially drop Oracle support for only some of the licenses while keeping others on Oracle support – it’s usually an all-or-nothing for a given product or license set. You’ll need to identify which Oracle products are tied together in your agreements.

Additionally, be aware of Oracle’s rules for re-enrollment. If you want to return to Oracle support in the future, Oracle typically will require the back support fees for the lapsed period (the fees you would have paid if you had been on support the whole time) plus a reinstatement fee.

This can be a significant sum if you’ve been off support for years. Also, even off support, Oracle retains the right to audit your usage of its software. Using third-party support doesn’t shield you from license compliance – you must remain within your licensed metrics and usage limits; otherwise, Oracle can pursue penalties for unlicensed use.

In short, your licenses remain valid and legal, but you must play by Oracle’s rules in terms of usage and any contract constraints when dropping support.

Best Practices:

• Conduct a License Audit (Internally or via Experts): Before terminating Oracle support, do a thorough internal audit of your Oracle deployments to ensure you’re fully compliant with your entitlements (CPU counts, user counts, optional features enabled, etc.). If possible, engage a licensing expert or firm to review your contracts and current usage. The goal is to enter third-party support with zero compliance issues that Oracle could use in an audit. Knowing you are clean removes a major worry.
• Analyze Support Coverage Requirements: Carefully read the “matching service levels” or similar clauses in your Oracle Ordering Documents or Master Agreement​ . Determine which products must be treated as a group. For example, if you have a bundle of Oracle Database licenses under a single CSI (Customer Support Identifier), you will likely need to remove support for all of them at once. Plan your third-party support scope accordingly – you may need to include all instances of a product to stay compliant with Oracle’s policies.
• Negotiate Outstanding Contracts if Possible: If you are in the midst of any Oracle negotiations, such as renewing an Unlimited License Agreement or purchasing new licenses, consider negotiating flexibility in support as part of the deal. Sometimes, large customers can negotiate exceptions or carve-outs, though Oracle often resists. At the very least, time your move to third-party support at a point when you have no other critical Oracle negotiations ongoing, to avoid complicating those.

Pitfalls to Avoid:

• Violating the “All or None” Policy: A common mistake is trying to save money by purchasing only a subset of licenses for third-party support while keeping the rest with Oracle, without realizing that Oracle’s contract forbids such a split. This can result in Oracle refusing to support the remaining licenses or even terminating support agreements. Always adhere to the matching service level rule​– if you want a partial move (a hybrid approach), structure it by distinct products or contracts, not by splitting a single support contract.
• Forgetting About Reinstatement Costs: Some organizations leave Oracle support for a few years and then are surprised when Oracle quotes a large bill to reinstate it. This is not a punitive action; it’s just Oracle’s standard practice of charging back support plus a 150% penalty, for example​. Failing to plan for this could undermine the long-term cost savings if you do have to rejoin. Make sure decision-makers are aware of this cost so that, if you plan to upgrade later via Oracle, the savings versus cost equation is evaluated with that in mind.
• Overlooking Linked Contracts or Bundled Discounts: Check if any of your Oracle support agreements are tied to other contracts or bundled discounts. Oracle sometimes grants discounts on licenses or cloud services in exchange for maintaining support​. For instance, you might be enjoying a reduced price on an Oracle ULA or a cloud subscription because you kept certain on-premises products under support​. Dropping support could nullify those discounts and lead to higher costs elsewhere. Failing to account for this could make third-party support less attractive than it appears. Be sure to consider the bigger picture of your Oracle relationship (see Consideration 11 for Oracle’s response).

What IT Leaders Should Do: Engage your procurement and legal teams early to review all Oracle contracts and policies. If you have access to Oracle contract specialists or licensing advisors, use them.

Create a checklist of contractual considerations: e.g., “Do we have any Oracle Unlimited License Agreements or enterprise contracts affected by this? Are all products we want to switch owned outright (no cloud subscriptions involved)?

Did we sign any clauses about third-party support (unlikely, but worth confirming)?” Also, develop a clear internal policy for how you will handle Oracle communications after the switch. Typically, you will notify Oracle of support termination for specific CSI numbers. Have that correspondence drafted or reviewed by legal to ensure it’s compliant and doesn’t inadvertently forfeit anything.

By dotting the i’s and crossing the t’s on licensing, you will avoid legal entanglements and can proceed with confidence that you are within your rights to use third-party support.

Consideration 6: Mitigate Security and Compliance Risks

Overview: A major concern when leaving Oracle support is how to handle security updates and compliance requirements without Oracle’s regular patches. Under Oracle’s support, you receive frequent Critical Patch Updates (CPU) and other security fixes.

Once you switch to third-party support, those Oracle-issued patches are no longer available to you for new vulnerabilities. This introduces a risk: if a serious security flaw is discovered in your Oracle software, you must rely on your third-party provider to develop a fix or provide mitigation guidance, since you cannot download Oracle’s official patch that was released after your contract lapsed.

In security-sensitive environments, this loss of the vendor’s security pipeline is the number one risk to consider.

That said, third-party support is not inherently non-compliant – many organizations in regulated industries successfully use it. Still, they implement compensating controls and ensure their provider is capable of responding quickly to security issues. The onus is on the organization and the provider to maintain a strong security posture without Oracle’s direct involvement.

Best Practices:

• Ensure Provider’s Security Capabilities: When evaluating vendors, scrutinize their approach to security. Ask if they provide proactive security monitoring or vulnerability scanning, how they stay aware of new Oracle security bulletins, and request examples of security fixes they’ve provided to other clients. Top providers will have documented processes and, in some cases, dedicated security teams (for example, Rimini Street offers a “Security Shield” service). You want a provider that can mimic or exceed Oracle’s responsiveness to vulnerabilities, perhaps even guaranteeing a faster turnaround than Oracle’s quarterly schedule.
• Implement Compensating Controls: Augment your security posture to compensate for not getting Oracle patches. This can include stricter perimeter security (firewalls, intrusion detection tuned to Oracle-specific traffic), database activity monitoring tools, and stringent access controls to reduce risk exposure​. If a database can’t be patched immediately, ensure network segmentation and other defenses limit the threat. In essence, double down on general security best practices to protect any unpatched weaknesses until fixes are applied.
• Stay Informed of Oracle Advisories: Even without an Oracle support contract, Oracle still publishes critical vulnerability information publicly, such as CVE listings and CPU pre-announcements. Assign someone (or ask your provider) to keep tabs on Oracle’s security announcements. When a new vulnerability in, say, WebLogic or Oracle DB is disclosed, proactively engage your third-party provider to understand if you’re affected and what mitigation steps to take. This way, you’re not “in the dark” on emerging risks – you remain as informed as an Oracle customer would be.

Pitfalls to Avoid:

• Falling Behind on Patches: It can be easy to deprioritize patching when Oracle stops pushing patches to you. Avoid complacency. A pitfall is assuming that your third-party provider will handle everything; you still need to maintain internal security vigilance. Do not let your Oracle systems go unpatched for long periods – insist on timely fixes or documented mitigations from your provider for all critical vulnerabilities​If a provider seems unable to address a security issue promptly, that’s a serious problem.
• Compliance Blind Spots: If you operate in a regulated industry (such as finance, healthcare, or government), be prepared to justify third-party support decisions to auditors or risk committees. A mistake would be switching without informing your internal compliance and audit teams. They might be concerned that, without vendor support, you are non-compliant with the policies. To avoid this, get buy-in from risk management and document how you will maintain compliance. For example, you might document that “we will apply all security fixes via our third-party provider or implement compensating controls within 30 days of any vulnerability disclosure” to satisfy audit requirements.
• Provider Legal/Compliance Issues: Ensure the provider’s methods for delivering support are themselves compliant and legal (to avoid any service disruption). For instance, in the past, some providers, such as in the early Rimini Street case, were found to have improperly downloaded Oracle materials, resulting in injunctions. Modern, reputable vendors follow strict IP compliance, but you should verify that the provider is not involved in any active litigation with Oracle over support practices. Choosing a provider with ongoing legal troubles could risk the continuity of your support if a court were to restrict their operations. Do your due diligence on the provider’s compliance history (ask directly, and check the news).

What IT Leaders Should Do: Engage your CISO (Chief Information Security Officer) and security team in the evaluation process. Make sure they vet the third-party provider’s security offerings and are comfortable that risks can be managed. Develop a security plan that covers how vulnerabilities will be addressed.

For instance, set up a process where any Oracle-related CVE is immediately reviewed by your security team and a ticket is opened with the support vendor to obtain a patch, fix, or detailed mitigation guidance. Also, update your disaster recovery and business continuity plans to reflect that you rely on a third party for support. Ensure you have contacts and procedures in place in case of a major security incident.

By proactively managing security and compliance in this way, you can confidently assert that moving off Oracle support will not compromise your enterprise’s risk posture. Many companies even find that with the right provider, their security improves, because the third-party can offer more hands-on help in applying fixes than Oracle’s generic support​.

Consideration 7: Identify Ideal Candidates and Scenarios for Third-Party Support

Overview: Not every Oracle system is an equal candidate for third-party support. A strategic assessment is needed to identify which applications or environments make the most sense to switch to, and when.

Typical scenarios where third-party support is most advantageous include: systems that are stable and mature (i.e., you’re not expecting to implement major changes or upgrades), products nearing or past Oracle’s official support horizon, and situations where the cost of Oracle support outweighs the benefits received.

For example, a company running a heavily customized Oracle E-Business Suite 12.1 that is stable and meeting business needs might question the value of paying Oracle’s high fees, especially if Oracle is pressuring an upgrade to 12.2 that the company doesn’t want. By switching that system to third-party support, the company can save money and avoid an unnecessary upgrade.

Similarly, organizations often move older PeopleSoft or JD Edwards instances, or Oracle databases with no performance issues, off Oracle support to cut costs while keeping them operational. On the other hand, systems that are highly strategic or require constant innovation (e.g., a cutting-edge Oracle Cloud service or an Oracle database underpinning a rapidly evolving analytics platform) may be better kept on Oracle support if you need the latest patches or very close alignment with Oracle’s roadmap.

Some enterprises choose a hybrid approach – using third-party support for certain systems, such as legacy ERPs, and Oracle support for others, like mission-critical databases. However, remember that contract constraints require all licenses of a product family to be treated as a whole. The key is to evaluate each system’s context: its lifecycle stage, future roadmap, and the risk and reward of switching its support.

Best Practices:

• Inventory and Categorize Systems: Create an inventory of your Oracle-based systems, including applications, databases, and middleware. For each, note its current version, the last significant upgrade, any customizations, and its criticality to the business. Categorize them, for example: “Legacy/Stable” vs “Strategic/Evolving.” Legacy stable systems, such as an old JDE or a content Oracle DB that just works, are prime candidates for third-party support. Strategic ones, like an Oracle BI system that business analysts constantly want new features for, might be out of scope for now.
• Target high-ROI candidates: Prioritize candidates where support costs are high and the functional benefit from Oracle support is low. If you’re paying 22% of a large license cost but not using Oracle’s help much (maybe the system rarely has issues, or Oracle hasn’t released an update you care about in years), that’s a high ROI switch. In contrast, if Oracle is about to release a critical update (say, a required tax update for your HR system next quarter), you might postpone switching that particular system.
• Consider Timing with Oracle’s schedule: review Oracle’s support lifecycle for your products. Suppose Oracle’s Premier Support is ending, and they are moving you to expensive Extended Support. In that case, that’s often a good time to switch to a third-party option (to avoid Oracle’s hefty extended fees). Likewise, if you’re just a year away from decommissioning a system entirely, you might simply stay on Oracle support until retirement to avoid the transition effort for a short span. Choose timing that maximizes benefit – e.g., right after you’ve gotten the last Oracle patch you need, or when a contract period ends.

Pitfalls to Avoid:

• All-or-Nothing Thinking: Don’t assume you must move everything off Oracle support to pursue third-party. It’s not uncommon to start with one or two systems as a pilot or partial adoption. Some organizations maintain a hybrid model: they keep Oracle support for very strategic products (or ones still under development) and use third-party support for others​. The pitfall is failing to consider this nuanced approach. Conversely, also avoid leaving a few straggling licenses on Oracle support due to oversight – remember the matching service level rules; plan intentionally if some products will remain with Oracle.
• Neglecting Stakeholder Input: Each system likely has business owners or key users who should be consulted. Suppose you switch the support model for an application without the business owner’s knowledge. In that case, you may encounter resistance or confusion when they can’t get Oracle on the phone for an issue. Avoid this by involving stakeholders in the decision for each system. Often, when they hear about cost savings and that they’ll still get support (just from a different team), they are on board, especially if their system is not in line for new features anyway.
• Switching Critical Systems Without Adequate Backup Plan: If you decide to switch a truly critical, 24×7, “can’t-go-down” system to third-party support, be extra cautious. Not that third-party can’t handle it, but you should stress-test the provider’s capabilities (maybe through a proof-of-concept support scenario). The risk is that if something catastrophic happens and the provider’s response doesn’t meet Oracle’s standards (for example, in a severe production outage). Mitigate this by ensuring that the SLA and support procedures with the provider are rock-solid for that critical system, or by initially limiting third-party support to less critical environments until confidence is built.

What IT Leaders Should Do: Perform a system-by-system suitability analysis. This can be presented as a matrix or portfolio view to your steering committee. For each Oracle system, present the current state, importance, any upcoming initiatives, the cost of support, and a recommendation (Switch to 3rd-party, Keep Oracle support, Re-evaluate in the future). Highlight the ones that are “low risk, high savings” as immediate moves.

For ones you recommend keeping with Oracle (if any), provide the rationale (e.g., “Product X is slated for replacement in 1 year, so we’ll just maintain the status quo,” or “Application Y is on Oracle SaaS, third-party support not applicable”).

This thoughtful segmentation shows that you’re making a strategic, not haphazard decision. It also sets expectations that some areas will change and others won’t, which helps manage organizational acceptance. Once consensus is reached on which systems to transition, you can proceed to engage third-party vendors for those specific areas.

Consideration 8: Survey the Vendor Landscape and Support Offerings

Overview: The third-party support market for Oracle is served by several specialized vendors. As an IT leader, you should be aware of the major players and their differences. The two largest and most prominent providers are Rimini Street and Spinnaker Support, both of which have been in this business for well over a decade and have established track records.

Rimini Street (founded 2005) is the market leader with over 3,000 clients globally as of 2024, supporting a wide array of Oracle products (databases, middleware, EBS, PeopleSoft, JD Edwards, Siebel, Hyperion, etc)​

They are known for their comprehensive service, including global tax and regulatory updates for Oracle applications, and a generally proactive support model. Spinnaker Support (founded in 2008) is another top provider with over 1,000 clients worldwide.

Spinnaker emphasizes a high-touch, personalized approach and touts a strong team of former Oracle engineers on staff​. They have notably avoided the legal disputes with Oracle that Rimini Street went through, which some customers see as a positive (less risk of disruption)​. Support Revolution is a UK-based provider that has gained popularity, especially in the EMEA region, by often offering the most competitive quotes.

They achieve lower prices through a globally distributed support model, leveraging lower-cost regions​. Support Revolution is smaller than the big two, but can be a viable option for cost-focused organizations, albeit with potential trade-offs in breadth of expertise.​

Beyond these, there are a handful of other players. For example, US Cloud (originally a Microsoft support specialist) has started offering Oracle support, and some niche firms specialize in specific Oracle products, such as one that focuses on Hyperion support. Knowing the vendor landscape will help you create a shortlist of whom to evaluate.

Best Practices:

• Research Vendor Reputation: Look for independent assessments or customer references of the vendors. Analyst reports, such as those from Gartner and Forrester, often name Rimini Street and Spinnaker as leaders. Check for case studies or testimonials in your industry – for example, public sector entities or universities often share their experiences publicly. Rimini and others have case studies, such as those from the University of Hull and the City of Flint, that demonstrate how they saved money with third-party support. A vendor’s reputation in handling Oracle products similar to yours is a strong indicator of fit.
• Compare Service Offerings: While core support (break-fix, Q&A, etc.) is standard, vendors differentiate in additional services. Rimini Street, for instance, provides global tax and regulatory updates out of the box for certain Oracle applications. Spinnaker might offer some managed services or tools, such as security monitoring, as part of the package. Support Revolution might emphasize flexibility and low cost. List out the value-added services each vendor includes or offers optionally, and see which align with your needs (you might value the tax updates or a security guarantee, for example).
• Consider Vendor Size vs. Attention: Larger providers have more resources and possibly more comprehensive coverage, as well as a larger client community, whereas smaller providers may offer more personalized attention. Spinnaker often positions itself as a more boutique experience relative to Rimini​. Decide what matters to you – do you prefer a big player with extensive processes, or a smaller one that might be more flexible? Best practice is to engage in conversations with both types to gauge their responsiveness and willingness to tailor their service.

Pitfalls to Avoid:

• Basing the Choice Solely on Price: It may be tempting to go with the lowest bid, especially from a newer or smaller provider. While cost is important, remember the difference between a 50% savings and a 55% savings is minor compared to the risk of subpar support. Avoid choosing a vendor that lacks solid Oracle expertise or a proven track record, even if they are cheaper. The few extra percentage points saved could evaporate if they fail to resolve a critical issue quickly.
• Ignoring Legal History: As noted, Rimini Street had a well-publicized legal battle with Oracle over its support practices​. While that has largely been settled (with Rimini adjusting its processes under court guidance), you should still consider any ongoing legal situations. A vendor currently in litigation with Oracle might face restrictions. That said, both Rimini and Spinnaker now operate within known legal boundaries. Just ensure that whichever vendor you consider has a clean legal record.
• Not Verifying Product Coverage: Don’t assume a vendor supports all Oracle products you have. Always verify support coverage for each specific product or version. For instance, if you use a less common Oracle product, such as Oracle Retail or Oracle ATG, ask if they have experience with it. Most big vendors do, but smaller ones might not. Overlooking this could lead to gaps where you switch support and then find the provider struggling to support a niche product.

What IT Leaders Should Do: Develop a vendor shortlist (usually 2–3 vendors) based on initial research and any peer recommendations. Then, initiate a detailed evaluation process (next consideration) with those vendors.

As part of shortlisting, you may issue an RFI (Request for Information) to gather high-level info about each provider’s capabilities and experience with your particular Oracle portfolio.

Also, consider reaching out to your network – other CIOs or IT leaders – to ask about their experience if they have switched to third-party support. Often, firsthand insights can quickly tell you which vendors are strong.

The outcome of this step should be a focused list of serious contenders that you will further vet on service quality, terms, and pricing.

Consideration 9: Run a Rigorous Sourcing and Evaluation Process

Overview: Treat the selection of a third-party support provider with the same rigor as any critical IT service sourcing. This means conducting a structured RFP (Request for Proposal) or, at the very least, a formal evaluation that allows you to compare offerings side by side.

Key areas to evaluate include the provider’s service delivery model, expertise, security approach, contract terms, and price. It’s important to ask detailed questions to surface differences – many third-party support vendors sound similar at a high level, so it’s the details that matter.

A well-run RFP will ask vendors to explain how they will meet your needs, not just whether they can do so. This is your chance to see how each vendor thinks and operates. Also, involving your procurement department can help ensure you get the best commercial terms and that nothing is overlooked in the proposal comparisons.

At the end of this process, you should have a clear sense of which vendor aligns best with your organization’s priorities and risk tolerance.

Best Practices:

• Develop Comprehensive RFP Questions: Cover all crucial categories in your RFP or questionnaire. These typically include: Staffing and Expertise (e.g., “Will we have dedicated support engineers? What is their experience level?”)​; Support Processes and SLAs (e.g., “What are your guaranteed response and resolution times for critical issues?”)​; Service Scope (e.g., “Do you support customizations? Do you provide tax/regulatory updates? Will you support integrations or only core product issues?”)​; Security and Compliance (e.g., “Describe your vulnerability management process. What security certifications do you hold?”)Onboarding and Transition (“How do you handle onboarding and archiving of Oracle materials?”)​ Contractual Terms (“What is the standard term? Are there escape clauses or flexibility if our needs change?”)​ and Reputation and References (e.g., “Provide customer references, and disclose any current litigation related to your support services.”)​ By asking consistent questions, you can directly compare vendor answers.
• Include Key Stakeholders in Evaluations: Have your technical leads (DBAs, application managers) and security team review the RFP responses alongside procurement. They can spot subtleties – for example, a DBA might notice if a vendor’s proposed method for bug fixes is sound or not. Arrange vendor presentation meetings or workshops where they can present their capabilities and answer questions live. This can reveal their depth of knowledge and culture of customer service.
• Score and Rank the Vendors: Use a scoring mechanism for the RFP responses. Assign weights to different sections based on what matters most to you (e.g., Security might be 20%, Service Approach 30%, Cost 25%, etc.). Score each vendor’s answers objectively and tally the results. While scoring shouldn’t be the only factor, it provides a structured view of who leads in each area. It also helps justify the decision to stakeholders, showing, for example, that Vendor A scored highest in the categories most important to you.

Pitfalls to Avoid:

• Incomplete Due Diligence: A major pitfall is not asking enough questions or verifying claims. For instance, if a vendor says “we can support all your Oracle products,” ask how many clients they support on each of those products, and potentially provide a reference for each. If you skip reference checks or fail to probe vague answers, you might select a vendor only to discover shortcomings after you’ve switched. Do thorough due diligence now to avoid surprises.
• Over-focusing on Short-term Price: It’s common in RFPs to focus solely on pricing comparisons. While you should compare costs, don’t let a small difference drive the decision. Also consider contract flexibility – a vendor might be slightly more expensive but offer the ability to scale down support fees if you retire your systems, or offer a shorter-term commitment. Those can be valuable. The cheapest provider isn’t always the best value.
• Not Involving Oracle (for Data Points): This may sound counterintuitive, but as part of due diligence, consider informing your Oracle account manager that you are evaluating third-party support. Sometimes, Oracle might offer concessions to retain your business, which gives you insight into how much they value you and what your alternatives are. Or they might provide warnings – take these with a grain of salt, as Oracle has a vested interest, but you can later ask vendors to clarify those points. The pitfall is doing this too early or without preparation. If you reveal your hand to Oracle without a plan, you may invite increased audit attention, as mentioned earlier, or sales pressure. Only engage Oracle when you have a clear idea of your direction, and maybe after you have a preferred vendor in mind. And do so carefully (see Consideration 11).

What IT Leaders Should Do: Approach this as a formal procurement project. Set up a project team that includes IT, procurement, finance, and legal, as needed. Create a timeline for the RFP process with deadlines for responses, demos, and decisions.

Use templates or past RFPs for similar services as a starting point, customizing them to the specifics of third-party software support. Treat vendor interactions professionally and document everything, including questions asked and answers received.

As the leader, your role will be to balance input from various teams and keep the evaluation aligned with strategic goals, such as cost savings, risk management, and service quality.

After the evaluation, be prepared to make a recommendation to top management on which vendor to select and why. Having all the RFP data and scoring will make that conversation fact-based and easier to justify.

Consideration 10: Negotiate the Contract and Service Levels

Overview: Once you have chosen a provider (or are down to a final candidate), the next step is to negotiate a contract that protects your interests and ensures you get the service you expect.

Third-party support contracts can often be more flexible than Oracle’s standard agreements – vendors will compete on terms as well as price to win your business. Key aspects to negotiate include the support fee (and any multi-year discounts), the contract term length, renewal conditions, service level commitments, and liabilities.

Unlike Oracle, which generally has one-sided support terms, a third-party provider will be eager to address customer concerns in the contract because you likely represent significant business to them.

This is your opportunity to lock in not just a good price, but also favorable terms such as the ability to cancel with notice if needed, or caps on annual price increases (ideally none). Ensure the contract spells out the scope of support, including which products and types of issues are covered, to avoid any ambiguity.

Also, clarify details such as how to request support, escalation paths, and any credits or remedies if SLA targets are not met. Essentially, the negotiation should result in a support agreement that is robust, fair, and tailored to your needs, quite possibly better aligned to you than Oracle’s “one-size-fits-all” support terms.

Best Practices:

• Secure a Multi-Year Rate Lock: Opt for a multi-year contract (e.g., 3 years) with the annual fee locked in or even decreasing over time. One of the benefits of third-party support is avoiding Oracle’s yearly increases. Ensure your contract explicitly states that fees will not increase during the term, or only by a very minimal, agreed-upon amount. Vendors often will agree to fixed pricing for the term, especially if it’s a longer commitment. In exchange, you get cost predictability and additional savings over time.
• Define SLAs and Penalties: Ensure the contract includes the SLA metrics that the vendor committed to, such as response times for different severity levels. Also, negotiate what happens if they fail to meet those SLAs – for instance, service credits, the right to terminate if breaches are repeated, etc. While you hope to never use these remedies, having them in writing underscores the vendor’s accountability. It also forces clarity: for example, how do you measure response time and what constitutes resolution should be unambiguous in the contract.
• Include a “Change of Circumstances” Clause: Business needs change – perhaps you divest a business unit and no longer need support for some systems, or perhaps you end up migrating to a new platform sooner than expected. Try to include terms that allow for some flexibility, such as the ability to reduce scope (with a corresponding fee reduction) if certain systems are decommissioned, or the option to exit the contract after a minimum period with notice. Vendors may allow a degree of this because they understand customers fear being locked in if the strategy shifts. Even a partial flexibility clause is worth having.

Pitfalls to Avoid:

• Overlooking Exclusions or Assumptions: Read the contract fine print for any exclusions. For example, some vendors may exclude support for custom code unless it is explicitly listed, or assume that the customer is responsible for certain tasks, such as obtaining valid licenses or providing a test environment for replication. Make sure everything you expect is either explicitly included or at least not excluded. If a vendor says in the RFP, “We cover customizations,” ensure the contract states that clearly. Do not rely on verbal assurances – get it in the contract.
• Inadequate Liability Protections: While rare, consider worst-case scenarios: what if the provider mishandles something that causes a major outage or compliance issue? Oracle’s contracts typically have very limited liability on their side. You may not get much more from a third party, but it’s worth negotiating liability caps and insurance requirements that are appropriate for the engagement. Also consider confidentiality and IP protection clauses – ensure the vendor will protect your data and isn’t going to misuse Oracle’s intellectual property in a way that drags you into litigation. Essentially, cover your bases legally as you would with any critical IT outsource.
• Not Coordinating with Renewal Cycles: If you are phasing multiple systems over to third-party support at different times (for example, the database this year and an application next year when its Oracle support expires), try to negotiate future additions now. A pitfall is signing a contract for a subset and later adding more products separately without the same leverage. Instead, consider negotiating a master agreement that can accommodate adding other Oracle products at the same discount rate or terms when you’re ready. This way, you lock in a framework upfront. If you don’t, you might find yourself renegotiating from scratch for each addition, potentially at less favorable terms.

What IT Leaders Should Do: Work closely with your procurement and legal teams during negotiation. Use the leverage you have – the vendor knows you can still walk away at this point – to get the best overall deal.

Don’t hesitate to push back on terms that don’t align with your expectations; most providers will be amenable to reasonable edits. Communicate to the vendor any internal requirements you have (for example, “our policy is no auto-renew without a 90-day notice, so that must be in the contract”).

Also plan the timing: ideally, you want the new contract signed and ready to take effect as soon as your Oracle support lapses, to avoid any support gap. Coordinate the end date of Oracle support with the start date of the third-party contract.

Once you reach an agreement, have a formal sign-off internally. Make sure the CIO and, if needed, the CFO review the final contract. By securing a well-negotiated contract, you set the foundation for a successful partnership with the vendor, with clear expectations on both sides.

Consideration 11: Prepare for Oracle’s Response and Relationship Management

Overview: Switching to third-party support inherently changes your relationship with Oracle. You should be prepared for how Oracle might respond when they learn of your decision, and have a plan to manage that dynamic.

Remember, Oracle has a strong incentive to retain support revenue so that you may encounter tactics ranging from enticements to warnings. One common response is that Oracle’s account team might come back with an offer or discount to lure you into staying. For example, they might offer a one-time reduction in the support fee or a bundle of free cloud credits if you stay on support.

Alternatively, Oracle might emphasize the risks of leaving, implying things about legality (which we know are exaggerated) or hinting at the strict enforcement of contract terms, such as audits. It’s also possible that Oracle will elevate your situation internally, meaning your departure will be noted by account management.

While Oracle cannot directly penalize you beyond what the contracts allow, they could engage in “soft” retaliation, such as being less flexible in other ongoing negotiations or conducting an audit to scrutinize your license usage. It’s important not to be caught off guard.

By anticipating these responses, you can manage communications with Oracle professionally and maintain as cordial a relationship as possible.

After all, you likely still use Oracle software and may buy from Oracle in the future (licenses, cloud services, etc.), so you don’t want an acrimonious split.

Best Practices:

• Have a Communications Plan: Decide when and how you will inform Oracle of your move. Typically, customers notify Oracle by submitting non-renewal notices for support (per contract terms, often 30-90 days before expiration). It’s best to provide the notice in writing as required, and simultaneously inform your Oracle account manager verbally. Be clear and firm that, as of a specific date, you will no longer renew support for those licenses. Thank Oracle for past support and express willingness to continue a positive relationship in other areas. Setting a professional tone can defuse some negativity.
• Manage the Narrative: Oracle might ask why you are leaving. You can choose how much to share. Some companies cite budget pressures or lack of need for upgrades; others directly say they found a better support solution. It’s okay to be honest but diplomatic. Emphasize that this decision was carefully made and is in the best interest of the company. If Oracle dangles a discount, evaluate it fairly – occasionally, Oracle might offer something substantial. However, they often cannot achieve a 50% reduction year over year. If their counter is minor, you can politely decline. If it’s bigger, weigh it against the benefits of the third party’s service quality and flexibility, not just the cost.
• Involve Legal for Any Pushback: If Oracle representatives use aggressive tactics (e.g., explicitly threatening an audit or suggesting you are in violation), involve your legal counsel. While Oracle audits can occur, they must follow contractual audit clauses. Any harassment beyond normal audit processes is not acceptable. Having legal send a firm response that you are aware of your rights and expect Oracle to honor the agreements can help. In practice, many customers do not experience heavy-handed retaliation, but it’s wise to be ready. Document all interactions with Oracle around this decision.

Pitfalls to Avoid:

• Burning Bridges: Avoid using combative language or issuing ultimatums to Oracle. Even if sales reps get pushy, respond calmly. Don’t gloat about saving money or badmouth Oracle’s support – maintain a professional demeanor. A pitfall would be making the separation hostile, which could sour future dealings. Remember, you may need Oracle for new licenses or cloud services at some point; keeping the door open is beneficial.
• Revealing Vendor Details Prematurely: Oracle might be very curious which third-party provider you’re going with. You are not obligated to tell them. It’s often wise not to reveal the vendor’s name or the exact terms you got. Oracle has been known to try to discredit specific third-party firms by citing the Rimini lawsuit or other issues. If they don’t know, they can only speak in generalities. Keep the focus on what Oracle can control (their support offer) rather than discussing the third-party.
• Neglecting Remaining Oracle Contracts: If your organization still has other contracts with Oracle (for example, Oracle Cloud subscriptions, or support on other products you’re not switching), don’t neglect those relationships. A pitfall would be letting this support switch poison those engagements. Ensure the teams handling other Oracle dealings are aware of the change so that they can manage any cross-talk. Oracle might try to leverage another contract: “We’ll renew your database support discount only if you keep EBS on support.” Know your priorities – if you have to compromise on something to secure a critical Oracle deal, weigh the options carefully. Ideally, you would have segmented things such that this move stands on its own merits.

What IT Leaders Should Do: Coach your team on how to engage Oracle during this transition. This includes procurement, vendor management, and any IT staff who interface with Oracle. Provide them with the rationale and the messaging to use.

For example, suppose an Oracle salesperson calls an IT manager to pitch why staying is a better option. In that case, that manager should know to refer them to the central decision makers and maintain a consistent message (“We’ve decided to move to an independent support model for these products, to optimize costs and focus on stability.

We remain a customer for other Oracle products and value the partnership.” Internally, prepare an FAQ for leadership in case the news reaches higher levels at Oracle, who might escalate to your executives.

You want your execs to have talking points too (“Yes, we did this to save $X million, and it aligns with our strategy”). By managing Oracle’s response carefully, you can transition to third-party support while minimizing friction and even potentially extract some last-minute concessions.

Once the dust settles, continue to periodically engage with Oracle on positive terms (e.g., keep informed about their product roadmaps, attend their events if useful) – you’re showing that choosing independent support for some products doesn’t mean the end of the Oracle relationship.

Consideration 12: Plan and Execute a Smooth Transition to the New Support Provider

Overview: After contracts are signed and decisions made, the practical work of transitioning support from Oracle to the third-party provider begins. The goal is to ensure there is no lapse in support coverage and that your IT team is fully prepared to work with the new support model. Fortunately, transitioning is usually straightforward, but it does require coordination.

On the final day of your Oracle support contract, your access to Oracle’s support systems (like My Oracle Support portal) will be cut off, and Oracle will no longer take your support calls. From the next day onward, you’ll be calling or logging tickets with the new provider.

To be ready, you should have already completed certain tasks: for example, download any last available patches or documentation from Oracle’s portal while you still can (you won’t legally be able to after support ends)​You also want to have an onboarding session with the third-party provider so they understand your environment and you know how to engage them (contact methods, escalation paths, etc.).

A common best practice is to schedule the provider’s onboarding to start a few weeks before your Oracle support expires, so there is an overlap where they can learn your systems and, if applicable, shadow any open Oracle support issues. The transition period is also a good time to archive information, such as saving configuration data, support ticket history, and so on, to have full knowledge in-house as you make the switch.

Best Practices:

• Archive Oracle Support Materials: Before your Oracle support ends, proactively download any patches, updates, or technical documentation from Oracle that you think you might need in the future. For instance, if there are known patch sets for your version that you haven’t applied yet, download and store them in your repository. (Note: You must have the necessary rights during active support to do so.) Similarly, export or save any relevant MOS knowledge articles, or at least note their Doc IDs, in case you need to refer to them. This ensures you have a safety net of Oracle-provided material to reference even after access is gone.
• Onboarding with the Provider: Work with your new provider to set up kick-off meetings and technical workshops. They will likely want to gather information on your systems, including architecture diagrams, customizations, interfaces, and recent issues. Dedicate time for your team to assist in this knowledge transfer. Treat the provider team like an extension of your own – the more they know upfront, the faster they can help when an issue arises. Also, configure any necessary connectivity (some providers offer on-site appliances or VPN connections for support). Test the ticket logging process in advance so that, on day one, you know how to raise an issue and that it works.
• Communicate the Switch Internally: Ensure that all relevant IT staff and end-users (if they directly log support tickets) are aware of the support change. Provide them with the new support contact information, portal links, and procedures. It’s helpful to distribute a one-page “cheat sheet” on how to contact the new support and perhaps an FAQ on the differences. This will avoid confusion, such as someone accidentally trying to log into Oracle’s support site after the transition.

Pitfalls to Avoid:

• Gap in Coverage: Timing is crucial. Avoid any gaps between the Oracle support end date and the third-party start date. Even a few days’ gap is risky. Coordinate the dates and double-check them. A pitfall would be a contract misalignment where Oracle support ends on Dec 31, but the new contract starts Jan 2 – leaving Jan 1 uncovered (and of course that’s the day something goes wrong!). Start the new support a day earlier if necessary to overlap – better to double pay for one day than have no support.
• Failure to Close Out Oracle SRs: If you have any ongoing Oracle Service Requests (tickets) or pending escalations, try to get them resolved before you transition. Oracle will typically stop working on them once you are out of support. Sometimes that’s not fully in your control, but at least have the info from those SRs documented. Alternatively, brief the new provider on any ongoing issues; they may have to pick up troubleshooting where Oracle left off. Failing to do so can cause issues to fall through the cracks.
• Underestimating Cultural Change: Your internal teams might be accustomed to Oracle’s way of support, even if it had its frustrations. Moving to a new support provider is a change – people might not immediately reach out the same way or might be unsure if the new team can help with certain problems. Avoid a passive approach; encourage your team to engage the new provider actively. Don’t let problems fester because someone wasn’t sure “if we should call them for this.” In the early days, it’s better to over-communicate and over-report issues to establish a working relationship.

What IT Leaders Should Do: Oversee a transition project plan. This should include tasks like “notify Oracle of non-renewal, confirm acknowledgment,” “sign third-party contract,” “complete provider onboarding sessions by X date,” “test provider ticket logging,” “internal comms out by Y date,” and “Oracle support access backup done.”

Assign an owner to each task, such as the Oracle admin or the vendor manager. As the leader, ensure all tasks are completed before the switch date. It’s also wise to schedule a review meeting a week or two after the transition to capture any hiccups and ensure they are resolved.

Additionally, set expectations with the third-party provider about early support needs – for example, if you have critical periods (such as year-end processing), let them know to be on high alert.

With a solid transition plan in place, your organization should experience a seamless cutover. On the day after Oracle support ends, business and IT users will hardly notice the difference, except perhaps for improved responsiveness.

Consideration 13: Manage and Review the Ongoing Support Relationship

Overview: After switching to third-party support, the journey isn’t over – it enters a new phase of ongoing vendor management and continuous improvement. You should actively manage the relationship with your support provider to ensure they are delivering on promises and that you are realizing the expected benefits.

This involves setting up regular service review meetings, tracking key performance indicators (such as SLA adherence and ticket resolution times), and maintaining an open feedback loop.

In addition, continue to monitor the health of your Oracle environment and any changes in your business that may impact support needs. Over time, your company’s strategy might evolve (for example, a decision to migrate off Oracle applications to a cloud SaaS could arise in a few years). If and when such changes occur, you’ll need to adjust your support strategy accordingly, perhaps by ramping down third-party support as systems are retired, etc.

Also, maintain vigilance on license compliance and security just as you did at the start – these are ongoing concerns, though often easier to handle once you’re in a steady state.

The provider can become a valuable partner beyond just break-fix – many clients find that their third-party support vendor becomes a source of expert advice on how to maximize the longevity of their Oracle systems. Leverage that knowledge.

Essentially, manage the provider not as a short-term vendor but as a strategic partner over the contract term.

Best Practices:

• Regular Performance Reviews: Establish a cadence (e.g., monthly or quarterly) for formal service review meetings with the vendor. In these meetings, review key metrics, including the number of tickets opened, response and resolution times, any breaches of the SLA, and the root cause of major issues, among others. Also, discuss upcoming events, such as known maintenance or new projects, so the support team is prepared. Use these sessions to give feedback, both positive and constructive. A good provider will welcome input and continuously try to improve the service for you.
• Measure Business Impact: Track the broader impact of the switch. Are you indeed saving the expected dollars? (Check invoices and ensure they match the contract.) Have the saved funds been redirected to the initiatives as planned? (Check with finance.) Also, are there improvements in system stability or user satisfaction with support? Perhaps conduct an internal survey after 6 months to gauge user and IT sentiment about the new support model compared to the old. Having these data points will help you demonstrate the value realized to your leadership and build the case if you want to expand third-party support to other areas.
• Stay Current on Provider and Oracle Developments: Continue to watch the landscape. Keep in contact with your provider about their new services or tools that could benefit you, such as security scanning tools or newly supported products. Simultaneously, keep an eye on Oracle’s announcements that might affect you – for example, if Oracle suddenly changes support policies or offers extended support for free for a period (it happens occasionally), you want to know in case it affects your calculus. Also, monitor if Oracle releases any must-have features or a compelling cloud offering – this could influence future decisions, such as perhaps re-engaging with Oracle for those areas. Being informed ensures you can pivot strategy if needed.

Pitfalls to Avoid:

• “Set and Forget” Approach: Don’t treat moving to third-party support as an autopilot situation. If you ignore the vendor relationship until contract renewal time, you might miss out on optimizations or early signs of issues. For example, if support quality were to dip (perhaps due to staff changes on the vendor side), you’d want to catch that early and address it, not discover later that your teams were unhappy. Stay engaged as an active partner.
• Scope Creep or Unauthorized Changes: As time passes, be careful that your Oracle usage doesn’t drift into areas not covered by support or license. There could be a temptation to deploy new modules or expand usage since you’re saving money. But remember, without Oracle support, using new modules you aren’t licensed for (or versions beyond your license) is not allowed. Also, if you upgrade something on your own (some brave souls apply minor upgrades or patch sets on their own), verify with the provider that they still support you. Avoid doing anything that inadvertently breaks the agreed support scope or your license terms.
• Not Revisiting the Strategy: Your enterprise architecture and application portfolio will evolve. Maybe in three years, you’ll have 80% of those Oracle systems still running with great third-party support, and 20% replaced by something else. Or vice versa, maybe Oracle comes out with a new cloud product you adopt, putting you back in Oracle’s realm for that part. A pitfall is failing to revisit your support strategy periodically. Don’t assume the situation in year 1 remains the same in year 5. Plan to reassess: Are we still getting value? Should we extend the third-party contract or consider reverting to Oracle for any reason? These should be conscious decisions at renewal time, not automatic.

What IT Leaders Should Do: Act as an executive sponsor for the relationship with the support provider. Even after transition, have periodic check-ins with your counterpart at the vendor (e.g., an account manager or support director).

This keeps the relationship strong and signals to the vendor that your company’s leadership is keen on success. Internally, keep your leadership team informed with annual or biannual summaries of how the third-party support arrangement is performing. Highlight cost savings achieved, system uptime improvements, and any other relevant metrics.

Also, include any issues and how they were resolved. By doing this, you maintain confidence in the decision and ensure ongoing support from the business side. Finally, continue to cultivate your organizational knowledge of Oracle systems. While the provider handles day-to-day support, your internal IT team should still document any workarounds or fixes applied and maintain knowledge of the architecture.

This ensures you’re not completely dependent on the vendor and can make informed decisions down the road. In short, treat third-party support as a long-term partnership that needs care and feeding.

With proper management, it will deliver the promised strategic benefits—cost savings, flexibility, and service quality—year after year, while you steer your Oracle environment in the direction that best suits your enterprise’s needs. <hr>

Conclusion: Adopting third-party support for Oracle environments can be a game-changer for IT leaders under pressure to do more with less. By carefully considering the factors above – from understanding the model and building the business case to selection, negotiation, and transition, and finally, ongoing management – you can confidently navigate the switch and make it a success.

Many organizations worldwide have halved their support costs while maintaining or even improving service quality by leveraging independent support​. The key is to approach it strategically: know your environment, pick the right partner, and manage the change diligently.

This playbook of considerations is meant to serve as a roadmap for that journey. With thorough planning and execution, Oracle third-party support can become a valuable tool in your IT leadership toolkit, enabling you to invest in innovation while keeping your critical systems running smoothly, on your terms rather than the vendor’s.

Sources: The guidance above incorporates insights from industry analyses, case studies, and expert recommendations on Oracle third-party support.

Key references include Gartner research on trends in third-party support​. Oracle licensing and compliance advisory resources​, and documented experiences of organizations that have successfully made the switch​

Each consideration is informed by best practices observed in the field, ensuring that IT leaders can make informed, confident decisions about whether and how to pursue third-party support for their Oracle portfolios.