APEX 26.1 has landed, introducing APEXlang. A human-readable export format that opens the door to version control workflows, AI-assisted development, and a much cleaner way of working with Oracle APEX applications.

Here's the uncomfortable part.

While the platform evolved, a lot of our applications quietly stayed where they were. Technical debt piled up year after year. Skipped APEX upgrades, outdated Universal Theme versions, custom JavaScript and CSS added to work around limitations that no longer exist, unsupported plugins, inconsistencies, and security findings that were never revisited because "the application still works."

None of these issues are unusual. In fact, they're exactly what we'd expect to find in applications that have successfully supported the business for many years.

The challenge is that technical debt compounds. It makes upgrades harder, increases maintenance costs, and limits your ability to take advantage of new APEX capabilities. In some cases, it can even prevent a clean APEXlang export or import altogether. Did you know it's not possible to export APEX applications with translated shadow applications?

There's also the security angle. Every skipped APEX upgrade means missing years of security fixes, while custom workarounds often bypass native protections. And as newer AI models make it easier to analyze applications and uncover weaknesses, the applications that have "just worked" for years can quietly become some of the highest-risk assets in your portfolio.

So while APEX moved on, our applications quietly became part of the legacy.

At United Codes, we've helped a number of clients work through those challenges. So we don't call them upgrade projects, but application modernizations. By getting our clients' applications lean, secure, consistent, and genuinely ready for everything APEX and the future has to offer.

This article walks through that methodology: how we assess an application's current state, define the scope of modernization, execute the work, and measure the results.

The methodology

Every modernization project we run sharpens the same methodology, built to hit all project goals at once: schedule, budget, and most importantly, the quality of what we hand back.

Paired with our own tooling, APEX Project Eye, which supports the whole journey from first analysis to final delivery, the process lets us:

• Analyze and quantify the technical debt
• Understand how the applications are actually used
• Set clear modernization goals
• Measure project progress in real time
• Report outcomes with hard numbers
• Hand back future-proof applications and development guidelines the internal team can keep using

Leaving you in a place where every future APEX upgrade is just a routine task again.

The work breaks into four phases:

1. Analysis: step on the scale and set the baseline

You can't modernize what you can't see. So we start by measuring the applications across several dimensions, which is the heart of our APEX Health Check approach:

• Usage — what's actually used versus dead weight, where the performance problems are, and which paths through the app really matter.
• Size — instance, workspace, application, and page level.
• Complexity and custom code — the degree of bespoke JS/CSS/HTML/PL/SQL that's holding you back from keeping pace with newer versions.
• Bad practices and workarounds.
• Errors — invalid SQL/PL/SQL, broken references.
• Security vulnerabilities.
• Deprecated and desupported components or configurations.

A lot of this comes straight from the platform itself. The APEX dictionary views expose everything about your applications; you just need a systematic way to query it. On top of the systematic scan, there's always a layer of manual review; some things you only catch when looking at the page itself.

Each page then gets a score based on its size, complexity, usage, and the type of issues found. That score is what turns a vague sense of "this app is messy" into something you can plan and budget around. 

To give you a feel for the shape of a real portfolio, here's an anonymized breakdown from one engagement:

All this rolls up into an analysis report that becomes the basis for everything that follows.

2. Plan: decide what "future-proof" means for you

The analysis is the input. Planning is where we define a concrete scope.

First, we reduce the scope: unused applications and pages get identified and dropped from scope. There's no sense modernizing something nobody opens. (The usage data — from APEX_WORKSPACE_ACTIVITY_LOG and Project Eye's orphan page and chain analysis — makes these calls defensible rather than guesswork.)

Then we align on the enhancements, and this is where we go beyond "just make it run on the new version." We're not interested in only upgrading the platform and confirming the lights are still on. To make an application genuinely future-proof, we look at:

• Replacing custom code with native APEX. This is the big one. A quick word on philosophy: APEX is wonderfully customizable, and that's a strength. But custom code is your responsibility forever; native components are the APEX team's responsibility. Every bit of unnecessary JavaScript, CSS, HTML, or PL/SQL we can replace with a native approach is debt you stop carrying.
• Retiring unsupported plugins. If a plugin was genuinely useful, there's a good chance APEX has since absorbed that behavior natively. Better to depend on the platform than on an external developer you've never met.
• Adopting and refreshing the Universal Theme to the latest version — making everything render correctly, leaning on documented UT CSS classes and variables, and using Template Components instead of hand-rolled custom templates.
• Replacing legacy components with their modern equivalents, and introducing new component types where they genuinely serve the business process.
• Centralizing shared components, application features, JavaScript, and CSS to kill redundancy — and pushing business logic out of the apps and down into the database where it belongs.
• Applying best practices — both the global ones and your internal standards.
• Resolving the security issues the analysis surfaced.
• Cleaning up everything unused — orphaned pages, unreferenced buttons and dynamic actions, unreferenced shared components, disabled components. Clutter doesn't just confuse the next developer; it confuses the LLMs you'll want to point at your APEXlang in the first place.
• Making things consistent — naming conventions, formatting rules, and a standardized look and feel across pages.
• Fixing performance — by optimizing code or, where needed, redesigning the functionality.

With the activities chosen and the scores in hand, we can estimate effort and set a realistic ETA. Here's roughly how that math looks, building on the same portfolio. We express it in story points, relative effort per page on a Fibonacci scale, and we count only the pages that are used. 

Finally, every page becomes a ticket on an agile board, with a defined workflow and an owner. That's not bureaucracy for its own sake — it's how we always know the exact status of any page, application, or the project as a whole, and how we catch a budget or deadline drift long before it can derail anything.

3. Execution: leave the past behind, page by page

With a plan and a board, we go through applications and pages, one by one, assigning functionally related pages to the same developer so context isn't lost across the team.

A few practices make the difference here:

Keep a reference environment. We set up a separate environment running the original APEX version, so we always have a faithful picture of how each application looked and behaved. It's our safety net against silently losing functionality.

Actually, leave the past behind. We disable the legacy JavaScript libraries that APEX ships for backward compatibility, refresh the Universal Theme, and set compatibility mode to the latest version. This will break things. But we're walking every page anyway, so we catch and fix what breaks.

Centralize in multi-app environments. We adopt a shared-component subscription approach so the theme, plugins, authentication and authorization schemes, lists, LOVs, application items and processes, and more are maintained in one place and subscribed everywhere else.

Let QA drive the work. Developers run the APEX Project Eye Quality Assurance rules before and during their work on a page — first to understand everything that needs to be resolved (so they can prepare properly), then as a living checklist of what's already been done. This is what guarantees the agreed activities actually happen, whether the page is touched by a human or generated via APEXlang.

Using our AI expertise. APEXLang enables you to maximize AI use when developing APEX applications. This does not mean we let AI generate all of the code. We incorporated agentic development into our way of working. By keeping a human in the loop, we assure the delivery of readable, maintainable, and robust applications.

4. Review: prove it with numbers, then keep it that way

Modernization that you can't measure is just a feeling. Throughout the project and at the end, we report concrete success metrics:

• Number of pages before and after
• Total complexity score
• Lines of JavaScript
• Lines of CSS
• Unsupported plugins still in use

And we don't just hand over a cleaner app and walk away. As the project progresses, we continuously refine the development guidelines and implement as many of them as possible into the APEX Project Eye QA rule library, so your team can keep applying them to new development. We also capture that knowledge as AI skills and rule files, so the same standards are honored when applications are later modified through APEXlang. The way of working outlives the engagement.

Measurable Results

Across our past projects, the numbers have been consistent — and frankly, more dramatic than people expect going in:

• ~30% reduction in application size
• ~60% reduction in complexity score
• ~90% of custom code and unsupported plugins removed

Now imagine how much trouble you save yourself on future APEX upgrades. Each one becomes a routine task with nothing to break, and you'll be able to keep up with every new version. Your APEXlang export will be lean and valid, with less noise for AI agents working on a leaner, native codebase rather than a layered pile of workarounds.

Where to start

If your applications have been running quietly for years and you're not sure what state they're really in, that's exactly what an analysis is for, and it's your first step toward eliminating that technical debt.

• APEX Health Check — get a clear, measured picture of where your applications actually stand: usage, complexity, security, and what's standing between you and a clean APEXlang export.
• APEX Modernization Suite / Upgrades — the full methodology, tooling, and hands-on team to take your applications from "still works" to "ready for what's next."
• Oracle Forms Quick Scan — still running Oracle Forms? Start with a quick scan of your Forms estate to understand what you're working with before planning a move to APEX.

We've done this enough times to have a methodology, the tools, and the scars to prove it. If you want, we'll take you by the hand through the whole thing.

Want to talk through your own portfolio? Reach out to the United Codes team — happy to compare notes.