Introduction
No one gets excited about technical debt, but when your APEX instance is still on 18.2 (or earlier), its “interest clock” is already ticking.
Oracle offers full support for only 18 months per APEX release. Upgrading usually takes less time than your weekly sprint demo; yet, thousands of production apps still run on outdated versions.
Staying current isn’t just about running the latest APEX version. It’s about proactively addressing deprecated features and aligning Instance, Workspace, and Applications settings with the latest features.
This post will follow a case study of a client running on-premises APEX (18.2) who is migrating to an Autonomous Transaction Processing Database (ATP) instance running on Oracle Cloud Infrastructure (OCI).
Case Study
The client went live with their old system when APEX 18.2 came out in the fall of 2018 (seven years ago). Premier support for APEX 18.2 ran out at the end of March 2023 (two years ago). I thought, “Wow, this client has been running their APEX environment for seven years and has had virtually no maintenance costs.”
⚠
That is the blessing and the curse of APEX. It runs and runs with very little intervention, so you can fall into the trap of thinking you never need to upgrade it.
This section describes APEX remediations I discovered while assessing the client’s APEX 18.2 environment for upgrade to APEX 24.2.
Include Legacy JavaScript
➡
Navigation: Shared Components > User Interface > User Interface Attributes > Include Legacy JavaScript > Include Deprecated or Desupported JavaScript Functions
There are two checkboxes: ‘Pre 18.1’ and ‘18.x’. They tell APEX to load legacy JavaScript libraries found in /i/libraries/apex/legacy*.js. These incur unnecessary overhead and indicate that you are not taking good care of your APEX environment!
✅
Disable these options, perform a regression test, and remediate as necessary.
Include jQuery Migrate
➡
Navigation: Shared Components > User Interface > User Interface Attributes > Include Legacy JavaScript > Include jQuery Migrate
Similar to the previous option, this is a crutch for Apps using legacy jQuery code.
✅
Disable these options, run a regression test, and remediate as necessary.
Compatibility Mode
➡
Navigation: Shared Components > Application Definition > Definition > Compatibility Mode
Certain APEX runtime behaviors change from one release to the next. This option allows you to avoid the impact of these changes during an upgrade. The release notes list compatibility mode changes dating back to APEX 4.1.
✅
After an upgrade, set all apps to the latest compatibility mode and remediate them as necessary.
Upgrade Universal Theme
Not on the Universal Theme - Yikes!
In this use case, one of the apps did not use the Universal Theme. Migrating from legacy themes to the Universal Theme is a significant undertaking and will likely require remediation and possibly even a UI redesign. See the ‘Migrating from Other Themes’ tab of the Migration Guide in the APEX Universal Theme App to learn how to migrate to the Universal Theme.
Refreshing the Universal Theme
Assuming your Apps are using the Universal Theme, the steps to refresh it are simple and are laid out in the ‘Refresh Universal Theme’ tab of the Migration Guide in the APEX Universal Theme App.
✅
Refresh the Universal Theme for all your Apps after every upgrade.
Upgrade Application
➡
Navigation: Application > Utilities > Upgrade Application
Specific APEX components undergo changes in their implementation. For example, between APEX 23.1 and APEX 24.1, the Rich Text Editor changed frameworks three times from CKEditor > Tiny MCE > Oracle Rich Text Library. The Date Picker has undergone similar changes to its implementation.
While APEX does a good job of allowing old implementations to work alongside the new, it is good practice to update to the latest implementation when you upgrade APEX.
One way to do this is to run the Upgrade Application utility. This will provide a report of components that you should transition to, along with suggestions on changes to make based on updates to existing components.
While not all suggestions need to be actioned, it is worth checking this report after every upgrade. For example, in the above report, ‘Upgrade jQuery Date Picker to new Date Picker’ should be addressed.
✅
Run the ‘Upgrade Application’ utility after every upgrade.
Check Security Settings
This exercise provides an excellent opportunity to ensure that you have all the recommended security settings in place. While this list is not intended to be a comprehensive security checklist, it highlights settings that are incorrectly configured for this customer and are worth reviewing in your instance.
Application Level Authorization Scheme
➡
Navigation: Shared Components > Security Attributes > Authorization Scheme
✅
All applications should have an Application Level Authorization scheme. This maintains a minimum level of Authorization should you forget to add Authorization at the Page Level.
Page Level Authorization Schemes
✅
All pages should have an Authorization scheme. This shows you have considered which users should be able to access the page.
Application Security Runtime API Usage
➡
Navigation: Shared Components > Security Attributes > Application Security Runtime API Usage
These options restrict what impact an application can have on your APEX environment. For example, to use the API APEX_UTIL.CREATE_USER in an APEX Application, the application must permit modification of the workspace repository.
✅
Uncheck all of these options unless you have a specific use case that requires their use.
Bookmark Hash Function
➡
Navigation: Shared Components > Security Attributes > Bookmark Hash Function
This was set to MD5 and needed to be SHA-2, 512-bit.
✅
Ensure the Bookmark hash function uses the most advanced hashing algorithm available.
Browser Caching
➡
Navigation: Shared Components > Security Attributes > Browser Security > Cache
This was set on. I can’t think of any good reasons to have this switched on.
✅
This should be turned off.
Session State Protection
💡
Navigation: Shared Components > Security Attributes > Session State Protection
Although this was set at the Application Level (which does nothing), it was only set for about half of the pages. Not having this set for every page makes URL tampering a real risk.
✅
Always enable at the Application Level. Set for every page level, unless you have a compelling reason not to.
Session Management
➡
Navigation: Shared Components > Security Attributes > Session Management
While this was set for the applications in this case study, it is worth noting, especially for applications that haven’t been updated in a long time. Setting appropriate idle and session timeouts is essential.
✅
Always set session and idle timeouts for your applications.
Other Settings to Check
Friendly URLs
➡
Navigation: Shared Components > Application Definition > Friendly URLs
Enabling Friendly URLs changes how APEX handles URLs from the legacy f?p= syntax to a path-based syntax. It is also a prerequisite for enabling PWAs.
✅
Switch it on, go on, you know you want to do it.
Progressive Web App
➡
Navigation: Shared Components > Progressive Web App > Enable Progressive Web App
Enable the ‘Enable Progressive Web App’ setting as a minimum. This provides performance improvements by serving static files more efficiently using advanced caching. There are also other compelling PWA features worth considering.
✅
Enable ‘Enable Progressive Web App’.
Instance & Workspace Settings
As APEX evolves, new options are added at the Instance (INTERNAL/Administration Services) and Workspace levels. It is essential to verify these settings after an upgrade to ensure that any newly added options are configured correctly.
Instance
Some more recently added instance settings that you should check:
Not recent but worth checking anyway:
- Manage Instance > Security > Require HTTPS (should be on)
Workspace
Some more recently added workspace settings that you should check:
Plugins
➡
Navigation: Application > Shared Components > Plug-ins
The applications that were part of this exercise used five plugins. All of them are no longer actively supported. The good news is that they can all be replaced with standard functionality in APEX 24.2.
✅
Check all plugins: 1) Can they be replaced by standard functionality? 2) Make sure they are still actively supported. 3) If they are not supported, ensure you understand how they work so you can resolve any issues that may arise after an upgrade.
Tabular forms were used extensively. Tabular forms were deprecated in APEX 20.1 and are considered legacy.
✅
Replace tabular forms with Interactive Grids as soon as possible. It is only a matter of time before they cause problems.
Deprecated & De-Supported Features/APIs
Check for references to deprecated APEX features, PL/SQL, and JavaScript APIs. In my use case, I found calls to htmldb_mail.SEND and wwv_flow_mail.push_queue and usage of legacy data load definitions and tabular forms.
✅
If you do not address remediation of deprecated to de-supported features, at least add remediation for these to your backlog. Incorporate these remediations the next time you need to change the impacted application(s).
💡
Having your code in GitHub makes finding references to deprecated APIs much easier.
Modern Authentication
For this use case, the customer utilized a custom table-based Authentication Scheme with plain-text passwords. Legacy apps often use hardcoded custom authentication schemes that are now better handled with APEX Social sign-on and modern authentication providers, such as Active Directory and Okta.
This even applies to APEX Builder. Configuring APEX Builder to use SSO enhances the security of your development environment and streamlines login for your developers.
APEX Advisor
➡
Navigation: Utilities > Advisor
The APEX advisor appears to be receiving more attention from the APEX development team, and as of APEX 24.2, is starting to provide valuable insights again.
💡
Run before and after any upgrades.
Release Notes
If all you did for each APEX upgrade were to read the release notes, you would be more than halfway there. Just look at the index. Why would you not want to know these things before upgrading?
✅
Always read the release notes for each new version of APEX.
What About ORDS?
Everything I have said about APEX applies to Oracle REST Data Services (ORDS). In every release, ORDS introduces new features, deprecations, performance improvements, and bug fixes. In short, whatever steps you take for APEX, you should also take for ORDS.
What About the Database?
The great thing about APEX running in the database is that with each major database release, APEX receives a direct boost in functionality and performance enhancements. When performing a database upgrade, review the new features to identify areas where you can utilize modern approaches and features. Some examples in 19c and 23ai include:
Significant improvements to how you handle JSON in the database. This includes much more efficient JSON Parsing since 19c. It also enables the inclusion of additional attributes in a JSON column.
Vector/Semantic search in 23ai significantly enhances search and serves as the building block for AI techniques, such as Retrieval-Augmented Generation (RAG).
SQL Macros (since 19c) allow you to create parameterized views, which can boost the performance of your APEX reports.
JSON Relational Duality Views provide a configurable JSON interface to relational tables.
Reasons to Stay Up to Date
Oracle Support - After a new version of APEX is released, Oracle provides support for it for 18 months.
Security - By running the latest version, you are running the most secure version of APEX. Also, remember to update the recommended security settings accordingly.
Return on Investment - Take advantage of the latest groundbreaking features by running the latest APEX version and enabling new features.
Performance - Take advantage of performance improvements included in the latest version.
Developer Productivity - The latest features make building APEX Apps even quicker.
Developer Sanity - Keep your developers happy (no one wants to be working on APEX 18.2).
Reasons Why We Don’t Stay Up to Date
For every reason why it is a good idea to stay up to date, there is another reason why people don’t:
Fear of breaking Apps with a lot of Custom JavaScript.
Fear of breaking something by making changes to settings.
Fear of breaking Plugins.
Lack of Resources to remediate and or regression test after every upgrade.
Locked into a Custom Theme that cannot be refreshed or converted to the Universal Theme.
How Can I Avoid This Fate?
Follow these steps to avoid the fate of the customer in my use case:
Avoid plugins unless they provide a measurable differentiator for your business. For example, APEX Office Print from United Codes provides functionality fundamental to business applications that are not available in APEX out of the box.
If your business depends on a Plugin, make sure you either know how to fix it yourself or that a reputable company, such as United Codes, supports it.
Check the release notes to see if the latest version has a feature that allows you to remove a plugin or simplify code.
Avoid JavaScript unless it is going to provide a measurable business impact.
Do not unsubscribe from the Universal Theme.
Upgrade APEX (and ORDS) at least once a year.
Read the release notes for every APEX release.
If you do not address the remediation issue in the current upgrade cycle, at least document it so that you are aware of the technical debt you are accumulating by not taking action. Documenting deferred remediations has the added benefit of giving you a list to process throughout the year. I suggest leaking them into your sprints while working on other changes to your Apps. You could also reserve a couple of dedicated sprints each year to handle remediation issues.
Build regression test scripts (manual or automated) to allow you to run regressions after each upgrade.
Conclusion
An aging APEX environment rarely screams for attention. All the same, it quietly accumulates risk, inefficiency, and missed opportunity. As this case study shows, the illusion of stability can mask a mounting backlog of deprecated features, security gaps, and unsupported components.
The payoff is modern security, faster performance, happier developers, and the freedom to adopt new features with confidence. Don’t let inertia become your architecture. Make staying current part of your culture, not just your roadmap.
💡
I urge you to consider upgrading APEX (and ORDS) at least once a year and maintain a backlog of remediations along with a plan to address them.
