The Latest Oracle E-Business Suite Technology News direct from
Oracle E-Business Suite Development & Product Management

To Customize or Not to Customize?

Steven Chan
Senior Director
Any customer can have a car painted any colour that he wants so long as it is black.
~ Henry Ford
Ford's now-famous words seem a little quaint today.  We live in the Golden Age of the Consumer, where virtually everything can be customized or personalized in some way.  If you can customize mass-produced consumer goods, it seems reasonable to expect that you should be able to customize something as strategic and mission-critical as an enterprise resource planning system, too.  But just because you can, does this mean that you should? Personalizations are Persistent The E-Business Suite has acquired increasingly-powerful personalization features over the years.  These features allow you to personalize existing EBS screens with your own branding, corporate logos, colour schemes, field names, explanatory messages, and more.  My fellow blog authors have previously written about personalization options here (for Forms personalization) and here (for OA Framework personalization).  These types of personalizations are metadata-driven, which means that they are preserved and work even when the underlying screens are updated by EBS product teams via new patches.  This is the primary benefit of using the standard Apps personalization features: your changes are persistent and will continue to work even if the underlying screens are patched at a later date.  Going Beyond Personalizations You might have a unique service offering, product, or business process.  You might need to capture or manage information about your business, products, or customers in a way that differs markedly from the way the E-Business Suite's designers originally intended.  From a system administrator's perspective, you might need to deploy the E-Business Suite in an architecture, topology, or system configuration that aren't supported via AutoConfig yet.  The E-Business Suite's personalization features, while useful, may not be sufficient to meet these types of specialized requirements.  At this point of your analysis, it will be useful to consider the advantages, disadvantages, and implications of customizing your the E-Business Suite in an invasive way. There are many ways of customizing or extending your EBS environment.  These include:
  • New business rules or data transformations
  • New or custom screens
  • Integrations with external systems
  • Use of third-party utilities or extensions
  • Creation of new reports
  • Creation of new workflows
  • Integrations with standalone APEX applications
All of these customizations need to be considered in terms of their invasiveness.  The more invasive the change, the greater the long-term implications. Advantages of Customizations
  1. Functionality meets your requirements more closely
Disadvantages of Customizations
  1. More costly than deploying a "plain vanilla" solution
  2. Requires specialized development skills
  3. May require updates, testing, and maintenance whenever:
    • New EBS patches are released
    • New architectures are deployed
    • New technology certifications are released
  4. Increases support complexity and overhead
  5. Can potentially complicate upgrades to new EBS releases
Understanding the Implications of Customizations As regular readers of this blog know, we frequently release new technology stack patches, certifications, architectures, and systems management features.  Apps product families (e.g. Financials, Supply Chain, Human Resources, etc.) aren't standing still, either.  They're constantly updating their products with new features and enhancements, too. Let's assume that you have the resources to address the first two potential issues of increased cost and skills.  What remains are the implications of keeping up with your friendly developers at Oracle:  
Testing Implications I've spoken with a number of customers who tell me that their customizations have prevented them from applying the latest ATG Rollup or upgrading to the latest database release.  They might have had staff to perform the original customizations years ago, but they no longer have the capacity to regression test their environments with new patches or technology stack components.  In some cases, formal development records detailing the customizations have been lost, making it extremely difficult to perform any impact analyses or tests.  These customers can't go forward, and they can't undo their customizations, either.  These customers are stuck. If you've customized your E-Business Suite environment in some way, you need to ensure that every new certification, patch, or newly-supported architectures work in your customized environment.  Depending upon what you're considering introducing into your environment, you may need to perform functional tests, performance benchmarks, scalability testing, and even security reviews.  If you're thinking of customizations, it is extremely important not to underestimate the costs of maintaining and testing them. Support Implications If I were an IT manager considering customizing the E-Business Suite, the primary factor affecting my decision would be the support implications.  Oracle certifies and supports generic E-Business Suite environments.  If you invasively customize your system in some way, you should understand and plan for the fact that Oracle can only provide patches for issues that can be reproduced in uncustomized, "plain vanilla" E-Business Suite environments. Customers who can succinctly describe their customizations when logging Service Requests with Oracle Support will have a distinct advantage over those customers who wait for Oracle Support to stumble over a customization.  Upgrade Implications Premier Support for E-Business Suite Release 11i ends in November, 2010.  At OpenWorld this year, it was abundantly clear that many of you are planning your upgrades to E-Business Suite Release 12 now.  If you've customized your Apps 11i environment in some way, your Apps 12 upgrade plan needs to consider whether those customizations are still needed.  Given the many new features in EBS 12, it's entirely possible that your customizations may now be redundant or obsolete.  One major Apps 11i customer with several thousand customizations observed that at least half of those were already built directly into R12, obviating the need for forward-porting.
Tipping the Scales I've had the pleasure of working with countless EBS customers over the years.  My impressions are that systems administrators with uncustomized Apps environments are generally more-receptive to keeping up with the latest patches, are more willing to consider upgrades and trying new technologies.  This makes a lot of intuitive sense. As a battle-scarred Oracle developer, I would venture that very few customers can justify the extremely-high costs and long-term systems management implications that come along with invasive customizations.  That said, every customer has their own business case for customizations.  Your mileage will vary.  Everyone going through this analysis will have their own factor weightings, costs, and benefits of customizing their EBS environments. I'd be interested in hearing your war stories about customizations, both good and bad.  Feel free to share them in a comment or by dropping me a line.  Related Articles

Join the discussion

Comments ( 32 )
  • David Weber Wednesday, November 11, 2009

    Hi Steven, thanks for your great blog entries, it's always very helpful what you and your colleagues post here.

    Regarding customizations: agree with you from the technical perspective that customizations are increasing complexity and bring a lot of risks and costs and additional work.

    However I think you forget the functional perspective here: it's not that we create customizations because we like them, it's because the features that we need are not available in the standard software.

    In our system we made a couple of customizations and till now we did not face major issues with customizations when it comes to patching/upgrading. So I think it's more important to have certain guides and rules for implementing customizations. If you follow those recommendations you are not 100% safe but at least can avoid many conflict situations.

    Next to that personally I always differentiate in my developments between "extensions" and "customizations". The extensions offer additional functionality on top of the standard functionality, and worst case that should happen after patching/upgrading is that the extension does not work anymore, but the standard functionality is still guaranteed. A customization is for me then really changing standard behavior.

    So besides of looking at it from a technical or admin perspective I would love to see an article focusing on development. We know the Developers Guide, but it's a heavy book... a short overview of the most important "DOs and DONTs" for customizations would be nice. But I guess creating such a list is not an easy task.

    Thanks, David.

  • Balasubramanian Thursday, November 12, 2009

    Dear Steven,

    Is there any guidelines/ framework methodology in particular in the form of Templates which will be helpful for clients like Military Hospitals, when they go for Oracle EBS R12 Implementation from prior legacy systems.

    Best Regards,


    ERP Systems Analyst-Oracle EBS R12

  • Gaby Thursday, November 12, 2009


    Great article and as you stated, how many miles is your leash is the question. Organization, often view IT as a silver bullet and instead of taking a hard look at their business processes will prefer to customize or extend the e-business suite. Much easier to have our development staff create a new form instead of mapping our processes to the out of the box form or report!

    Well… once you reach the end of your leash and your IT department realizes all they are doing is supporting those customizations is when the real discussions start happening. At least this is how we got there at my organization. Spending 10 developers’ time to upgrade from 11.03 to 11i meant stopping any new development for the organization for over a year. Now release 12 is knocking on the door and this will imply seriously looking at decommissioning customizations and extensions. Now the organization gets it, feels it and they hopefully understand the cost of customizing and extending the e-business suite.


  • Steven Chan Thursday, November 12, 2009

    Dear Balasubramanian,

    I'm not personally familiar with any such templates, but that doesn't mean much. I'm in Development, not Consulting, so I don't have a lot of visibility into the scope of our "EBS Accelerators," which are created for various vertical industries and uses.

    If you'd like, I can pass your email on to someone in our Oracle Consulting group on your behalf; they can look into this for you. Let me know if you'd like someone to contact you about that.



  • Steven Chan Thursday, November 12, 2009

    Hi, David,

    I fully agree with you: indeed, there are features that some customers consider mission-critical that aren't built into the E-Business Suite.

    I also agree that there's an important distinction between "extensions" and "customizations," but this is a pretty subtle one that's often lost on developers who are new to the E-Business Suite. I would consider custom code that's loosely-coupled with the E-Business Suite to be an extension, but an invasive change to code or screens provided by Oracle Development to be a customization.

    Building extensions according to the guidelines laid out in the Developer's Guide is a bit of an art, naturally. I think your suggestion of having a short overview of the key principles is a good one. I've passed it on to our Applications Technology Group, the group that owns that guide. This is the perfect kind of material for either a whitepaper, a conference session, or even a web-based seminar.



  • Steven Chan Thursday, November 12, 2009

    Hi, Gaby,

    "How many miles is your leash?" is a great way of putting things.

    Back when I was a management consultant, I often preached that using specialized IT systems that supported unique business processes was a way of creating competitive differentiation.

    But that's really only true for very unique, customer-facing business processes. Generic business activities that are focussed on internal processes, as opposed to things that affect a company's customers, are largely irrelevant to the competitive equation. After all, how much competitive advantage does a new way of, say, entering internal expense reports confer on a business? Not much, I'd suggest.

    Your experience is very similar to that of many customers, and your yearlong 11.0.3 to 11i upgrade experience is really sobering reading. I hope that your R12 upgrade is much simpler and faster!



  • Greg Frost Monday, November 16, 2009

    Hi Steven

    Great blog - thanks!

    As somebody who has implemented at various sites for a decade, I'm in general agreement with you.

    I've one suggestion for Oracle products though - it would be great to have a tool for web apps which allow non technical people to easily add business logic to the app.

    Forms Personalization is excellent with this, but there really isn't a smart / easy tool available otherwise which allows you to say "if you're a male, you're not allow to fill in this information" etc.

    I reckon that a usable solution to this, modeled on the Forms Personalization approach, would limit hundreds of "customizations" and associated audit reports etc etc.

    And when you think about the basic needs of an application (inserting and maintaining data & then turning it into information), that would probably be half the battle won!


  • Steven Chan Tuesday, November 17, 2009

    Hi, Greg,

    That's an interesting suggestion. I think that being able to declaratively define business logic would be very useful. Building such a thing... well, that might take some time. I'd suspect that the end-product would likely resemble our development tools like JDeveloper so closely that it might be a wash.

    It never hurts to ask, though, so I've passed on your suggestion to our Applications Technology Group for their review.



  • Rajkishore Wednesday, November 18, 2009

    Hi steven,

    nice blog. It's always pleasure to read thruogh your blog. We get lot of good info to start with. In my experience we have done lot of customisatons and I don't think there is any 1 company in this world without customisations.

    I have one suggestion related to patching or upgrade process. Is it possible to notify the dbas if the patch they are applying is overwriting any file that is customised? If there is something like that then atleast we get know what might fail after applying the patch. I have seen cases where we applied patch and then realised some of the customisations are gone after testing.



  • Steven Chan Thursday, November 19, 2009

    Hi, Raj,

    Yes, you can flag specific files that you've customized and have warnings generated if AutoPatch is about to replace them. The method varies by EBS release. In Apps 12, for example, check out the "Registered Flagged Files" functionality in this manual:

    Oracle Applications Patching Procedures -


    There's a really nice web-based module within the R12 Oracle Application Manager that allows you to register your customized files.



  • Sharon Thursday, November 26, 2009

    We're currently having difficulty understanding the term "customisation" - only that it's expensive in licensing terms! Is there anything anywhere that tells us in plain english what we can and can't change under the "runtime" licence?

  • Steven Chan Tuesday, December 1, 2009

    Hi, Sharon,

    From a lay perspective, the term "customization" usually applies to your changing any code delivered with the E-Business Suite, or using the product in a configuration that falls outside of our documented procedures.

    It's important to note that I am not a lawyer. I'm in EBS Development and am not privy to licencing contracts. I would assume that the term "customisation" is defined somewhere in those contracts, but am speculating on first principles only here. If you need an authoritative answer to this one, your Oracle account manager should be able to help parse through your existing contracts for a definitive clause.



  • Harry Thursday, December 3, 2009

    Steven, I am possibly going to be rewriting an entire page's HTML code; though without removing any of the functionality that the page provides. In other words none of the underlying functionality is changed, merely the HTML layer.

    How would i be affected by future patches?

    Many thanks, Harry

  • Steven Chan Thursday, December 3, 2009

    Hi, Harry,

    It's really hard to say, I'm afraid.

    I think this really depends upon whether your custom HTML code or page makes assumptions about the data that's coming from the underlying business logic. It's hard to make any broad generalizations or to give you assurances that you'll be unaffected.

    This is the fundamental challenge of distributed development. In this case, one team (Oracle) will be making changes to their code without taking into account any dependencies on that code except their own. They will test their code, but you're the only one who can determine whether their changes interfere with your own custom dependencies.





  • Krishnamoorthy Friday, August 12, 2011

    Hi Steven,

    Our PROD environment is highly customized and we are not sure about all the customizations.

    It is instance. Is there a way we can find what are all the customization that has been implemented??

    As we know before running autoconfig we need to preserve all the customization.



  • Steven Chan Friday, August 12, 2011

    Hello, Krishna,

    Our Consulting team offers a tool that can catalog most customizations in your EBS environment. For details about that tool, you should listen to the webcast, "Upgrading E-Business Suite 11i Customizations to R12" cross-referenced on this summary page:

    Summary of Oracle E-Business Suite Technology Webcasts and Training


    Good luck with your upgrade.



  • Shyam Patel Saturday, February 4, 2012

    Dear ALL,

    I am New in Apps Customization.I am using Oracle forms 10g. I am facing Following Error while trying to run test_form on My PC(OS:Win XP)

    FRM-40832: Variable FORMS_USEREXITS not set.User Exit FND did not execute

    Need guidance of yours!!!



  • Steven Chan Monday, February 6, 2012

    Hi, Shyam,

    I'm sorry to hear that you've encountered an issue with this.

    We can provide general conceptual guidance here, but I'm afraid that this blog isn't the best place to get technical support for specific issues like the one that you're working through.

    Your best bet would be to log a formal Service Request via My Oracle Support (formerly Metalink) to get one of our specialists engaged.

    Please feel free to forward your Service Request number to me if it gets stuck in the support process for some reason.



  • Shyam Tuesday, February 7, 2012

    Thanks Steven

  • guest Tuesday, May 8, 2012

    Hi Steven,

    I came across a word Rewrite Customizations When dealing with a customer for EBS Requirement so can you let me know what does it exactly means



  • Steven Chan Wednesday, May 30, 2012

    Hi, Manoj,

    I don't understand your question. If you're considering the impact of customizations on upgrades, this whitepaper might be useful:

    New Whitepaper: Upgrading your Customizations to Oracle E-Business Suite Release 12 (Oracle E-Business Suite Technology)




  • guest Wednesday, June 20, 2012

    Hi steven,

    Does normally oracle give source codes to customers so that they can customize it in any way they want?

  • Steven Chan Wednesday, June 20, 2012

    Hi, Guest,

    No, this isn't customary. If you'd like to discuss options for this, I'd recommend contacting your Oracle account manager.



  • Steven Touchant Friday, July 6, 2012


    What would be your approach regarding rather invasive customizations (e.g. APXINWKB.fmb version 115.891 was copied, customized and saved as XXAPXINWKB.fmb) in case an Oracle E-Business Suite patch is applied that delivers a higher version of the base objects (e.g. APXINWKB.fmb version 115.1073) and in case a major upgrade is performed (e.g. upgrade from to 12.1.3, which delivers for example APXINWKB.fmb 120.496.12000000.66)?

    Best regards,


  • Steven Chan Friday, July 6, 2012

    Hello, Steven,

    If you're upgrading from 11i to R12, your first task will be to determine whether your customizations are even needed any more. See:

    New Whitepaper: Upgrading your Customizations to Oracle E-Business Suite Release 12


    If you prefer a presentation format, the same whitepaper is summarized in the webcast linked at the bottom of that article.



  • Steven Friday, July 6, 2012


    Thanks for your swift reply.

    Let's suppose that I'm just applying an Oracle E-Business Suite patch that delivers a higher version of the base object. What would be your approach regarding the related rather invasive customization?

    And let's suppose that a rather invasive customization would still be required in R12. How would you upgrade that kind of customization from R11i to R12?

    Best regards,


  • Steven Chan Friday, July 6, 2012


    Speaking generally, you would need to revisit your invasive customization and ensure that you reapply it (or update it, as needed) to the new version of the base object. It will then be your responsibility to ensure that your customization doesn't introduce any regressions in standard E-Business Suite functionality.

    The same would apply to an EBS 12 upgrade. After you've upgraded your EBS environment from 11i to 12, you would need to reapply the customization (and you loop back to the start of this comment).

    Customizations are *EXPENSIVE*. You need to redo the work every time the base object changes, regardless of whether the changes are from patches or major upgrades.



  • Steven Monday, July 9, 2012


    Thanks for the clear answer. I fully agree that customizations are expensive, but it is often not obvious to elucidate that to all stakeholders involved.

    In a nutshell, taking my example of the Payables Invoice Workbench when upgrading from to 12.1.3, you would get APXINWKB.fmb version 120.496.12000000.66, redo the customization - which was done in XXAPXINWKB.fmb and which was based on APXINWKB.fmb version 115.891 - and perform thorough regression testing (rather than updating the existing equivalent of XXAPXINWKB.fmb, which was based on APXINWKB.fmb version 115.891, to make it work in 12.1.3). Correct?

    Best regards,


  • Steven Chan Monday, July 9, 2012


    Yes, that's correct. You should always redo and retest your customization based upon the very latest version of the base object available, for the EBS codeline upon which you wish your customization to run.

    There's little value in reworking your customization based upon whatever 11i-based package after APXINWKB.fmb version 115.891, since your target environment is on EBS 12. In other words, you should upgrade your environment to EBS 12 and then redo and retest all customizations on the EBS 12 equivalents.



  • guest Wednesday, November 11, 2015

    Surely the biggest consideration of customisation is that you will need to purchase technology licences as well as Apps licences. So Database, apps server and now with 12.2 SOA, WLS etc? Which can add hundreds of thousands to the purchase price?

  • Steven Chan Wednesday, November 11, 2015

    Hello, Guest,

    This is a technically-oriented blog from EBS Development, so we focus on technical topics.

    Agreed: different types of customizations to an EBS environment trigger different licensing requirements. We don't have any insight into licensing implications; those fall outside of our visibility and expertise.

    Customers with licensing questions would be best served by contacting their Oracle account manager for assistance.



  • Dharam Wednesday, February 3, 2016

    Brilliant Article Steve !

    Customization has it's nuances and has the potential to be redesigned/fixed every-time Oracle releases a new patch/release; I know cuz I have done tremendous amounts of patch analysis / impact analysis and have built processes around the same.

    But again, that boils down to the very fundamental question of Oracle eBusiness Suite's selling strategy vs SAP or other competitors which was Larry's prophecy which is

    "Oracle gives you the flexibility to customize which other ERP's don't"

    So, by avoiding customization and sticking to vanilla implementations how different are we from SAP or others (I do understand that Oracle provides better features in many modules)

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.