APEX Software Development: The 2026 Oracle APEX Guide

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

APEX software development is the practice of building business web applications with Oracle APEX (Application Express), a low-code platform that lives inside Oracle Database. In the US market the phrase usually refers to Oracle APEX, not to Apex, the programming language of the Salesforce platform; the two share a name and nothing else, and the comparison section below separates them in one table.

Most organizations do not arrive at APEX because they want a new tool. They arrive because an Oracle Forms estate is ageing, a WebLogic upgrade is due, or critical processes run on spreadsheets and Access databases that nobody wants to own. That makes APEX a modernization decision before it is a tooling decision, and it is why teams that deliver legacy application modernization services usually start with an inventory of what exists, which data matters and which screens can be retired, and only then choose between APEX, custom code or a mix of both.

This guide covers what Oracle APEX is and how it works, what changed in the 2026 releases 26.1 and 26.2, typical use cases, what development services include, the delivery process step by step, Oracle Forms to APEX migration, a comparison with other low-code platforms and custom code, costs, the cases where APEX is the wrong choice, security, and a checklist for choosing an Oracle APEX software development company.

What is APEX software development?

APEX software development is building web applications on Oracle APEX, a low-code platform where pages, forms, reports, charts and workflows are assembled declaratively and stored as metadata inside Oracle Database. Business logic is written in SQL and PL/SQL, the database’s own languages, and developers add JavaScript, CSS or REST calls only where the declarative components are not enough.

Oracle APEX was previously called Oracle Application Express, and it has been a no-cost feature of Oracle Database since 2004. According to Oracle’s product page, there are no separate fees per developer, per application or per end user: if you have a supported Oracle Database, you can build and run APEX applications on it. That pricing model is one of the main reasons Oracle APEX software development is common in organizations that already pay for Oracle.

A typical APEX application consists of a few building blocks that every Oracle developer recognizes:

• Interactive Reports and Interactive Grids for searchable, filterable, editable tables of data.
• Forms and wizards generated from tables or views, with validations and computations.
• Dynamic Actions that add client-side behaviour (show, hide, refresh, call PL/SQL) without hand-written JavaScript.
• Charts, calendars, maps and faceted search for dashboards and self-service exploration.
• Approvals, workflows and automations for multi-step business processes and scheduled jobs.
• REST data sources and REST-enabled SQL for consuming and exposing APIs.

How Oracle APEX works under the hood

Oracle APEX has no separate application server tier: the application definition is stored as metadata in database tables, and Oracle REST Data Services (ORDS) acts as the web listener that passes browser requests to the APEX engine inside the database. When a user opens a page, the engine reads the page definition, runs the SQL and PL/SQL it references and renders HTML back through ORDS to the browser.

This architecture has practical consequences. Data never leaves the database to be processed in a middle tier, so data-heavy screens are fast and the database security model applies to every query. Deployment is simpler because there is no Java or .NET application server to patch, and an application can be exported, versioned and imported as a unit. The trade-off is tight coupling: an APEX application is, by design, an Oracle Database application.

Who builds with APEX

APEX is built mainly by three groups: PL/SQL and database developers who already know the data model, Oracle-centric IT departments that need to deliver internal tools quickly, and business-side citizen developers working under IT governance. The common thread is SQL. A developer who writes good SQL and PL/SQL can become productive in APEX within weeks, while a front-end developer with no database background will find the learning curve steeper than the “low-code” label suggests.

For production systems, the most effective teams pair APEX specialists with a database performance expert and, where the UI matters, a front-end developer who understands the Universal Theme. Citizen developers are productive for prototypes and departmental tools, but enterprise applications still need code review, testing and an upgrade plan like any other software.

Oracle APEX or Salesforce Apex: which “APEX” do you mean?

Oracle APEX is a low-code platform for building web applications on Oracle Database, while Salesforce Apex is a proprietary, strongly typed programming language for business logic on the Salesforce platform. Search results for “apex software development” mix both, along with unrelated companies named Apex, so it is worth checking which one a job post, vendor or proposal actually means.

If your project is really about Salesforce, our Salesforce consulting services guide and the page on Salesforce integration are the better starting points. The rest of this article is about Oracle APEX.

What’s new in Oracle APEX in 2026 (26.1 and 26.2)?

The 2026 releases move Oracle APEX toward governed AI and git-friendly development: 26.1 introduced APEXlang, AI Agents and AI Interactive Reports, and 26.2 made APEXlang usable file by file and tied APEX into Oracle Deep Data Security. For teams planning new APEX software development in 2026, these two releases change how applications are versioned, reviewed and secured.

According to Oracle’s 26.1 announcement, the release is available on-premises on all Oracle AI Database distributions (Exadata, Linux and Windows), with OCI and multicloud services following. Oracle partner Pretius describes 26.1 as the first major APEX release in around eighteen months and sums up Oracle’s framing of governed AI as “If you generate it, you own it”. Details of 26.2 come from Oracle’s 26.2 announcement; Oracle re-released the download files on 9 October 2026 and keeps a known issues page worth reading before an upgrade.

APEXlang and source control

APEXlang turns an APEX application into readable, version-controllable files, which means APEX work can finally go through the same git branching, code review and CI/CD pipeline as the rest of your software. Before APEXlang, teams exported a whole application as one large SQL script, so two developers editing different pages produced conflicting exports and reviews compared machine-generated code.

APEX 26.2 completes the picture with file-level import: a single page or shared component can be exported and imported as an .apx file, and the builder can compare a file with the application and pull in only the changes. In practice this lets several developers work on one application in parallel, makes diffs meaningful in merge requests and allows a pipeline to deploy only what changed. For an Oracle APEX software development team, this is the most important process change of 2026.

AI Agents and AI Interactive Reports

APEX AI Agents are assistants that act only through tools a developer has explicitly approved, and AI Interactive Reports let users reshape a report in plain language over data they are already allowed to see. The design goal is governed AI: the model suggests, but every action and every row of data goes through APEX and database controls that the development team defines.

APEX 26.2 widened the choice of models with support for the OpenAI Responses API, Google Gemini Interactions and OCI Generative AI, added a Reasoning Effort setting for AI Agents and introduced managed identities for OCI services, so credentials do not have to be stored in the application. The Interactive Reports refresh in the same release added filter chips, multi-select header filters and computed columns described in plain language. If you plan to put AI features into business applications beyond APEX, our team covers generative AI integration across stacks.

What 2026 did not change

The 2026 releases did not change APEX’s fundamentals: it is still an Oracle Database platform, still centred on SQL and PL/SQL skills, and still on a fast release cadence that requires regular upgrades. Organizations that want database independence or a JavaScript-first stack will not find it in APEX 26.x.

The upgrade rhythm deserves planning. As DSP summarises Oracle’s support policy, only the two latest APEX releases are supported, each for approximately 18 months from general availability; by that schedule 24.2 is supported until around July 2027 and 26.1 until around November 2027. In practice, that means an APEX application needs an upgrade roughly once a year to stay on a supported release.

What can you build with Oracle APEX?

Oracle APEX is best for data-centric business applications where the data already lives in Oracle Database and users need to search, edit, approve and report on it. Seven use cases cover most real projects:

• Internal business and back-office apps: CRUD applications for orders, assets, contracts, inventory or case management on top of existing tables.
• Approval and workflow apps: purchase requests, change approvals and onboarding flows with built-in approvals, task lists and email notifications.
• Dashboards and BI-lite reporting: charts, KPIs and self-service reports on operational data without a separate BI licence for every user.
• Oracle E-Business Suite and Oracle Fusion extensions: screens and processes that the ERP does not cover, built next to EBS data or on Fusion data via REST, without customizing the ERP itself.
• Oracle Forms, Access and Excel replacements: modern web versions of legacy Forms modules and spreadsheet-driven processes, with central data and audit trails.
• Customer and partner portals: secure self-service portals where external users see their own orders, invoices or claims stored in Oracle.
• Multi-tenant SaaS on Oracle: line-of-business SaaS products where each tenant’s data is separated in the database and the vendor already standardizes on Oracle.

What do Oracle APEX software development services include?

Oracle APEX software development services cover the full life of an APEX application: building new apps, modernizing legacy systems into APEX, upgrading and integrating existing APEX estates, and keeping them fast, secure and supported. A capable partner should offer most of the following:

• Custom APEX application development: new applications from requirements and data model to production, including authentication, roles and reporting.
• Oracle Forms and legacy modernization: analysing existing Forms, Reports, Access or spreadsheet processes and rebuilding them as APEX applications in phases.
• APEX upgrades: moving applications from older releases such as 19.x, 21.x or 23.x to 24.2 and 26.x, fixing deprecated components and adopting APEXlang.
• Integrations: REST and ORDS interfaces with ERP, CRM, payment and SaaS systems, plus single sign-on with corporate identity providers. Our guide to enterprise system integration covers the patterns in more depth.
• UI and UX work: layouts, navigation and accessibility on the Universal Theme and the refreshed Iris theme, with custom components only where they pay off.
• Performance tuning: SQL and PL/SQL optimization, indexing and pagination strategy for large Interactive Reports and Grids.
• Support and maintenance: monitoring, bug fixing, small enhancements and a planned upgrade cycle aligned with Oracle’s release schedule.

The balance between these services depends on where you start. A greenfield project spends most of its budget on discovery and build, while an existing estate usually spends more on upgrades, performance and refactoring of years of accumulated pages.

How does the APEX development process work?

A well-run APEX project follows the same disciplined lifecycle as any enterprise software, only with shorter iterations because working screens can be generated from the data model in hours. The seven steps below are a practical sequence for a new application or a modernization phase.

1. Discovery and data audit. Map users, processes and the existing schema, identify data quality problems and agree on scope. Deliverable: a prioritized backlog, a target data model sketch and a fixed estimate for the first release.
2. Data model. Design or refactor tables, views and PL/SQL packages before building screens; APEX 24.2 and later can propose a starting model with AI-assisted data modelling in SQL Workshop. Deliverable: a reviewed schema with constraints and test data.
3. Prototype in days. Generate the main pages from the model and put them in front of real users within the first one or two weeks, which works as a low-risk proof of concept for both the process and the platform choice. Deliverable: a clickable prototype on real data structures.
4. Build and integrate. Implement business rules in PL/SQL packages, connect REST sources and target systems, and add authentication, authorization and auditing. Deliverable: feature-complete increments every one to two weeks.
5. Testing and code review. Review APEXlang diffs in merge requests, run unit tests on PL/SQL (for example with utPLSQL) and automate key user journeys in a browser testing tool. Deliverable: a test report and a regression suite.
6. Deployment via CI/CD. Promote APEXlang files and database scripts from development to test and production through a pipeline instead of manual exports. Deliverable: repeatable, auditable releases with rollback scripts.
7. Upgrades and support. Plan an upgrade window roughly every 12–18 months to stay within Oracle’s supported releases, and track performance and usage after go-live. Deliverable: an upgrade calendar and a support SLA.

The biggest time saver in this process is not the low-code builder itself but early user feedback: because APEX screens are cheap to change before the PL/SQL logic hardens, problems with the process surface in week two rather than in user acceptance testing.

How do you migrate Oracle Forms to Oracle APEX?

You migrate Oracle Forms to Oracle APEX by treating it as a redesign: keep and reuse the PL/SQL business logic in the database, but rebuild the screens and user flows for the web. A one-to-one conversion does not work because Forms is stateful and trigger-driven, while APEX is stateless and request-based, and Oracle’s own FAQ on Forms to APEX modernization makes the same point: no tool converts Forms to APEX fully automatically.

Timing is driven by support dates and infrastructure. Per published timelines under Oracle’s Lifetime Support Policy, as summarised by Aqlix’s 2026 migration guide, the latest Oracle Forms release is 14c (14.1.2) from December 2024, with Premier Support until 2030 and paid Extended Support until December 2033. Forms also requires WebLogic Server, while APEX does not, so retiring Forms usually removes a whole middleware layer to license and patch. The same guide estimates, as a vendor estimate, that mid-size migrations take roughly 6–18 months and large estates 2–3 years.

Oracle documents the built-in starting point in its guide to creating a Forms to APEX migration project, which analyses the uploaded Forms XML and helps track each module’s status.

Step-by-step Forms to APEX migration plan

1. Inventory and complexity scoring. List every form, report, library and menu, record usage, and score each module by triggers, blocks and integrations to decide what to migrate, merge or retire.
2. Forms XML analysis. Convert modules to XML and load them into an APEX migration project to see blocks, items and trigger code in one place.
3. Target UX design. Design web-native flows (search pages, master-detail, wizards) rather than copying Forms canvases, and validate them with key users.
4. Move logic into database packages. Extract business rules from form triggers into PL/SQL packages that APEX and any other client can call.
5. Phased build and dual run. Rebuild modules in priority order, run them in parallel with Forms where needed and compare results on real data.
6. Training and cut-over. Train users, switch module by module, decommission retired Forms and finally remove WebLogic from the stack.

Common pitfalls in Forms to APEX projects

• Pixel-for-pixel copying. Recreating Forms canvases in a browser preserves decades of workarounds and produces a slower, clunkier web app.
• Trigger logic left in the UI. Moving WHEN-VALIDATE-ITEM style logic into page processes instead of database packages repeats the original coupling problem.
• Ignoring Oracle Reports. Reports often outnumber forms and need their own plan, whether that is APEX reporting, Data Reporter or a separate tool.
• No test baseline. Without recorded expected results from the old system, nobody can prove the new one calculates the same totals.

The same patterns appear across modernization programmes in general; our article on legacy modernization costs and failure patterns covers the business case and the most common reasons projects stall.

Oracle APEX vs other low-code platforms vs custom code

Oracle APEX is the strongest option when data lives in Oracle and the app is data-centric; Microsoft Power Apps fits Microsoft 365 organizations, OutSystems targets broader enterprise app portfolios, and custom code wins when UX, scale or independence from any platform matter most. The comparison below is qualitative and deliberately avoids price figures, because licensing for commercial platforms changes often and depends on negotiated agreements.

For a deeper look at the trade-off, see our comparison of no-code vs custom-built software and the framework for deciding build vs buy for enterprise software. Many organizations end up with a mix: APEX for internal Oracle-centric tools and custom code for customer-facing products.

When is Oracle APEX the wrong choice?

Oracle APEX is the wrong choice when the data does not live in Oracle, when the product is consumer-facing and design-led, or when the organization plans to reduce its dependence on Oracle. In those cases the low-code speed advantage is outweighed by workarounds, lock-in and hiring constraints. Watch for these signals:

• Data outside Oracle or a multi-database strategy. If most data sits in PostgreSQL, SQL Server or cloud data warehouses, APEX adds an Oracle dependency instead of removing friction.
• Consumer-facing, design-heavy or offline-first mobile apps. Pixel-perfect brand experiences, animations and native device features are expensive to force into a business-app framework.
• Very high public traffic with complex front-end interactivity. Rich client-side applications for large anonymous audiences are better served by a dedicated front-end and API architecture.
• No PL/SQL skills available. If neither your team nor your hiring market has SQL and PL/SQL depth, maintenance will become the bottleneck.
• A strategic plan to leave Oracle. Building new applications on APEX deepens the dependency you are trying to reduce.
• Heavy real-time and event streaming workloads. High-frequency event processing and streaming analytics fit specialized platforms better than a request-based web framework.

When several of these apply, the alternative is usually a custom application with an API layer that can still read from Oracle during a transition. That is the core of enterprise software development: choosing the architecture for the next ten years rather than the fastest first screen.

How much does Oracle APEX development cost in 2026?

The Oracle APEX platform licence is usually $0 on top of an Oracle Database you already have; the real costs of APEX software development are engineering effort, hosting and the regular upgrades the release cycle requires. The table below breaks the total cost of ownership into its components.

The OCI figures come from Oracle’s announcement that it lowered the barriers to entry with ECPU and per-gigabyte pricing, which replaced the earlier entry configuration of 1 OCPU and 1 TB at $358 per month, and from Oracle’s APEX pricing page. Prices on OCI change, so treat them as a reference rather than a quote.

Within engineering effort, these factors move the estimate most:

• Number and complexity of Oracle Forms and reports to migrate or replace.
• Integrations with ERP, CRM, payment, document and identity systems.
• Data migration and cleansing from spreadsheets, Access or legacy schemas.
• Authentication and SSO with corporate identity providers and fine-grained roles.
• Compliance requirements such as audit trails, data residency and access reviews.

As a reference from our own modernization pricing, fixed-scope engagements on our software modernization page start from $2,300 for a modernization audit with quick wins, $9,200 for systemic refactoring and $28,700 for full modernization, quoted in USD after a discovery phase that typically takes 4–6 weeks. Whether the target is APEX, custom code or a combination is decided in that discovery, not before it.

How do you choose an Oracle APEX software development company?

Choose an Oracle APEX software development company by checking production experience on current releases, database depth beyond page building, and a credible plan for testing, security and upgrades. A short checklist helps compare vendors on substance rather than on slide decks:

1. Live APEX 24.2 or 26.x applications in production that the vendor can describe in detail, including size, users and integrations.
2. PL/SQL and database performance depth, not only page building: ask how they would tune a slow Interactive Grid on a table with tens of millions of rows.
3. Oracle Forms migration references with honest timelines and lessons learned, if modernization is part of your scope.
4. APEXlang, git and CI/CD practice: how they branch, review and deploy APEX changes after 26.1 and 26.2.
5. A clear security model: authentication schemes, authorization schemes, session state protection and use of Deep Data Security in 26.2.
6. An upgrade and support plan aligned with Oracle’s two-release, roughly 18-month support window.
7. Transparent, fixed-scope discovery before a full estimate, with deliverables you keep even if you change vendors.

Is Oracle APEX secure enough for enterprise applications?

Yes, Oracle APEX is secure enough for enterprise applications when teams use the database security model properly and keep applications on supported releases. Because APEX runs inside Oracle Database, data access stays within the database security perimeter instead of passing through an extra application server.

• Authentication schemes integrate with corporate identity providers through standards such as SAML and OpenID Connect, as well as database and custom schemes.
• Authorization schemes control access to applications, pages, regions, buttons and processes based on roles.
• Session state protection prevents users from tampering with URL parameters and page item values.
• Deep Data Security in APEX 26.2 checks Data Roles and Data Grants in the database on every SQL statement, including REST calls and AI Agent actions, according to Oracle’s 26.2 announcement.
• Supported releases only: staying within the two currently supported APEX releases keeps security fixes flowing.

Platform features are only half of the job; secure coding, reviews and testing matter just as much. Our guide to the secure software development life cycle explains how to build those checks into every release.

Frequently asked questions