Upgrade with Confidence! Catch Desupported Features Before They Break Your App

Oracle APEX upgrades can introduce breaking changes, deprecations, and subtle regressions. Whether you're migrating from APEX 20.x to 24.x or preparing for future versions, such as 25.2, understanding what might break before it actually breaks is crucial.

That’s where the new MIGRATION QA Standard in APE (APEX Project Eye) 25.1 comes in.

This update introduces a purpose-built set of QA rules for APE, enabling developers to systematically evaluate and modernize their applications before an upgrade.

Why It Matters: Desupported ≠ Deprecated

Oracle APEX distinguishes clearly between:

Deprecated - Still functional but planned for removal in a future release. Impact: You can still use it (for now), but update soon.

Desupported - Removed completely, no longer works. Impact: Will cause runtime errors or silent failures. 

The MIGRATION QA Standard uses this distinction to highlight:

• Warnings for deprecated features you should plan to replace
• Errors for desupported features that require immediate attention

Real Example: Public Dictionary View Changes in APEX 24.2 

As of APEX 24.2, several public dictionary views no longer return values in ATTRIBUTE_01 through ATTRIBUTE_25. Instead, values are now stored in a unified attributes JSON column.

This impacts views like:

• APEX_APPLICATION_PAGE_ITEMS
• APEX_APPL_PAGE_IG_COLUMNS
• APEX_APPL_PLUGIN_SETTINGS
• APEX_APPL_PAGE_FILTERS

Any custom logic, QA script, or report that expects values in ATTRIBUTE_01 to ATTRIBUTE_25 will silently break or return nulls—with no warning from APEX.

This is a classic desupported change: the columns still exist, but their values are gone.

The MIGRATION QA Standard will flag this as an error, helping you catch and fix it before you upgrade.

Also Flagged: Deprecated and Risky Code Patterns

APE 25.1’s migration standard doesn’t stop there. It also detects usage of:

- Obsolete JavaScript APIs, like doSubmit() or apex.event.trigger('apexrefresh')

- Deprecated PL/SQL procedures, such as:

          - apex_util.set_session_state → use apex_session.set_value

          - wwv_flow_custom_auth_std.* → migrate to apex_authentication.*

          - apex_util.string_to_table → replaced by apex_string.split

- Legacy UI components:

          - Tabular Forms (replaced by Interactive Grids)

          - Old tree or chart region types

          - JET-based date pickers

Each flagged item includes a severity level and a recommended replacement.

How to Use It

After upgrading to APEX Project Eye 25.1, navigate to the Quality Standards section and load the default UC Standard to make the MIGRATION (25.1) rule set available. Then go to QA Assessments, select the MIGRATION standard, and run a scan on your entire application or selected pages. Review the flagged issues, follow the recommended actions, or mark false positives where appropriate. The assessment helps you quickly prioritize what needs immediate fixes before an upgrade and what can be planned for later refactoring.

What’s Next

Make the MIGRATION QA Standard a regular part of your upgrade planning and QA workflow. You can use it proactively during development, before staging freezes, or when preparing upgrade impact assessments for clients. Stay tuned to the United Codes blog for future updates as we expand this standard with each APEX release.

Summary

The MIGRATION QA Standard in APEX Project Eye 25.1 includes over 90 rules designed to help you prepare for APEX upgrades by identifying deprecated APIs, desupported components, outdated UI elements, and compatibility settings that may cause issues in newer versions. With a single scan, you can detect and resolve potential migration blockers before they impact production, ensuring a smooth and predictable upgrade process.