By Use this Oracle APEX 26.1 upgrade checklist to verify platform requirements, choose a compatible import route, test plug-ins and custom code, repeat your critical workflows, and rehearse recovery before production. This checklist turns those decisions into six checks you can review with your team.
This guide is a practical preflight and regression checklist for developers moving existing applications to Oracle APEX 26.1. Start with the export you plan to deploy, then work through the dependencies, application behavior, and recovery plan before scheduling production.
Scope: The version-specific details below are based on Oracle documentation reviewed on 4 October 2026. The test plan is a proposed checklist, not a report of a completed upgrade. No application-specific test results are claimed.
For a tour of the release, see the Oracle APEX 26.1 new features overview. This guide focuses on migration readiness and the evidence needed for a go-live decision.
Oracle APEX 26.1 upgrade checklist at a glance
| Decision | Evidence to collect | Ready when |
|---|---|---|
| Who owns the platform upgrade? | Hosting model and named platform owner | Developer and administrator responsibilities are agreed |
| What exactly will be imported? | Export type, source APEX version, file revision | The deployment route is valid for this artifact |
| What does the application depend on? | Schemas, packages, shared components, plug-ins, integrations | Dependencies exist in the test target |
| Which workflows must keep working? | Baseline results for representative user roles | The same checks can be repeated after the move |
| How would service be recovered? | Approved recovery procedure and restore evidence | The owner can explain the recovery point and downtime |
1. Verify the platform before troubleshooting the application
For Oracle Database 19c, the minimum is Database Release Update 19.18. On Oracle AI Database 26ai, Oracle specifies database version 23.26.0 or later. APEX 26.1 requires ORDS 26.1.1 or later. Check the exact database and ORDS versions, rather than recording only “19c” or “ORDS installed.” Oracle APEX 26.1 prerequisites.
On a self-managed installation, have the platform owner check the database, ORDS configuration, APEX static resources, and installation procedure together. Record the current versions and configuration before changing anything.
On managed hosting, first ask which parts the service operates and what upgrade or preview options it provides. Workspace access is not evidence that you can change ORDS or install another APEX release. Your application checks still belong in the plan, even when the provider handles the infrastructure.
- Record the source and target APEX versions, including installed patches.
- Agree a test window and identify who can inspect platform logs.
- Use an isolated test environment with safe data and controlled integration endpoints.
- Capture the current application Compatibility Mode so it can be compared after migration.
2. Choose the correct import route
APEX 26.1 accepts full applications from APEX 24.2 and earlier. It rejects earlier-release single-page and component exports; 26.1 page/component exports remain supported. This distinction matters when your release process normally ships one page at a time. Oracle export and import changes.
For a complete application migration, start with a full application export and rehearse importing it into the 26.1 test target. Review the parsing schema, application ID, supporting objects, remote servers, and subscriptions before confirming any replacement. Reusing an existing application ID replaces that application. Oracle application import workflow.
If you only need one page from an older application
Use a full-application migration as a staging step in an isolated environment. After that application is available in 26.1, prepare a fresh, same-version deployment artifact for the page or components you need. Treat this as a workflow to rehearse, not a guarantee that every dependency has been carried across correctly.
Before using a single-page export between systems, check Oracle’s restrictions: matching application and workspace IDs, matching shared-component IDs, and prior deployment of new or changed shared components. A page export is not a self-contained package for its database objects and dependencies. Oracle single-page export restrictions.
Keep the original full export unchanged. Give the migrated export a separate revision and record which target version produced it. Avoid manually editing internal export procedure calls to make an incompatible artifact appear acceptable.
Also verify the selected format. App Builder does not import APEXlang page exports in this release. APEXlang application imports through App Builder require a REST-enabled schema in the workspace, as well as the required ORDS version. Oracle import format requirements.
3. Separate plug-in import from plug-in runtime testing
A standalone Plug-in import is a distinct import category in App Builder. Do not turn the page/component restriction into a blanket claim that every older standalone plug-in export is unsupported. Verify the actual plug-in package, its release requirements, and the result in your target. Oracle import categories.
APEX 26.1 extends unlimited attributes to additional plug-in types. Oracle describes moving relevant plug-ins to the Procedure interface and typed attribute accessors. For migrated attributes, generated Static IDs follow names such as attribute_01. Dictionary queries for dynamic-action attributes should use the JSON attributes column; the older numbered view columns return null. Oracle plug-in attribute migration guidance.
For a plug-in you maintain, review its interface and attribute handling as one change. For a third-party plug-in, first look for the maintainer’s supported release instead of modifying a production copy.
- Inventory each plug-in name, version, source, and the pages that use it.
- Exercise render, AJAX, validation, and error paths where applicable.
- Test populated, empty, and boundary-length attribute values.
- Check substituted values containing quotes, ampersands, and markup; preserve appropriate escaping.
- Repeat the check after region refresh and after a fresh login.
A clean import is useful evidence. It does not establish that all runtime paths or custom integrations are correct.
4. Review the behavior changes that can hide in custom code
Prioritize these documented changes when searching application code:
- DOM identification: Affected page-component Static ID labels become HTML DOM ID. Affected undocumented JavaScript properties change from
regionStaticId/staticIdtoregionDomId/domId. - Page lifecycle: Page Unload dynamic actions use
pagehide; browser exit events are not guaranteed. - Time zones: Automatic Time Zone may yield a named zone. Newly calculated session timeouts are UTC-based, though exposed as
DATEvalues. - Subscriptions: Import checks master components and offers subscription mappings; unresolved required masters can fail the import.
Compatibility Mode controls selected runtime behaviors; higher modes include earlier mode changes. Treat changing it as a separate, testable decision. Oracle changed behavior and compatibility notes.
Search first, then inspect each match in context. A global text replacement across JavaScript, plug-ins, and export files can damage unrelated identifiers. Keep the change set small enough to review, and record the application page and component for every correction.
5. Run the same test matrix before and after
Use the same role, input, and expected business result on both sides of the upgrade. Record evidence against each row. The following matrix is a starting point; remove irrelevant checks and add your application’s critical workflows.
| Area | Baseline and repeatable check | Pass evidence |
|---|---|---|
| Authentication and roles | Sign in, sign out, and open an allowed and a denied page for each important role | Expected access decisions and navigation |
| Forms and transactions | Create, edit, cancel, and submit invalid data using test records | Correct saved values and useful validation messages |
| Reports and grids | Filter, sort, save a report, edit a row, and export representative data | Expected rows, values, and file content |
| Dynamic actions and custom JavaScript | Repeat button clicks and refresh-dependent interactions | One intended action per interaction; no unexpected console errors |
| Plug-ins | Run normal and failure paths on each representative plug-in page | Correct output and server/client error handling |
| Date and session logic | Repeat time-sensitive workflows with documented browser settings | Expected displayed times, comparisons, and session behavior |
| Integrations and jobs | Exercise an approved test endpoint and a controlled background run | Expected payload/result without duplicate external effects |
| UI and accessibility | Use keyboard navigation and narrow-screen layouts | Usable focus order, readable messages, no blocked controls |
Add a result record with: test ID, source result, target result, target version, tester, evidence, and open defect. “Not tested” should stay visible. A screenshot of the home page is not sufficient evidence for a save process, authorization rule, or scheduled job.
When a check fails, preserve the exact error and reproduction steps before changing code. Compare the smallest affected path with the baseline, fix one cause at a time, and rerun the relevant checks.
6. Make recovery an executable plan
Keep application exports, database recovery arrangements, and platform configuration records as separate recovery assets. Confirm which data each one protects. An application definition export is not a substitute for restoring business data.
Have the platform owner specify the appropriate procedure for the actual deployment. Oracle’s release-specific reversion documentation must be read in context; a generic promise to “downgrade APEX” is not a recovery plan. Oracle reversion documentation.
- State the event that triggers recovery, such as a critical workflow failure with no acceptable workaround.
- Name the person who can authorize and execute recovery.
- Record the recovery point, expected downtime, and handling of transactions written after cutover.
- Preserve the prior application revision and the required platform/static-resource configuration.
- Rehearse the chosen restore or recovery route outside production.
- Agree how scheduled work, integrations, and user access will be resumed and checked.
Keep pre-upgrade artifacts until the release has passed its agreed observation period. A newer application export cannot be imported into an earlier APEX release, so do not rely on a post-upgrade export as your older-environment recovery artifact. Oracle export compatibility rule.
Common Oracle APEX 26.1 upgrade pitfalls
Use these questions during the deployment review. Each one catches a gap that an import success message cannot resolve on its own.
“The export imported, so the application is ready.”
An import establishes that the selected artifact passed that import path. It does not exercise your authentication scheme, authorization conditions, database packages, or external services. For an Oracle APEX 26.1 upgrade, keep the import result and the application test results in separate parts of the release record. Ask a tester to run a complete business workflow, including an invalid input and a denied action, before signing off.
“We can replace only the page and sort out dependencies later.”
Start by identifying the source release and export category. An older-release page export needs a different migration route from a full application export. Even a supported same-version page export depends on the matching identifiers and shared components described above. Review those conditions before selecting the target application. A successful rehearsal against a disposable copy gives you more useful evidence than a rushed replacement of a working application.
“The administrator owns every part of the upgrade.”
Assign platform checks and application checks explicitly. The administrator may own ORDS and database readiness, while the development team owns plug-ins, custom JavaScript, integrations, and business behavior. On managed hosting, document what the provider actually operates. The Oracle APEX 26.1 upgrade plan should name who supplies each piece of evidence and who decides whether an unresolved defect blocks production.
“We have an export, so recovery is covered.”
Ask what the export can restore and what it cannot. Application definitions, business data, and platform configuration need appropriate recovery arrangements. Also decide how to handle transactions created after cutover: restoring an earlier point can affect those records. Keep the original application artifact, record the recovery procedure, and rehearse it with the responsible owner before the production window.
If any answer depends on “we will check that later,” put it in the release record with an owner and a deadline. Leave the decision open until the evidence exists. This makes the remaining risk visible without turning an untested assumption into a claimed result.
Final Oracle APEX 26.1 upgrade checks
- Platform requirements and ownership verified
- Original full export and recovery assets retained
- Target import rehearsed with reviewed application IDs and dependencies
- Plug-ins and custom code checked
- Before-and-after test results reviewed, with no unresolved critical failures
- Recovery decision and procedure agreed
- Production window, observation checks, and responsible people confirmed
Key takeaways
Choose the deployment artifact before planning the import. Keep platform readiness and application validation as separate sign-offs. Use repeatable business checks, retain the original recovery assets, and make every untested area visible before production.
The final record from this Oracle APEX 26.1 upgrade checklist should be short and specific: what moved, which checks passed, which behavior changed, and how service can be recovered. That is the evidence your team needs when deciding whether the application is ready.
