Third-Party Support Risk Assessment
We conduct product-by-product risk assessments for organisations evaluating third-party Oracle support — quantifying real risk, dismissing manufactured fear, and building mitigation strategies. Fully independent.
1. The Risk Framework: Separating Signal from Noise
Before examining each risk individually, we need to establish the framework for evaluating them — because Oracle's risk narrative is deliberately designed to blur the distinction between risks that are real and material, risks that are real but manageable, and risks that are manufactured to prevent you from leaving.
Every risk must be evaluated across three dimensions. Probability: How likely is this risk to materialise for your specific Oracle deployment? Not in theory — in practice, given your products, your environment, and your operational maturity. Impact: If the risk materialises, what is the financial, operational, or strategic consequence? A risk with a $50,000 remediation cost is different from one that forces a $3 million reinstatement. Mitigation: What actions can you take before, during, or after the transition to reduce the probability or impact? A risk with a proven, affordable mitigation is categorically different from one you simply have to accept. See our guide to dropping Oracle support and reinstatement.
Most Oracle customers evaluating third-party support get stuck in a loop of unquantified anxiety — they know the risks exist but have never assessed them with the same analytical rigour they'd apply to any other business decision. Oracle's sales team exploits this by presenting risks as binary (either you have Oracle support or you're exposed) rather than as a spectrum that varies by product, by environment, and by the mitigations you deploy. The purpose of this article is to break that loop. For the complete provider comparison that complements this risk analysis, see our Oracle Third-Party Support Providers guide.
2. Risk 1: The Security Patching Gap
Risk level: HIGH for internet-facing databases. MEDIUM for internal applications. LOW for isolated/non-production systems.
This is the most significant genuine risk of leaving Oracle support, and it deserves the most detailed treatment. When you leave Oracle Premier Support, you lose access to Oracle's quarterly Critical Patch Updates (CPUs) — the official patches that address known security vulnerabilities in Oracle software. Oracle publishes CPUs four times per year, and each CPU typically addresses 100–400 vulnerabilities across the product portfolio, with 20–60 classified as critical or high severity.
What Actually Happens Without CPUs
Your Oracle software does not become immediately vulnerable the day you leave support. The vulnerabilities addressed by CPUs existed before the patch — you were already exposed during the gap between vulnerability discovery and patch release. What changes is your ability to close that exposure through Oracle's official fix. If Oracle releases a CPU addressing a critical vulnerability in Oracle Database 19c, and you're on third-party support, you cannot apply Oracle's patch.
Third-party providers address this through alternative mechanisms: virtual patching (applying protection at the network, WAF, or IPS layer that prevents exploitation of the vulnerability without modifying Oracle's code), security advisories (detailed guidance on configuration changes that mitigate the vulnerability), and in some cases, independently developed binary patches (actual code fixes developed by the third-party provider). These alternatives are effective — thousands of organisations have operated on third-party support for years without security incidents — but they are not identical to applying Oracle's official patch. For a detailed comparison of how security differs between the two models, see our third-party vs. Oracle Premier Support analysis.
Where This Risk Is Highest
The security patching risk is not uniform. It concentrates in specific scenarios: Oracle Database instances directly accessible from the internet or from untrusted networks, environments subject to regulatory frameworks that explicitly require vendor-issued patches (PCI-DSS can be interpreted this way, depending on the QSA), Oracle software running in environments with high threat profiles (financial services, government, healthcare), and products with a high frequency of critical CVEs (Oracle Database and WebLogic have significantly higher vulnerability discovery rates than PeopleSoft or Hyperion).
Where This Risk Is Overblown
For the majority of enterprise Oracle deployments — internal-facing databases behind multiple security layers, application servers accessible only from the corporate network, legacy ERP systems with no internet exposure — the practical security risk of operating without Oracle's CPUs is low. The vulnerabilities addressed by CPUs require specific access conditions to exploit. If your Oracle Database is behind a firewall, accessible only from a hardened application tier, with no direct SQL*Net exposure to untrusted networks, the attack surface that CPUs address is narrow. Virtual patching and configuration hardening provide adequate protection for these environments.
Mitigation Strategy
Before leaving Oracle support, conduct a security assessment of every Oracle product: map its network exposure, identify its access paths, review recent CVE history for the specific product and version, and evaluate whether your existing security architecture (firewalls, IPS, WAF, network segmentation) provides compensating controls. Products with high exposure and high CVE frequency should remain on Oracle support. Products with low exposure and effective compensating controls are strong candidates for third-party support. This is the most important distinction in the entire decision framework.
3. Risk 2: Version Lock-In
Risk level: HIGH for products with active upgrade plans. LOW for stable/mature products. ZERO for products approaching retirement.
When you leave Oracle support, you forfeit access to new Oracle software versions. You cannot download Oracle Database 23ai if you're currently running 19c. You cannot upgrade PeopleSoft to a new PeopleTools release. You are locked into the version you have at the time of transition — indefinitely, or until you either return to Oracle support (with reinstatement penalties) or migrate to an entirely different platform.
What Actually Happens
Version lock-in sounds alarming in the abstract. In practice, it affects only organisations that have active, funded, timeline-committed plans to upgrade to a newer Oracle version. The reality for most enterprise Oracle estates: upgrades are infrequent, expensive, high-risk projects that organisations postpone for years. A company "planning" to upgrade from Oracle Database 19c to 23ai has, in most cases, been "planning" that upgrade for two years and will continue planning it for another two before committing resources. The version lock-in imposed by third-party support is often indistinguishable from the version lock-in imposed by the organisation's own upgrade inertia.
Oracle Database 19c has Long Term Support through at least April 2027, with Extended Support available beyond that. PeopleSoft, Siebel, and JD Edwards are on continuous delivery models with extended support roadmaps. The version you're running today is very likely the version you'll be running for the next 3–5 years regardless of your support provider. The question is not whether you'll be locked into your current version — it's whether you're paying Oracle $2 million a year in support for the privilege of being locked into it.
Where This Risk Is Real
Version lock-in is a genuine constraint when: a specific new feature in a future Oracle version is required for a funded business initiative (e.g., Oracle Database 23ai's JSON Relational Duality for a planned application modernisation), a regulatory requirement mandates a minimum software version (rare but possible in highly regulated industries), or the current version is approaching absolute end of life with known security issues that cannot be addressed through virtual patching.
Mitigation Strategy
Evaluate each product's upgrade trajectory honestly. Not "we might upgrade someday" — but "we have budget, resources, and an approved timeline to upgrade within 36 months." Products meeting that test should remain on Oracle support. Everything else is paying an upgrade tax on an upgrade that isn't happening.
4. Risk 3: The Reinstatement Trap
Risk level: HIGH if the decision is reversible. MEDIUM if partially reversible. LOW if the decision is final.
Oracle's reinstatement penalty is the financial mechanism that makes leaving Oracle support a one-way door. If you terminate support and later need to reinstate, Oracle's standard policy requires: all back-support fees for the lapsed period (22% × net licence value × number of years lapsed), plus a reinstatement penalty of up to 50% of those back fees. For a product with $1M in annual support dropped for three years, the reinstatement cost is: ($1M × 3) + ($3M × 50%) = $4.5 million.
Why This Risk Is Uniquely Dangerous
The reinstatement trap is dangerous not because it's large (though it is) but because it punishes uncertainty. Every other risk in this article can be managed through preparation, mitigation, or alternative solutions. The reinstatement penalty punishes the specific scenario where you leave Oracle support and later discover you need it back — and the penalty grows larger the longer you've been away. It converts the third-party support decision from a recoverable experiment into a near-permanent commitment.
This is by design. Oracle calibrated the penalty to ensure that the cost of leaving and coming back exceeds the cost of never leaving in the first place. The reinstatement penalty is not a fee — it's a deterrent.
Scenario: The Upgrade That Changed Everything
A European logistics company moved their entire Oracle Database estate to third-party support in 2021, saving $1.8M annually. In 2024, their board approved a digital transformation programme requiring Oracle Database 23ai features (specifically, JSON Relational Duality and AI Vector Search). Accessing 23ai required returning to Oracle support. Three years of lapsed support at $1.8M/year = $5.4M. Reinstatement penalty at 50% = $2.7M. Total reinstatement cost: $8.1M. Net savings over the three years on third-party support: $5.4M (three years × $1.8M savings). Net loss from the round trip: $2.7M. The company saved money every year on third-party support — and still lost money overall because the reinstatement penalty exceeded the accumulated savings.
Mitigation Strategy
The reinstatement risk is entirely a function of decision quality. It is high when you move products that might need Oracle support again. It is zero when you move products you will never need to upgrade or that are being retired. The mitigation is not financial — it's analytical. Every product you move to third-party support must pass the finality test: "Can we commit, with high confidence, that we will never need Oracle support for this product again?" Products that pass go to third-party support. Products that don't, stay. The reinstatement penalty is not a risk to be managed — it's a consequence to be avoided through better decision-making. For guidance on the few scenarios where reinstatement makes sense, see our analysis of returning to Oracle after third-party support.
5. Risk 4: Third-Party Provider Viability
Risk level: LOW for established providers. MEDIUM for smaller/newer providers. HIGH for undercapitalised startups.
What happens if your third-party support provider goes out of business, is acquired, or fundamentally changes its service model? You're left without support on products you can no longer return to Oracle for (without the reinstatement penalty). This is a genuine risk — though its probability varies enormously by provider.
The Realistic Assessment
Rimini Street is publicly traded with $400+ million in revenue and a twenty-year operating history. The probability of Rimini ceasing operations is not zero, but it's comparable to any established public company — and far lower than Oracle's messaging implies. Spinnaker Support is privately held with a seventeen-year track record. Smaller specialist providers carry higher viability risk, particularly those with fewer than five years of operating history or a narrow client base.
The risk increases if your third-party provider is acquired — not because the acquirer will necessarily degrade service, but because acquisition can trigger contract changes, pricing adjustments, and service model transitions that disrupt your support coverage. The Broadcom/VMware acquisition demonstrated how dramatically a vendor change can affect support customers, and the same dynamic could theoretically apply to a third-party Oracle support provider acquisition.
Mitigation Strategy
Negotiate contractual protections: source code and tool escrow provisions that guarantee access to the provider's proprietary security tools and patch libraries if they cease operations, termination assistance clauses requiring the provider to support your transition back to Oracle or to another provider for 6–12 months after contract termination, change-of-control clauses that give you early termination rights if the provider is acquired, and SLA guarantees with financial penalties that give you exit leverage if service quality deteriorates. Additionally, maintain your Oracle licensing in good standing (keep your perpetual licences, even without active support) so that the option to return to Oracle exists — however expensive — as a backstop. See our third-party support negotiation guide for the complete contractual framework.
6. Risk 5: Oracle's Commercial Retaliation
Risk level: MEDIUM to HIGH — depends on the size of the support reduction and the Oracle relationship.
This is the risk Oracle will never openly acknowledge and the one that most directly affects your organisation's IT operating environment. When you reduce Oracle support significantly, Oracle responds. Not through formal retaliation (which would be contractually and legally indefensible) but through a set of commercial behaviours that are individually subtle and collectively punitive.
What Actually Happens
Audit escalation: Organisations that reduce Oracle support are disproportionately likely to receive audit notifications in the 6–18 months following the reduction. Oracle's audit right exists in your Master Agreement regardless of your support status, and an audit timed to coincide with a third-party support transition can create significant disruption — both operationally (managing an audit and a support transition simultaneously is extremely demanding) and financially (audit findings that would have been resolved through the Oracle relationship now require separate remediation without the goodwill that comes from being a loyal support customer). For a full analysis of audit triggers, see our article on Oracle audit risk assessment.
Reduced commercial flexibility: Oracle's account team may become less willing to offer discounts, accommodate exceptions, or extend contractual courtesies for the products that remain on Oracle support. The "partnership" dynamic shifts to a transactional one. This doesn't cost you money directly — but it reduces your negotiating leverage in future Oracle interactions.
Cloud migration friction: If you're simultaneously migrating to Oracle Cloud while reducing on-premise support, expect Oracle's cloud sales team to use the support reduction as leverage in cloud negotiations. Cloud incentive programmes like Support Rewards require active Oracle support — reducing support disqualifies the corresponding products from the programme, potentially reducing your cloud discount.
Mitigation Strategy
The single most important mitigation: ensure your licence compliance is clean before you reduce support. Oracle's primary retaliation mechanism is the audit. A clean compliance position renders the audit toothless — it produces no findings, generates no revenue for Oracle, and removes the most potent weapon from Oracle's retention arsenal. Conduct a comprehensive internal compliance assessment as the first step of any third-party support evaluation. Fix every gap before Oracle has an opportunity to discover it. The $50,000–$100,000 cost of the internal assessment is insurance against a $2–$10 million audit finding that Oracle would be highly motivated to pursue. See our Oracle Audit Defence Services for support.
7. Risk 6: Regulatory and Compliance Exposure
Risk level: HIGH in specific regulated industries. LOW in most commercial sectors.
Some regulatory frameworks impose requirements that may be difficult to satisfy without vendor-issued security patches. This is a genuine risk — but it's narrower than Oracle's messaging suggests and it's highly dependent on how the relevant regulations are interpreted by your specific auditors.
Where the Risk Is Real
PCI-DSS: The Payment Card Industry Data Security Standard requires "vendor-supplied security patches" for systems that store, process, or transmit cardholder data. Whether third-party virtual patching satisfies this requirement depends on your QSA's interpretation. Some QSAs accept virtual patching as a compensating control; others insist on vendor-issued patches. If your Oracle Database stores cardholder data and your QSA requires vendor patches, leaving Oracle support on that database creates a compliance gap.
FedRAMP / Government mandates: US federal government systems subject to FedRAMP or FISMA may require vendor-issued patches as part of their security control baseline. Again, compensating controls (virtual patching) may be acceptable, but the burden of proof falls on the organisation to demonstrate equivalence.
SOX and financial reporting: Sarbanes-Oxley does not explicitly require vendor-issued patches, but SOX auditors may question whether a system processing financial data without vendor security patches meets the IT general controls requirements. The risk here is audit friction rather than actual non-compliance.
Where the Risk Is Manufactured
For the vast majority of commercial organisations outside highly regulated industries, no regulatory framework mandates Oracle-issued patches specifically. GDPR, HIPAA, ISO 27001, and most industry frameworks require "appropriate security measures" — a standard that can be met through a combination of virtual patching, network segmentation, access controls, and monitoring. Third-party support providers deliver these measures as part of their standard service. The risk is not that you'll be non-compliant — it's that you need to document your security posture more thoroughly to demonstrate equivalence to auditors who may be unfamiliar with the third-party support model.
Mitigation Strategy
Map every Oracle product against the regulatory frameworks that govern it. Identify products where a specific regulation requires vendor-issued patches — retain Oracle support on those products. For everything else, document your compensating controls (virtual patching, network architecture, access management) and prepare a brief for your auditors explaining how third-party support addresses the security control requirements. This documentation exercise costs days, not months — and it eliminates the compliance risk entirely.
8. Risk 7: Technical Coverage Gaps
Risk level: MEDIUM for complex environments. LOW for standard deployments.
Third-party support engineers, while generally excellent, are not Oracle product engineers. There are specific technical scenarios where Oracle's support infrastructure has capabilities that no third-party provider can replicate.
Bug Escalation to Oracle Engineering
When Oracle Premier Support encounters a bug in Oracle software, they can escalate to Oracle's product engineering team for a code fix — a bug patch specific to your issue. Third-party providers cannot do this. They can provide workarounds, configuration changes, and compensating solutions, but they cannot fix bugs in Oracle's proprietary code. For most organisations, this is a theoretical rather than practical risk: bug escalations to Oracle Engineering are rare (most issues are resolved through existing patches or configuration), and the bugs that require engineering escalation are typically edge cases in complex, non-standard configurations.
New Platform Certification
If you need to migrate your Oracle software to a new operating system version, a new hardware platform, or a new cloud infrastructure type, Oracle's support provides platform certification — confirmation that the Oracle software is tested and supported on the target platform. Without Oracle support, you lose this safety net. The risk is highest during infrastructure refresh cycles (e.g., migrating from RHEL 8 to RHEL 9) and cloud migrations where platform compatibility is not yet established.
Complex Interoperability Issues
For Oracle Middleware products that integrate with multiple systems (WebLogic, SOA Suite, Integration Hub), third-party providers may have less depth in diagnosing interoperability issues between Oracle products and third-party systems. Oracle's support has access to internal documentation, cross-product debugging tools, and multi-product engineering teams that third-party providers cannot replicate. For organisations running complex middleware integration architectures, this coverage gap can be material.
Mitigation Strategy
Retain Oracle support on products where these technical risks are material: actively upgraded databases, complex middleware integration layers, and any product scheduled for a platform migration. Move to third-party support products running stable configurations on established platforms with no planned changes. The mitigation for technical coverage gaps is the same as for every other risk in this article: precision in product selection.
9. The Four Manufactured Fears (and Why They Don't Hold Up)
Having examined the genuine risks, we now address the fears Oracle propagates that are either false, dramatically exaggerated, or technically true but practically irrelevant. Understanding these manufactured fears is essential because they are the primary mechanism through which Oracle prevents customers from making rational cost-benefit evaluations. For a primer on Oracle's broader persuasion playbook, see our article on dealing with Oracle sales tactics.
Manufactured Fear 1: "Third-Party Support Is Illegal"
Status: False. Third-party Oracle support is legal. Period. Oracle's decade-long litigation against Rimini Street — which reached the US Supreme Court — established clear legal boundaries but did not prohibit third-party support as a service model. The court rulings addressed specific practices (software copying for patch development), not the fundamental right of customers to choose alternative support providers. Any Oracle representative suggesting otherwise is either uninformed or deliberately misleading.
Manufactured Fear 2: "Your Licences Will Be Revoked"
Status: False. Oracle perpetual licences are perpetual. They do not expire when you terminate support. They are not conditional on maintaining an Oracle support contract. Your Master Agreement and Ordering Documents grant you a perpetual right to use the software you've purchased. Dropping support ends your access to patches, updates, and Oracle's support services — but your licence to run the software remains intact. Oracle has never revoked a perpetual licence for non-payment of support, and no contract clause gives them the right to do so.
Manufactured Fear 3: "You'll Be Immediately Vulnerable to Cyberattack"
Status: Exaggerated. Your Oracle software's security posture does not change the day you leave Oracle support. The vulnerabilities that exist today existed yesterday, while you were still on Oracle support. What changes is your access to future patches for future vulnerabilities. This is a legitimate risk (addressed in detail in Section 2) — but Oracle's presentation of it as an immediate, catastrophic exposure is misleading. Your existing patches remain applied. Your existing security controls remain in place. Your third-party provider's security advisory and virtual patching services begin immediately. The transition is not from "secure" to "vulnerable" — it's from one patching methodology to another.
Manufactured Fear 4: "No One Comes Back from Third-Party Support"
Status: Misleading. Oracle implies that leaving for third-party support is a permanent exile. In reality, returning to Oracle support is always possible — it's just expensive (reinstatement penalty). Oracle will happily take you back because reinstatement generates significant revenue. The fear should not be "can I come back?" but rather "can I afford to come back?" — which is a financial calculation, not an existential one. And as noted in Section 4, the reinstatement penalty is negotiable in many circumstances.
| Fear | Oracle's Claim | Reality | Risk Level |
|---|---|---|---|
| "It's illegal" | Third-party support violates IP rights | Supreme Court confirmed legality; boundaries clarified, not prohibited | Zero |
| "Licences revoked" | Dropping support loses your licence | Perpetual licences are unconditional; contract confirms | Zero |
| "Immediate vulnerability" | Unpatched = compromised | Existing patches remain; virtual patching begins day one | Low–Medium (varies) |
| "No way back" | Leaving is permanent | Reinstatement always available — expensive, but negotiable | Financial, not technical |
10. The Product-Level Risk Matrix
The culmination of this analysis is a product-level risk matrix that maps every major Oracle product category against the seven genuine risks identified in this article. Use this matrix to guide your product-by-product evaluation — but always calibrate it against your specific deployment characteristics. For the complete transition methodology, see our CIO's guide to transitioning to third-party support.
| Product Category | Security Gap | Version Lock | Reinstatement | Provider Risk | Retaliation | Compliance | Technical Gap | Overall Risk |
|---|---|---|---|---|---|---|---|---|
| Oracle DB EE (active patching) | HIGH | HIGH | HIGH | LOW | HIGH | HIGH | MEDIUM | HIGH — Retain Oracle |
| Oracle DB EE (stable, 19c) | MEDIUM | LOW | MEDIUM | LOW | MEDIUM | MEDIUM | LOW | MEDIUM — Candidate for TPS |
| Oracle DB SE2 | LOW | LOW | LOW | LOW | LOW | LOW | LOW | LOW — Strong TPS candidate |
| PeopleSoft | LOW | LOW | LOW | LOW | MEDIUM | LOW | LOW | LOW — Strong TPS candidate |
| E-Business Suite | LOW | LOW | MEDIUM | LOW | MEDIUM | LOW | LOW | LOW — Strong TPS candidate |
| Siebel CRM | LOW | LOW | LOW | LOW | LOW | LOW | LOW | LOW — Strong TPS candidate |
| JD Edwards | LOW | LOW | LOW | LOW | LOW | LOW | LOW | LOW — Strong TPS candidate |
| Middleware (WebLogic, SOA) | MEDIUM | LOW | MEDIUM | LOW | MEDIUM | LOW | MEDIUM | MEDIUM — Evaluate carefully |
| Hyperion / Analytics | LOW | LOW | LOW | LOW | LOW | LOW | LOW | LOW — Strong TPS candidate |
| Database Options (unused) | N/A | N/A | N/A | N/A | LOW | N/A | N/A | ZERO — Terminate support |
The matrix tells a clear story: the Oracle estate is not monolithic. Some products carry genuine, material risk if moved to third-party support. Most don't. The financial opportunity lies in treating each product individually and moving the 60–70% of your estate that falls in the "LOW" risk category — while retaining Oracle support on the genuinely high-risk 20–30%. The remaining 10–15% is shelfware that should have its support terminated entirely. For hybrid strategy examples in action, see our case studies on Adecco (€12M saved), Technip Energies (€12M saved), and Telefónica (€40M saved).
11. Frequently Asked Questions
The reinstatement trap — not because it's the most likely to occur, but because its financial consequences are the most severe and the most difficult to reverse. The security patching gap is a bigger operational risk for specific products, but it can be mitigated through virtual patching and compensating controls. The reinstatement penalty cannot be mitigated — only avoided through careful product selection. Move only products where you have high confidence you will never need to return to Oracle support. For everything else, retain Oracle. The reinstatement penalty turns a recoverable decision into a potentially irreversible one, and that asymmetry demands the highest standard of analysis before committing.
There is no publicly documented case of a major security breach directly attributable to an organisation's decision to use third-party Oracle support instead of Oracle Premier Support. This doesn't mean the risk is zero — it means the risk is not as catastrophic as Oracle's marketing suggests. The overwhelming majority of Oracle security breaches are caused by misconfigured systems, unpatched known vulnerabilities (that went unpatched even with Oracle support), weak access controls, and human error — not by the absence of Oracle's specific patching mechanism. A well-secured Oracle environment with third-party virtual patching, proper network segmentation, and competent administration is more secure than a poorly managed environment with Oracle Premier Support.
Your licence compliance obligations don't change when you leave Oracle support — you must still comply with your Oracle licensing agreements regardless of your support status. However, Oracle may be more motivated to audit you after a support reduction, and an audit without an active support relationship removes some of the informal goodwill that can facilitate settlement negotiations. The most important mitigation: ensure your compliance position is pristine before reducing support. Conduct a thorough internal compliance assessment, remediate all gaps, and document your compliance position. A clean estate gives Oracle nothing to find — regardless of how motivated they are to look.
Request specific documentation from each provider: their CVE response process (how quickly they assess and address newly disclosed Oracle vulnerabilities), their patch delivery methodology (virtual patching, binary patching, or advisory-only), their historical response time for critical CVEs (ask for specific examples from the past 12 months), and independent security assessments or certifications they hold. Ask for reference clients in your industry who can speak to the security experience. Map their capabilities against your specific security requirements — if you're PCI-DSS scoped, ask specifically how they support PCI compliance for Oracle environments. A provider who can't answer these questions with specificity is not ready to support your Oracle security needs.
For any organisation with annual Oracle support exceeding $1M, independent advisory support adds significant value to the risk assessment — precisely because the assessment requires objectivity that neither Oracle nor third-party support providers can provide. Oracle will overstate every risk to keep you paying. Third-party providers will understate every risk to win your business. An independent advisor quantifies each risk for your specific estate, without a commercial interest in the outcome. At Redress Compliance, we've advised organisations that ultimately stayed with Oracle, organisations that moved entirely to third-party, and everything in between. Our transition advisory service includes a product-level risk assessment that maps directly to the framework in this article. Visit our Oracle Knowledge Hub for additional resources, or contact us through our Oracle Advisory Services page.