Oracle's support contracts do not cover customized code — full stop. The nuances matter: Oracle will support the base product, but when a problem occurs in or near your customization layer, the standard Oracle support response is to reproduce the issue on an uncustomised environment. For enterprises that have spent years building proprietary modifications into Oracle E-Business Suite, PeopleSoft, or JD Edwards, this limitation has direct implications for support value, third-party support decisions, and upgrade planning.
Oracle's Software Technical Support Policies document — the governing terms for Oracle support coverage — explicitly excludes support for modifications, alterations, or customisations made to Oracle software. The core provision states that Oracle's support obligation extends to Oracle's delivered software as of the product release; it does not extend to changes made by the customer, the customer's implementation partner, or any third party after the software is delivered.
This is not a minor footnote. For the majority of Oracle enterprise application deployments — E-Business Suite, PeopleSoft, JD Edwards, and Siebel — some degree of customization is the norm rather than the exception. Oracle Applications implementations rarely operate on entirely standard, uncustomised code. When Oracle's standard support limitation intersects with a heavily customized production environment, the result is a support model that provides substantially less value than the 22% annual maintenance fee suggests.
Understanding exactly where Oracle draws the line — and where there is grey area — is essential for any honest Oracle support value analysis. Our support cost reduction service includes a detailed review of what your Oracle support fee is actually buying relative to your specific implementation profile.
Not affiliated with Oracle Corporation. This analysis is based on our team's direct experience advising enterprise buyers through Oracle support escalations, SR disputes, and third-party support transitions. Oracle's specific support policies are governed by your Oracle Master Agreement and the applicable Software Technical Support Policies document.
For customized environments, Oracle's support commitment covers the base product — the Oracle-delivered software as documented and released. This means: bug fixes and error corrections for defects in the standard Oracle code; security patches (Critical Patch Updates) for the base product; platform certifications for the Oracle-delivered product version; and access to My Oracle Support knowledge base articles and documentation for the standard product.
In practice, Oracle support engineers will assist with customized environments in two specific ways. First, they will try to isolate whether a reported issue is caused by Oracle's standard code or by the customization. If the issue is in Oracle's code (reproduces on a standard, uncustomised installation), Oracle will treat it as a supportable SR and work toward a fix. Second, Oracle will provide guidance — not a fix — for how standard Oracle functionality works and how customisations should interact with it, so that the customer's development team can fix their custom code.
What this means in practice: if your EBS implementation includes custom workflow code that breaks after an Oracle-provided patch is applied, Oracle's support response will be to confirm that the base Oracle code works correctly after the patch, and to direct you to update your custom workflow code to work with the new Oracle version. Oracle will not modify your custom code or fix the integration between your customization and the Oracle patch.
Oracle's Software Technical Support Policies explicitly exclude from support coverage: modifications to Oracle's source code; customer-created code that integrates with Oracle software (custom APIs, custom reports, custom workflows, custom PL/SQL packages); third-party software integrations; software that has been altered from Oracle's delivered version; and issues that cannot be reproduced on a standard, unmodified Oracle installation.
The exclusion for issues that cannot be reproduced on standard code is particularly significant. When an Oracle support engineer asks you to reproduce an issue on a "vanilla" instance (an unmodified Oracle installation), they are applying this policy. If the issue only occurs in your customized environment and cannot be reproduced in a standard Oracle environment, Oracle is entitled to close the SR as outside scope. This is a legitimate and documented policy — it is not Oracle being obstinate. But it creates a genuine support gap for heavily customized implementations.
| Area | Oracle Support Coverage | Customer Responsibility |
|---|---|---|
| Standard Oracle code defects | Full — bug fix, patch | Apply Oracle-provided patch |
| Security vulnerabilities (CPU) | Full — quarterly CPU | Apply CPU; test in custom env |
| Custom PL/SQL / stored procedures | Not covered | Customer development team |
| Custom EBS extensions (Forms, Reports) | Not covered | Customer / SI partner |
| Integration issues (custom APIs) | Not covered | Customer development team |
| Post-patch custom code failures | Oracle confirms patch is correct; no custom fix | Customer must remediate custom code |
| Third-party software integrations | Not covered | Customer / vendor |
| Performance issues in custom code | Not covered | Customer DBA / development team |
Our support cost reduction service maps your specific customization profile against Oracle's coverage to quantify what you're actually getting for the 22% annual fee — and whether third-party support or a different model delivers better value.
Oracle E-Business Suite (EBS) is the Oracle application most likely to have substantial customisations. EBS implementations that have been running for 10-15 years typically contain hundreds of custom objects: custom Oracle Forms, custom Oracle Reports (RDF), custom PL/SQL packages, custom concurrent programs, custom workflow definitions, custom Integration with external systems through custom APIs, and custom extensions built using the Oracle Applications Framework (OAF) or Oracle Forms Personalisation.
Oracle's support coverage for EBS distinguishes between "customisations" and "configurations." Configurations — changes made using Oracle's delivered configuration tools (EBS system parameters, profile options, responsibilities, flexfields within documented limits) — are generally supportable. Customisations — changes made to Oracle's delivered code or new code objects created outside Oracle's configuration framework — are not supported by Oracle.
The patching problem for customized EBS is substantial. Every Oracle CPU and Bundle Patch for EBS requires testing against the customized environment. Custom Oracle Forms files may conflict with Oracle-supplied patch content. Custom PL/SQL packages may need to be re-applied after each patch cycle. Custom concurrent program definitions may need to be rebuilt after patch-delivered changes to base Oracle tables. This patch testing and remediation burden falls entirely on the customer — Oracle support will not assist with it beyond confirming that the Oracle-delivered patch content is correct.
This is one of the primary reasons enterprises with heavily customized EBS environments consider third-party support: third-party providers like Rimini Street will support customized environments as part of their standard service model — developing tax and regulatory updates that account for the customer's specific customization layer, rather than delivering generic patches that require significant customer re-testing.
PeopleSoft and JD Edwards EnterpriseOne are both designed with customization frameworks — PeopleSoft's Application Designer, PeopleCode customization layers, and PeopleTools; JD Edwards's Orchestrator Framework, Business Functions, and ER (Event Rules) customization layer. These frameworks are designed to allow customization while theoretically maintaining upgrade compatibility — Oracle's argument is that using the documented customization frameworks reduces customization risk.
In practice, even customisations built within Oracle's documented frameworks create support grey areas. Oracle's support commitment covers the framework itself (PeopleTools, JD Edwards Orchestrator) but not custom code built within the framework. If a PeopleCode customization fails after a PeopleTools upgrade, Oracle will confirm that PeopleTools is functioning correctly and direct the customer to review their custom PeopleCode. If a JD Edwards business function fails after an ESU (Electronic Software Update) is applied, Oracle's position is to confirm the base functionality and direct the customer to re-test their custom business functions.
For PeopleSoft specifically, Oracle has extended Premier Support for 9.2 through December 2032 — a long runway. The extended support commitment creates a question for PeopleSoft customers: with 6+ years of Premier Support ahead, does the support model justify Oracle's 22% annual fee for a heavily customized implementation? For implementations with extensive customisations that Oracle won't fix, the answer deserves forensic analysis through our compliance review and support value assessment.
Oracle Database deployments present a different customization profile than Oracle Applications. Database "customisations" typically consist of: customer-created PL/SQL stored procedures, functions, and packages stored in Oracle Database schemas; custom database triggers; custom database jobs; custom database links; and custom views and materialized views built on Oracle system tables.
Oracle's support coverage for Oracle Database does not extend to customer-created database objects. If a customer-created PL/SQL package fails after an Oracle Database patch is applied, Oracle support will confirm the patch was applied correctly and that Oracle's own database code is functioning as documented. The customer is responsible for maintaining and remediating custom database objects. Oracle does not provide debugging assistance for customer PL/SQL code as part of standard support.
There is a grey area for issues that appear to be Oracle database bugs but manifest in the context of customer code. Oracle DBA support engineers will often assist with identifying whether Oracle is behaving according to its documented behavior — this is part of Oracle's "usage" support commitment, which covers helping customers use Oracle software correctly. If Oracle's behavior is a genuine defect (not matching Oracle's documentation), Oracle will log a bug. But if Oracle is behaving as documented and the customer's code is not handling that behavior correctly, Oracle's support obligation ends at "Oracle is working correctly."
For enterprise Oracle buyers, the customization support limitation has a direct implication for Oracle support value analysis. The honest question is: given that Oracle won't support your custom code, what are you actually getting for the 22% annual maintenance fee? The answer varies by implementation profile.
For enterprises running Oracle Database at scale with relatively standard configurations, Oracle's support is valuable: security patches, bug fixes, and platform certifications cover the vast majority of support needs. For enterprises running heavily customized Oracle EBS with hundreds of custom objects, where most production issues involve custom code and Oracle's SR responses are predominantly "we can see the base Oracle code is working correctly," the value delivered by Oracle support is substantially less than the headline 22% fee suggests.
Our support cost reduction analysis quantifies this gap by reviewing SR history, customization volume, and patch frequency against the annual Oracle support cost. Enterprises with high customization density and relatively few SR resolutions from Oracle are the strongest candidates for third-party support evaluation.
The customization support limitation is one of the primary commercial arguments for third-party Oracle support. Providers like Rimini Street and Spinnaker Support explicitly include support for customized environments in their standard service offering — something Oracle does not do. Third-party support providers will: review and support customer-created PL/SQL code; develop and test security fixes against the customer's specific customized environment (rather than a generic Oracle base release); and provide interoperability support that accounts for the customer's specific customization layer.
For enterprises with heavily customized Oracle applications, third-party support may provide more practical support for the actual production environment than Oracle's own support — at 50% of Oracle's annual maintenance fee. The support reduction analysis we provide compares the specific support coverage delivered by Oracle versus third-party providers for the customer's actual environment profile.
The case studies demonstrate this pattern consistently. A heavily customized EBS 12.2 environment with 300+ custom objects typically receives the majority of its practical support from the internal Oracle team and implementation partner, not from Oracle's MOS SR process. The annual Oracle support fee, in that context, is primarily purchasing security patches and the option to engage Oracle on base product issues — a coverage set that may be achievable at lower cost through third-party support combined with strategic investment in internal capability.
Includes the customization support gap analysis framework, third-party support comparison matrix, and negotiation tactics for challenging Oracle's 22% annual maintenance fee for customized environments.
Download Free →Support policy changes, third-party support developments, and negotiation insights — delivered monthly to enterprise Oracle stakeholders.