The short version
Oracle Forms modernization has a familiar bottleneck. Database packages can often be reused, but screens, triggers, program units and Forms-specific behavior still have to be understood before a team can redesign them for APEX.
Oracle APEX 26.1 changes the rebuild workflow with APEXLang, an open, declarative specification language for APEX applications. APEXLang represents application intent as structured .apx files that developers can read, store in Git, compare, validate and import.
Oracle has also published an AI-assisted Forms analysis workflow that turns exported Forms XML into reviewed requirements, traceability and modernization guidance. Put the two together and teams have a more direct path from legacy behavior to reviewable APEX source.
It is still modernization, not one-click conversion. The gain is a faster and more consistent engineering loop.
What changed in APEX 26.1
Before APEX 26.1, source control commonly revolved around generated SQL exports. Those exports remain useful for deployment, but they are not an ideal format for understanding a page or reviewing a focused change.
APEXLang adds a structured application package with readable definitions for application settings, pages and shared components. Oracle documents these files as source artifacts that can be reviewed, versioned, diffed, scanned, validated and governed.
| Capability | What it changes for a modernization team |
|---|---|
Human-readable .apx files |
Developers can inspect the proposed APEX application before import. |
| Source control | Page and component changes can be reviewed through meaningful diffs. |
| AI coding agents | Agents such as Codex or Claude can generate and modify supported APEX definitions. |
| SQLcl validation | Teams can run apex validate and correct metadata errors before import. |
| SQL Developer for VS Code | Developers get APEXLang editing, validation and import/export support in the editor. |
Oracle’s APEXLang skills can be installed or updated with SQLcl’s skills sync command. This gives coding agents documented APEX patterns instead of asking them to invent application metadata from a prompt alone.
The Forms analysis step matters just as much
APEXLang describes the target APEX application. It does not explain what an old Forms application was meant to do.
For that discovery work, Oracle has published a Forms modernization agent workflow for VS Code. The documented process starts by converting FMB modules to XML, then gives an AI agent access to the Forms definitions and the target database through MCP for Oracle Database.
The agent is designed to:
- Inspect Forms triggers, program units and referenced database objects.
- Check whether required objects exist in the target schema.
- Classify logic as reuse, refactor, reimplement or discard.
- Create a supporting PL/SQL package when reusable logic should move into the database.
- Produce a functional requirements specification.
- Produce a traceability matrix and modernization report for the APEX team.
Those are useful deliverables even before page generation begins. They make the legacy behavior explicit and give developers something concrete to review with users and application owners.
The approved specification can then drive an APEX blueprint or more detailed APEXLang generation. The generated application source remains inspectable and can be validated before it reaches an APEX environment.
Worked example: a marina management application
Consider a Forms 10g marina system with 24 modules covering berth allocation, seasonal contracts, vessel records, utility metering, invoicing and administration.
For planning, the team classifies the inventory as:
| Complexity | Modules | Example characteristics |
|---|---|---|
| Simple | 5 | Basic maintenance pages with limited logic |
| Medium | 14 | Multiple tables, validations and standard workflows |
| Complex | 5 | Heavy trigger logic, integrations or difficult transactions |
The table below is an illustrative planning model, not a published benchmark, customer quote or delivery commitment. It shows how a team might test the potential impact of the 26.1 workflow during a pilot.
| Phase | Traditional planning assumption | AI-assisted 26.1 pilot assumption |
|---|---|---|
| Analysis and requirements | 20 days | 5 days, with generated requirements and traceability reviewed by people |
| Business logic extraction | 15 days | 6 days, with package drafts reviewed and hardened by a developer |
| Initial application build | 108 days | 45 days, using APEXLang or blueprint scaffolding before refinement |
| Testing and UAT | 25 days | 22 days, with full business and security testing retained |
| Illustrative total | 168 days | 78 days |
Under those assumptions, the model shows roughly 54% less effort. That percentage is arithmetic, not evidence that every Forms portfolio will achieve the same result.
The credible way to estimate a real migration is to run the workflow against one simple and one representative complex module. Measure discovery, requirements review, generated-source correction, UX refinement and testing. Use those results to estimate the rest of the portfolio.
Why this is different from an old-style converter
Oracle desupported the APEX Forms Migration Project in APEX 21.1 and has consistently advised teams not to reproduce Forms screen for screen.
The APEX 26.1 approach is different because it separates three concerns:
- Understand the existing behavior. The Forms agent analyzes XML, database dependencies and embedded logic.
- Agree on the target application. People review the requirements, traceability and modernization decisions.
- Generate reviewable APEX intent. Blueprints or APEXLang create source that can be inspected and validated.
This lets a team replace Forms-specific canvas behavior, navigation built-ins and obsolete UI mechanics with suitable APEX components such as forms, interactive grids, faceted search, workflows and responsive pages.
It does not remove human decisions. Developers still own the target UX, authorization model, transaction boundaries, integrations, performance and production readiness.
A practical starting plan
- Prepare an APEX 26.1 development and staging environment with compatible ORDS and SQLcl versions.
- Convert one or two representative FMB modules to XML.
- Give the Forms modernization agent a clear specification template and controlled access to the target schema through MCP.
- Review the generated requirements, traceability matrix, modernization report and any proposed PL/SQL package.
- Agree on the target APEX page and workflow design with application owners.
- Generate an APEX blueprint or APEXLang source and store it in Git.
- Validate the APEXLang source with SQLcl before import.
- Test security, transactions, integrations, accessibility, responsive behavior and user acceptance in staging.
The early objective is not to migrate the whole estate. It is to prove the workflow, measure correction effort and establish repeatable review standards.
Planning the platform
APEXLang makes the application source easier to govern, but the runtime still needs disciplined operations. APEX, ORDS, SQLcl, Java, the database release, TLS, backups, monitoring and rollback plans should be managed as one platform set.
For teams evaluating the hosting layer, see the Cloud Hosting overview or review the hosting plans.
FAQ
Does APEXLang automatically convert Oracle Forms to APEX?
No. APEXLang specifies APEX applications. Oracle’s Forms modernization agent helps analyze Forms XML and produce requirements and modernization artifacts, but people still review the result and design the target APEX application.
Can existing Forms PL/SQL be reused?
Database packages, procedures and functions can often be reused because APEX runs close to Oracle Database. Logic embedded in Forms triggers or program units should be classified and reviewed before it is moved, refactored, reimplemented or discarded.
Are the marina estimates a benchmark?
No. They are an illustrative planning model based on explicit assumptions. A real estimate should come from a measured pilot using representative modules from the actual application.
Do developers have to stop using App Builder?
No. Teams can continue using App Builder, work with APEXLang in external tools, or combine both approaches.
Can SQLcl validate APEXLang without a database connection?
Yes. Oracle documents offline APEXLang validation with SQLcl. Import and runtime testing still require the appropriate APEX environment and database connection.
Is Oracle Forms 12c support ending in 2026?
Oracle states that Premier Support for Fusion Middleware 12c concludes in December 2026, followed by Extended Support in December 2027. Confirm the exact release and support entitlement for your environment before setting a deadline.