Financial institutions – from banks and insurers to capital markets firms – rely heavily on Oracle’s software portfolio for core operations. Oracle’s solutions like FLEXCUBE (core banking), Oracle Banking Platform, Oracle E-Business Suite (EBS), PeopleSoft, Oracle Database, and various risk and finance applications form critical IT infrastructure in this sector. However, the cost and constraints of Oracle’s Premier Support have led many CIOs to explore third-party support to reduce operating costs and gain flexibility. This advisory article compares Oracle’s official support with third-party support across these products, focusing on cost, scope, regulatory compliance, security, upgrade strategy, and legal considerations. We also highlight examples of financial institutions leveraging third-party support to cut costs, avoid forced upgrades, and stay compliant.
Cost Comparison and OPEX Impact
One of the biggest drivers for considering third-party support is cost savings. Oracle’s Premier Support typically costs around 22% of the original license fees per year, and Oracle often applies annual uplifts of a few percent. These support fees for a bank or insurer running a large Oracle estate consume a significant portion of the IT OPEX budget. Third-party support providers, by contrast, generally charge about 50% less than Oracle for equivalent support coverage. This means organizations can immediately cut maintenance spending by roughly half, freeing up millions to be redirected to strategic projects or digital innovation. Gartner research confirms that switching to third-party support can offset Oracle’s yearly price increases and help meet budget reduction goals.
- Annual Support Fees: Oracle Premier Support = ~22% of license cost (with 0-8% annual increases); Third-Party Support = ~50% of Oracle’s fee (often fixed or with lower increases). For example, if a bank pays $5 million yearly to Oracle, a third-party contract might be ~$2.5 million, saving $2.5 million annually.
- Multi-Year OPEX Reduction: Over multiple years, these savings compound. Companies avoid Oracle’s cumulative uplifts and can lock in a lower support cost. Some third-party clients report total savings up to 90% of the TCO when including avoided upgrade expenses and extended hardware life. This freed-up budget can be reinvested – The Iyo Bank in Japan, for instance, shifted savings from Oracle Database support into new customer experience initiatives after moving to third-party support.
- Budget Flexibility: Reducing Oracle support spend immediately relieves pressure on IT budgets. Instead of an ever-growing maintenance bill, CIOs gain predictable, lower OPEX. This is especially valuable in financial services, where cost-to-income ratios are closely watched. By trimming support costs, banks and insurers can fund innovation (AI, mobile banking features, etc.) that improves competitiveness.
In summary, third-party support offers significant cost relief compared to Oracle’s Premier Support. Many CIOs view it as a way to optimize run-the-bank costs and allocate more funds to change-the-bank investments. Financial institutions under margin pressure or budget cuts can realize substantial OPEX impact with this move while still maintaining their critical Oracle systems.
Scope of Support: Customizations and Legacy Releases
Another major difference is the scope of support provided. Oracle’s standard support has well-defined boundaries – it covers issues on vendor-supported versions and standard configurations. Still, it excludes assistance for customizations and ends for older product releases after their support lifecycle. In contrast, third-party support is far more accommodating, covering custom code, integrations, and legacy versions that Oracle no longer fully supports.
- Support for Customizations: Financial institutions often heavily customize Oracle applications (e.g., custom FLEXCUBE workflows, bespoke PeopleSoft HR modules, tailored EBS reports) to fit their business processes. Under Oracle Premier Support, if a problem is caused by custom code, Oracle’s typical response is to ask the customer to revert to the vanilla code – Oracle won’t fix issues caused by custom modifications. Third-party providers, however, will troubleshoot and resolve issues in customized environments. They take a holistic approach, helping identify root causes even if the bank’s team altered the code. For example, if a custom extension in an Oracle EBS financial module is causing errors, a third-party support engineer can craft a script or workaround to fix it. Oracle’s support would likely refuse to do the same, leaving the customer alone. Thus, third-party support embraces custom solutions, which is a big win for banks with heavily tailored Oracle systems.
- Legacy Release Coverage: Oracle adheres to a strict product lifecycle: after Premier Support (typically 5 years) and possibly Extended Support (for an extra fee), products enter Sustaining Support, where no new patches or updates are issued. This leaves customers running older versions (e.g., Oracle Database 12.1 or Oracle EBS 12.1) with limited help, effectively pressuring an upgrade. Third-party support breaks this model by continuing full support for legacy versions indefinitely. If a bank is stable on an older release of FLEXCUBE or an insurer is happy with PeopleSoft 9.x, a third-party vendor will still provide bug fixes, troubleshooting, and even security updates for that old version long after Oracle has ceased patches. For instance, when Oracle Database 12.1 reached end-of-support, many institutions turned to third-party support to avoid an urgent, costly upgrade. Independent providers can keep mature, stable systems running smoothly for 5, 10, 15+ years without forced upgrades. This extended product life is invaluable in financial services, where core systems (core banking, payment engines, etc.) may be trusted and unchanging for a long time.
- Breadth of Product Coverage: Third-party support isn’t limited to core database or ERP software – it spans the full Oracle product portfolio used in financial services. Specialized industry applications like Oracle FLEXCUBE, Oracle Banking Platform, and Oracle Financial Services Risk/Compliance suites can be supported by experienced third-party engineers (some providers have former Oracle specialists in core banking on staff). Likewise, older Oracle middleware (WebLogic, etc.) and analytical tools (Hyperion, OFSAA) can be maintained beyond Oracle’s timelines. A bank can consolidate support from its Oracle Database and middleware stack to its industry-specific apps under one third-party provider. Many third-party vendors have dedicated practices for each Oracle line (Database, EBS, PeopleSoft, JD Edwards, Siebel, etc.), ensuring expertise across the board.
Third-party support covers customizations and legacy systems, allowing financial institutions to maintain their Oracle environment as-is without vendor-imposed constraints. A stable but heavily customized core banking system can keep running for years with full support, and a legacy Oracle ERP can continue to receive updates for bugs or compliance, even if Oracle has moved on. This broader scope is a key advantage when Oracle’s standard support model doesn’t align with the bank’s IT strategy.
Regulatory Patching and Localization Updates
Financial services firms operate in a highly regulated environment, so their software must continually adapt to changing laws, regulations, and local requirements. During the Premier Support period, Oracle delivers periodic regulatory patches, tax updates, and localization packs for its applications (especially ERP and core banking). A common concern is whether third-party support can match this, ensuring banks remain compliant with regulatory changes if they leave Oracle’s umbrella.
Third-party providers recognize that compliance updates are mission-critical for clients in banking and insurance. Leading providers include the delivery of tax, legal, and regulatory updates as part of their standard support service. In practice, this means:
- Tax and Legal Changes: If a new tax rate is introduced or a labor law affecting payroll is updated, third-party support teams will develop the required patch or script for systems like Oracle EBS Financials or PeopleSoft HR. For example, when a new VAT rule or payroll regulation occurs, a third-party vendor can supply updated configuration or code to ensure the Oracle system stays compliant. These updates cover the same needs that Oracle’s support would handle during its support period.
- Banking and Insurance Regulations: Industry-specific applications (like Oracle FLEXCUBE core banking or Oracle’s risk management modules) often require updates for regulatory reporting, compliance with central bank guidelines, or global standards (Basel III, IFRS 17, etc.). Third-party support firms track such changes in key markets and create solutions for their clients. For instance, if a country’s banking regulator mandates a new reporting format for loan data, the support provider can help the bank’s Oracle platform implement that change on schedule. Localization support (language, currency, local business rules) continues under third-party support, so international banks using Oracle systems in multiple countries remain covered.
- Frequency and Quality: Third-party vendors typically issue regulatory bulletins and updates on time, often aligning with government release schedules. Clients might receive compliance updates via documentation or fix scripts that the third-party has tested. This ensures that the system’s compliance is current even without Oracle’s official patch. In one study, third-party supported Oracle clients received tax and regulatory updates enabling them to remain compliant with finance and HR laws across 200+ jurisdictions. The scope included everything from payroll tax tables to financial reporting changes, much like Oracle’s support would provide.
From an auditor and regulator’s perspective, what matters is that the institution can demonstrate its systems are current with applicable regulations. Third-party support can meet this bar, with careful documentation. Providers assist in producing evidence that all regulatory requirements (tax codes, filings, etc.) are addressed by the custom updates they supply. Financial institutions should ensure their third-party vendor has a solid process for monitoring regulatory changes in each jurisdiction they operate. Many large banks and insurers have successfully passed audits while on third-party support by leveraging their support partner’s compliance updates and detailed records.
In summary, moving off Oracle support does not mean falling out of compliance. Independent support vendors continue delivering the regulatory patches and localizations to keep Oracle-based systems legally up-to-date. CIOs should verify this capability when evaluating a provider, but the top third-party firms have a track record of keeping financial services clients compliant worldwide.
Information Security and Audit Risk
For CIOs in banking and insurance, information security is non-negotiable. A key question arises: “Without Oracle’s quarterly security patches, can we keep our systems secure and satisfy our regulators and auditors?” It’s a valid concern – Oracle’s Critical Patch Updates (CPUs) address known vulnerabilities, and falling behind can raise flags. Third-party support providers have developed robust strategies to manage security risks, often providing multi-layered protection beyond vendor patches. Here’s how security and audit concerns are handled with third-party support:
- Alternate Security Patching (Virtual Patches): Since third-party providers cannot distribute Oracle’s proprietary patches, they use virtual patching, custom fixes, and compensating controls to remediate vulnerabilities. When Oracle announces a security flaw (e.g., a database SQL injection vulnerability), the third-party vendor analyzes it and creates their fix or blocking mechanism. This might be a configuration change, a database trigger or script, a firewall rule, or an intrusion detection signature that closes off the exploit. Essentially, they “harden” the system against the vulnerability without modifying Oracle’s source code. This approach can be very effective – for example, a critical Oracle Database bug could be mitigated by a custom code patch or a network rule that prevents malicious packets, achieving a similar protection level to Oracle’s official patch. Such virtual patches are sometimes deployed faster, as one need not wait for Oracle’s next quarterly cycle. Providers also perform regular vulnerability assessments to find and fix weaknesses proactively.
- Continuous Monitoring and Response: Top third-party support vendors compensate for the lack of vendor patches by offering enhanced security monitoring. They will continuously monitor a client’s Oracle environments for suspicious activity or known attack patterns. If an anomaly (a possible breach attempt) is detected, their security team can respond immediately, isolating affected systems or applying a rapid configuration change to block the threat. This 24/7 watch, combined with intrusion detection systems and periodic penetration testing, creates a layered defense around the Oracle applications. In effect, third-party support can act like an outsourced security operations team focused on the Oracle stack, something not included in Oracle’s standard support. Additionally, third-party providers often send security advisories to clients (similar to Oracle’s CPU bulletins) with guidance on emerging threats and how to mitigate them.
- Audit and Regulatory Compliance: Auditors expect known vulnerabilities to be addressed promptly in regulated sectors like finance. While being off Oracle support means you aren’t applying Oracle patches, you can still satisfy auditors by showing compensating controls. Third-party providers help by mapping each Oracle patch you miss to an alternative solution they implemented. For example, suppose a PCI DSS standard requires patching a critical database flaw. In that case, the third-party support firm will document how their virtual patch or firewall rule mitigates that specific CVE and provide that evidence for audit purposes. Organizations must diligently maintain this documentation. Companies with third-party support have passed IT audits by demonstrating that all Oracle security bulletins have corresponding mitigations. Regulators want to see that the institution is secure; how you achieve security (Oracle patch vs. third-party fix) is less important than the result. However, the bank’s security and compliance teams must be more active in working with the provider to track and sign off on these measures.
- Proven Track Record: It is noteworthy that no major security incidents have been publicly linked to companies using third-party support to date. Thousands of organizations, including banks and government agencies, run Oracle systems supported by third parties without Oracle’s direct patches, yet maintain strong security. This suggests that with proper controls, the risk can be managed. Of course, due diligence is critical – CIOs should thoroughly vet any third-party support provider’s security credentials. Ensure they follow industry best practices (e.g., ISO 27001 certification, SOC 2 audits) and have clear procedures for zero-day threats. Many providers will outline their emergency response process (some have guarantees for developing a fix within days or even hours of a new critical vulnerability). Asking for client references in the financial sector can also give comfort regarding their performance under real-world threats.
In summary, while leaving Oracle’s patch program is significant, third-party support can maintain an equal (or even enhanced) security posture if approached correctly. Banks and insurers can stay secure and satisfy auditors and regulators through virtual patching, vigilant monitoring, and close collaboration on compliance. The key is to choose a reputable support partner and remain disciplined in applying their recommended security controls. With these precautions, many financial institutions can meet stringent security requirements without Oracle’s direct involvement.
Upgrade Timing, Oracle Roadmap Pressure, and Stack Freeze
Oracle’s product strategy and support policies often create pressure to upgrade – something CIOs in financial services know well. Oracle typically provides full support for a product version for a set number of years, after which customers must upgrade to stay supported or pay extra for extended support. Oracle’s roadmap is also increasingly cloud-focused, nudging customers toward Oracle Cloud applications or cloud database services. These vendor-driven upgrades can be disruptive, costly, and not always aligned with business priorities for banks and insurers running stable on-premise systems. Third-party support offers an alternative path: it allows organizations to freeze their technology stack on a preferred version and timeline, effectively removing the forced march of upgrades dictated by Oracle.
Key points regarding upgrades and roadmaps:
- Avoiding Forced Upgrades: With Oracle Premier Support expiration looming, firms often feel compelled to upgrade (e.g., upgrading Oracle E-Business Suite 12.1 to 12.2, or moving from an older Oracle Database to the latest release) simply to remain supported. These upgrades can be multi-million dollar projects with significant testing, integration rework, and risk undertaken primarily to “stay in support” rather than to gain new functionality. Third-party support eliminates the need for these mandatory upgrades. Companies can continue running their current version if it meets business needs, with assurance that the third-party vendor will keep supporting it. If your core banking system, built on Oracle FLEXCUBE 12.x, is stable and does the job, you do not have to embark on an expensive upgrade to the newest release just because Oracle’s support is ending. You can avoid the disruption and focus on other priorities. One CIO remarked that after switching to third-party support, they could “run their stable Oracle 11i ERP for another five years” without issue, whereas Oracle would have forced a migration to a new system.
- Freedom from Oracle’s Roadmap: Oracle’s roadmap might not align with a bank’s strategy. For example, Oracle might invest in cloud-based banking platforms or new analytics. In contrast, the bank might prefer to stick with on-prem solutions or consider alternative vendors at their own pace. Third-party support grants flexibility to chart your IT roadmap. You are no longer bound to Oracle’s upgrade schedule or end-of-support dates. If Oracle releases a new version or a cloud product, you can evaluate its merits and business value, rather than being coerced by support deadlines. In the Iyo Bank case, the bank explicitly noted that instead of following a vendor-led IT roadmap based on Oracle’s upgrade plans, they can now execute a business-led roadmap aligned with their objectives. This is a powerful strategic benefit – IT can focus on initiatives that deliver competitive advantage (digital banking, data analytics, etc.), rather than expending resources on upgrades that primarily benefit the vendor.
- Extended System Lifespan: Many financial institutions have legacy platforms that, while old, are deeply embedded and reliable (e.g., an old Oracle-based policy administration system at an insurer, or a trading system on Oracle Database that’s heavily customized). Third-party support can extend the life of these systems nearly indefinitely. One large manufacturing firm could keep using an outdated Oracle JD Edwards version because third-party support provided ongoing fixes after Oracle’s support ended – a scenario equally applicable to banks running end-of-life software. This buys time to plan transformation on your terms. A bank could choose to modernize its core banking in 5 years, and third-party support will sustain the current system in the interim without forcing a premature change. When you’re ready to migrate (perhaps to a new fintech solution or a different vendor’s product), you can do so deliberately, without juggling an Oracle-mandated upgrade.
- Upgrade When You Are Ready: With third-party support, the institution controls the timing of any upgrades or migrations. Some may never upgrade a certain system if it remains fit for purpose, simply maintaining it via third-party fixes. Others might use the breathing room to plan a major leap (for example, skipping several Oracle versions or jumping directly to a next-gen platform once it’s mature). Upgrades become a business decision, not a support contract requirement. This can also improve the ROI of existing software, squeezing additional value out of fully depreciated systems. As Mr. Shota Yano of Iyo Bank noted, third-party support allowed them to continue maximizing their Oracle Database investment for many years with “no required upgrades”, yielding a higher return on that software spend.
- Leverage and Negotiation: Freeing yourself from the immediate need to upgrade can also give you leverage in negotiations. If Oracle pushes a bank to migrate to Oracle Cloud, it can resist knowing it has a support alternative. This leverage has sometimes led Oracle to offer more favorable terms or discounts to win back business. While that might or might not be a goal, it’s an ancillary benefit—the bank is no longer locked in; it has options.
Of course, a trade-off is that you forego new features and enhancements Oracle might introduce by not upgrading. For some, that’s acceptable or preferred (many financial institutions value stability over shiny new features in core systems). Others might supplement stability with innovation in other layers (for instance, keep the core banking system stable under third-party support, but build new digital services on top via APIs). The bottom line is that third-party support puts you in control of your upgrade cycle. It relieves the constant time pressure of Oracle’s support deadlines and lets CIOs schedule major changes when it makes sense for the business, not when the vendor dictates.
Legal and Contractual Considerations
Switching to third-party support is fully legal, but it does require attention to Oracle’s licensing and contract terms. Oracle’s license agreements are separate from support contracts – you typically have a perpetual right to use the software, and support is optional. However, there are a few legal nuances and protections to consider when moving off Oracle support:
- Software License Rights: Ensure you understand your Oracle license agreement. Most Oracle licenses (especially perpetual licenses) allow you to use the software indefinitely, whether or not you purchase support. There is no clause prohibiting third-party support in standard Oracle contracts. Courts have affirmed that customers can legally obtain support from a third party for licensed software. So, simply switching support providers does not put you in violation of the license. You continue to run the Oracle software under your existing license rights. Important: If you have a term-based license or subscription, the situation may differ, but for typical perpetual on-premise licenses, it’s your choice who provides support.
- No Oracle Intellectual Property After Termination: While using third-party support is allowed, you must stop downloading or using Oracle’s proprietary support materials once your Oracle support contract lapses. This means no grabbing patches, updates, or new releases from Oracle’s support portal (MOS) after the end date. Doing so would breach Oracle’s support agreement (essentially using Oracle IP without paying). In practice, this requires some internal controls: revoke access to Oracle’s patch download site for your admins, and rely only on patches/fixes provided by the third party as we advance. Many companies will archive the Oracle patches they received while under support, as they are entitled to continue using those. But anything released by Oracle after you left cannot be applied. The third-party vendor will provide replacements for needed fixes, as discussed earlier.
- “Matching Service Levels” Policy: Oracle has a contractual policy (often called the Matching Service Level clause) that prevents partial support drop within a product family. In short, you cannot simultaneously have some licenses for a given Oracle product on Oracle support and others on third-party support. For example, if a bank has 1000 Oracle Database licenses under one agreement, it can’t take 500 of them to a third party and leave 500 with Oracle – Oracle requires all or none in a license set. When switching, you generally switch the entire environment for that product. The remedy is straightforward: plan to terminate Oracle support for the whole product set when moving to the third party.
In some cases, companies even terminate (give up) unused licenses to reduce costs, so the remaining licenses can all move off Oracle support without violating this rule. Reviewing your support contracts and identifying how Oracle defines these license sets is wise. Coordinate the transition at a contract renewal date to avoid overlap or unintended breach. Engaging Oracle for clarifications or negotiating exceptions (like carving out a subset) is possible but challenging. Most banks simply opt to switch the entirety of each targeted product. Once Oracle support is terminated, the clause will no longer be applicable. - Oracle ULA Considerations: Be cautious if your organization is in an Oracle ULA (Unlimited License Agreement) period. ULAs usually require you to stay on Oracle support during the term and certify your usage. Exiting Oracle support in the middle of a ULA could be considered a breach. Best practice is to wait until the ULA ends and you’ve certified (i.e., converted your unlimited use into specific perpetual licenses) before moving to third-party support. After certification, you have normal licenses and can proceed. Leaving a ULA early can leave you without valid licenses or expose you to compliance issues, so timing is critical for those scenarios.
- Support Reinstatement: Understand that if you leave Oracle support and later decide to return, Oracle may charge hefty reinstatement fees. Oracle’s policy often requires back payment of all the support fees for the period you were off support, plus a penalty (often 150% of the last annual fee). This effectively discourages customers from dropping support temporarily. While these fees can sometimes be negotiated, a return to Oracle support could be cost-prohibitive. Thus, CIOs should approach third-party support as a long-term or strategic move rather than a short-term fix. In practice, most who switch do not go back, given the ongoing satisfaction and savings, but this is a factor to be aware of.
- Contractual Protection with Third-Party Vendor: Review the contract for key protections when signing with a third-party support provider. Ensure the provider offers indemnification – leading vendors will indemnify customers against any IP infringement claims (for instance, if Oracle were to claim the support firm’s methods infringed Oracle’s IP, the vendor would protect the customer legally). This scenario is unlikely to involve the customer directly (Oracle’s well-known legal battles have been against the providers, not the customers), but it’s wise to have that coverage. Also, define service levels (response times, etc.) and deliverables like regulatory updates in the contract. Verify that the provider has strict confidentiality and data protection measures, as they may handle your sensitive system data. Treat it with the same rigor as any critical outsourcing contract, including escalation procedures, exit clauses, and perhaps a longer-term price lock to prevent unexpected increases.
- Oracle Audits: Financial institutions are routinely subject to Oracle license audits. After moving to third-party support, Oracle may still audit your license usage (they have the right to audit license compliance). It’s important to remain fully compliant with license metrics (e.g., not exceeding CPU or user counts) because you won’t have Oracle support to smooth out any issues. Some companies engage independent licensing advisors to double-check compliance before the switch. If you are compliant, being off support is not grounds for any license penalty. However, demonstrate that you have not used Oracle’s support materials beyond your entitlement. Good internal record-keeping (e.g., showing when support was terminated and no new patches were downloaded after that date) can close any audit contentions. In short, manage your licenses diligently to avoid giving Oracle any opening for claims.
Legally, a move to third-party support is a well-trodden path now – thousands of Oracle customers have done so, and court rulings have upheld its legitimacy. By minding the contractual details above, CIOs can ensure a smooth transition without legal hiccups. Many organizations involve their legal and procurement teams early to review Oracle agreements and the third-party contract to put proper protections in place. With careful planning, the legal risk is low, and you can enjoy the benefits of third-party support fully within your rights.
Industry Examples in Financial Services
Third-party support has gained traction across industries, including numerous banks, insurers, and investment firms. Below are a few examples and scenarios illustrating how financial institutions have leveraged third-party Oracle support:
- Regional Bank Cuts Costs & Avoids Upgrade: The Iyo Bank, a major regional bank in Japan, switched to third-party support for its Oracle Database, which was central to their loan system. By doing so, the bank immediately reduced its database maintenance costs and avoided an expensive system upgrade, which would have required it to stay on Oracle support. The savings in cost and IT resources were redirected to digital innovation projects aimed at improving customer experience. Importantly, Iyo Bank could use its stable Oracle Database version for at least 15 years with full support, instead of following Oracle’s forced roadmap. This case shows a bank improving its IT ROI and service quality by breaking free from Oracle’s costly support model.
- Insurer Maintains Compliance on Legacy ERP: A large insurance company running Oracle E-Business Suite 12.1 faced end-of-support and pressure to upgrade to Oracle’s cloud-based applications. Instead, they moved to a third-party support provider. The provider delivered all necessary regulatory updates (such as annual tax code changes and insurance regulatory reporting tweaks) to the EBS system, even though Oracle had stopped doing so. The insurer saved about 50% on support fees and stayed compliant with financial regulations through the third party’s updates. Their auditors accepted the compensating controls and third-party patches as valid, and the IT team was relieved from a forced migration. (This example combines common outcomes reported by several financial services firms on third-party support.)
- Improved Service for a PeopleSoft User: A financial services firm using Oracle PeopleSoft for HR and finance had struggled with performance issues and unresolved tickets under Oracle support. After switching to a third-party provider, they saw much better support service. The third party assigned a dedicated team that deeply understood the firm’s customized PeopleSoft environment. They fixed the lingering performance bottlenecks and provided proactive tuning that Oracle’s standard support hadn’t offered. The CIO noted that the personalized SLA and faster response improved system stability and user satisfaction. This highlights how third-party support’s tailored approach can benefit even mission-critical financial workloads, where downtime or inefficiency is costly.
- Global Bank Freezes Core Banking Changes: A global bank with operations in multiple countries ran an older version of Oracle FLEXCUBE as its core banking platform. Oracle’s roadmap required an upgrade to the newer Oracle Banking Platform or a major FLEXCUBE version jump, which would have been a multi-year project. Instead, the bank engaged a third-party support firm experienced in Oracle banking solutions. This allowed the bank to freeze its core banking software version for the next few years while receiving support and patches for any issues. During this period, the bank focused on developing new digital channels and front-end improvements (which were not tied to the core upgrade). The third-party handled the back-end stability. As a result, the bank avoided a risky upgrade, saved on project costs, and still met all regulatory requirements on the existing platform. When the time comes to overhaul core banking, the bank will do it on its schedule, possibly even considering non-Oracle alternatives – a flexibility earned by using third-party support.
These examples demonstrate tangible benefits for financial institutions: cost savings, upgrade deferral, improved support quality, and maintained compliance. Importantly, they show that even highly regulated and risk-averse organizations like banks can and do leverage third-party support successfully. The key is selecting a credible support partner and planning the transition carefully (in each case above, the firms conducted due diligence and had transition plans to ensure continuity).
According to industry reports, as of 2021, over 4,000 customers (including many in financial services) had adopted third-party support for Oracle or SAP products, and that number has grown since. The approach is no longer an exotic but a mainstream option for CIOs seeking efficiency. Banks and insurers worldwide have saved millions in support fees while keeping their Oracle systems reliable and compliant by going this route. Their experiences serve as valuable lessons for peers evaluating a similar move.
Recommendations
For CIOs and IT procurement leaders in financial services considering third-party Oracle support, here are actionable recommendations:
- Conduct a Cost-Benefit Analysis: Begin with an honest evaluation of your Oracle support spend versus the value received. Calculate the 5-year cost if you stay with Oracle (remember to factor in annual increases and any planned upgrades). Then compare with third-party support quotes (typically ~50% of Oracle’s fees). Include indirect savings like avoided upgrade costs and resource hours. This will quantify the OPEX impact and build the financial case (e.g., “saving $X million over 3 years”). Engage finance and procurement early to validate the savings.
- Identify Target Systems: Review your Oracle product portfolio and identify which systems are good candidates for third-party support. Ideal targets are stable, mature systems that you don’t plan to upgrade soon – for example, an older EBS or PeopleSoft instance that meets current needs, or an Oracle Database that’s reliable but out-of-date. Also consider highly customized systems where Oracle isn’t adding much value in support. List out these candidates and note their Oracle support renewal dates. Avoid switching anything truly cutting-edge or where you need Oracle’s ongoing innovations (those are likely few in on-premise Oracle environments nowadays).
- Check Compliance and Contracts: Review your Oracle license agreements and support policiesbefore making any moves. Ensure you have the rights (perpetual licenses, etc.) to continue using the software off support. Pay special attention to the Matching Service Levels clause – plan to move entire product license sets to a third party to stay compliant. If you’re under an Oracle ULA or other special agreement, get expert advice on timing the switch to avoid breaches. Involve your legal team or a licensing specialist to double-check these details. It’s also wise to self-audit your license usage now to clear any issues (true-up if needed) so that you exit Oracle support in full compliance.
- Evaluate Third-Party Providers Rigorously: Treat selecting a third-party support provider like a critical vendor decision. Research the leading vendors (e.g., Rimini Street, Spinnaker Support, Support Revolution, etc.) and consider issuing an RFP focusing on financial services experience. Key criteria to evaluate:
- Support Services Scope: Can they cover all your Oracle products (database, applications, industry solutions) in the regions you operate in? Do they include regulatory/tax updates for your countries? Will they fully support your customizations and integrations?
- Security & Compliance Capabilities: Ask detailed questions about how they handle security patches (look for explanations of virtual patching, monitoring, incident response). Request examples of how they kept a client secure during a major vulnerability. Ensure they will help with audit compliance by providing documentation of mitigations. Check for security certifications (ISO 27001, SOC reports).
- Track Record in Finance: Look for references or case studies in banking/insurance. A provider that supports other banks is preferable, as they’ll understand regulator expectations and common industry customizations. You may even request to speak to a reference client in a similar industry to hear their experience.
- Service Quality: Understand their support model – do you get a dedicated account manager and senior engineers on your account? What are the guaranteed response times for critical issues? Will they be 24/7 and global? Many third parties promise 15-minute responses for P1 issues, for example. Ensure the SLA and support model align with your operational needs (a core banking outage at midnight needs instant attention).
- Contractual Terms: Scrutinize the contract. Ensure there’s robust indemnification protecting you. Look at termination clauses (in case you ever needed to switch back or change providers). Check if fees are fixed for multiple years or if there’s any escalation. Clarify how they handle adding new modules or upgrades if you choose to do one with them.
- Plan the Transition in Stages: Develop a transition plan for moving off Oracle support. Time it so you switch at the end of Oracle support periods to avoid paying for overlapping support. You might phase different systems at different times (coordinating with their contract renewal dates). Before cutover, download and archive all Oracle documentation and patches you are entitled to (for reference, though you won’t use new ones in the future). Communicate internally to application owners that Oracle support will end on X date and the new provider will take over. Establish communication channels with the new provider and perhaps run through a few test support scenarios. Many firms do a “freeze period” around the switch where no new changes are applied to systems, ensuring stability during the handover. Also, brief your cybersecurity and compliance teams about the new processes so auditors and regulators can be informed proactively. A smooth, well-coordinated transition will make day 1 with the new support feel seamless.
- Maintain License Discipline Post-Switch: After moving to third-party support, remain vigilant about license compliance and Oracle interactions. Do not download Oracle patches or seek Oracle support informally – channel all needs through your new provider. Keep evidence of the third party’s fixes and communications in case of audits. It may help to have a point of contact in your organization to liaise with Oracle if needed (for example, if Oracle announces an audit, you respond promptly and transparently). In short, operating as a self-sufficient Oracle customer means you still use Oracle software, without Oracle’s direct help. With good processes, this is entirely manageable and routine.
- Monitor and reassess: After switching, regularly assess the arrangement. Are you getting the support quality promised? Are issues being resolved on time? Keep metrics (incident resolution times, system stability, cost savings realized) to report to senior management the benefits achieved. You’ll most likely find the support experience improved (more personalized and faster) and your costs much lower. However, if any service gaps appear, address them with the provider quickly. Also, maintain a longer-term IT roadmap: use the breathing room to plan future upgrades or migrations on your terms. Third-party support is not an endpoint but a strategy to give you flexibility – leverage that flexibility wisely, whether it’s modernizing core systems gradually or investing savings into new fintech partnerships, etc. An exit strategy (for eventually retiring or replacing very old systems) is still prudent, even if that horizon is extended.
These steps allow CIOs to confidently navigate the shift to third-party Oracle support. The key is to do due diligence upfront and actively manage the new support relationship. Many banks and insurers have shown that the right planning can dramatically cut costs and improve support without compromising compliance or security. Third-party support is a viable and increasingly popular option for financial institutions weighed down by Oracle support fees and constraints. With careful execution of the above recommendations, you can unlock substantial value while maintaining the robust, compliant operation that regulators and customers expect.
