An Oracle Forms to APEX migration rebuilds each Forms screen as a new APEX page on the same Oracle Database, keeping the schema and the PL/SQL packages. Oracle doesn't offer a converter that turns Forms modules into finished APEX applications, so the size of the work depends on how much logic sits inside the forms themselves.
This post covers what Oracle's tooling does, where the logic hides, how APEX compares, Forms 6i, and when Java fits better. For support dates, see Oracle Forms end of support. If your Forms run inside E-Business Suite 12.2, they follow the EBS clock explained there, and this post isn't for them.
- An Oracle Forms to APEX migration is a rebuild. Each screen becomes a new APEX page, while the schema and database packages stay.
- APEX's old migration workbench was desupported in APEX 21.1. Even before that, it fed Forms metadata into a rebuild rather than producing finished pages.
- Oracle's guidance is to move logic out of triggers and program units into database packages before you build the APEX pages.
- The Java route has the larger scope: every rule in triggers and .pll libraries has to be found and coded again.
Is there an Oracle Forms to APEX migration tool?
Not one that converts. APEX used to include an Application Migration Workshop. Oracle's migration guide for APEX 20.1 describes exporting Forms modules (.fmb), object libraries (.olb) and menus (.mmb) to XML with the Forms2XML tool, converting .pll libraries to .pld text in Forms Builder, and loading the result into a conversion project. Even then, the guide said that once the metadata was uploaded and annotated, "you use this information when building your new Oracle Application Express application." It helped plan the rebuild. It didn't do it.
Oracle's APEX 21.1 release notes then said: "The Migration Workbench (Application Migration / App 4400) is desupported as of this release." The current release is APEX 26.2, released on 6 October 2026 according to Oracle's APEX downloads page.
What Oracle offers today is guidance. Its solution guide, Move Oracle Forms applications to Oracle APEX (updated July 2025), says to "Retain the database structure that Oracle Forms was built on, as is," and to move the logic first: "Before starting the migration of Oracle Forms to Oracle APEX, migrate the business logic to stored procedures, functions, and packages in the database."
Oracle Forms to APEX converter: what to ask first
Any tool you're offered today as an Oracle Forms to APEX converter isn't part of APEX. The question to ask is what it does with behavior, because Oracle's own guide spells out the difference: "In Oracle Forms, triggers control almost everything. In Oracle APEX, control is based on flexible conditions that are activated when a page is submitted and are managed by validations, computations, dynamic actions, and processes."
A trigger that fires when a user leaves a field has no one-to-one equivalent in a page-submit model. Someone has to decide, rule by rule, whether it becomes a validation, a dynamic action, a process or a database constraint. Before any Oracle Forms to APEX conversion, ask:
- what happens to WHEN-VALIDATE-ITEM, POST-QUERY and KEY- triggers;
- whether program units and .pll libraries move into database packages or get copied into each page;
- how record groups, lists of values and multi-record blocks come across;
- how you'll test that each page behaves like the form it replaced.
Generated screens are the cheap part. Whether they behave the same is what you're paying to find out.
Where the logic lives in a Forms application
| Where | What you'll find | Where it goes in APEX |
|---|---|---|
| Item and block triggers (WHEN-VALIDATE-ITEM, POST-QUERY, PRE-INSERT) | Validation, defaults, derived values, business rules | Validations, computations, dynamic actions, or database packages |
| Program units inside each .fmb | Procedures and functions local to one form | Database packages, per Oracle's guide |
| PL/SQL libraries (.pll) | Code shared across forms | Database packages |
| Menus (.mmb) and object libraries (.olb) | Navigation, roles, shared standards | APEX navigation, authorization schemes, shared components |
| Database packages and triggers | Rules already in the database | Stay put, called from APEX |
The same pricing rule can sit in a form trigger, a .pll library and a database package, each slightly different. Finding those copies is what sets the estimate, because two applications with the same number of screens can need very different amounts of work. If one long-serving developer knows where the rules are, start capturing that knowledge before anything moves.
Oracle Forms vs APEX: what changes
| Oracle Forms | Oracle APEX | |
|---|---|---|
| Where it runs | Fusion Middleware (Forms 12c or 14.1.x) | Inside Oracle Database 19c or 26ai, served through Oracle REST Data Services |
| How logic fires | Triggers on items, records and blocks | Validations, computations, dynamic actions and processes on page events |
| What carries over | PL/SQL in the database | The same PL/SQL packages, called from pages |
| Support | Forms 12c Premier Support to December 2026, Extended to December 2027; 14.1.x Premier to December 2030 | APEX 26.2 supported on all editions of Database 19c and 26ai |
Checked 27 October 2026 against Oracle's Fusion Middleware Lifetime Support Policy (effective 13 April 2026) and the APEX downloads page.
APEX suits teams who know PL/SQL and want to stay on Oracle Database. Forms applications are on almost any list of legacy system examples, and running 12c past December 2026 carries the risks in running end-of-life software.
Migrate Oracle Forms 6i to APEX: one extra step
Forms 6i doesn't appear in Oracle's current Fusion Middleware Lifetime Support Policy at all. The oldest Forms it lists, part of Application Server 10gR2, left Premier Support in December 2011 with no Extended Support.
The route is the same, with a possible extra step at the start. Oracle's older APEX migration guide says Forms2XML "should also work on files from earlier releases of Oracle Forms," but if it doesn't, "you must upgrade the file to Oracle Developer Suite 9i or 10g and then convert to XML."
Oracle Forms to Java migration: the second route
Rewriting in Java, or another web stack, fits when the business wants to leave Oracle tooling or change the process itself. It has the largest scope: a Java rewrite either calls the existing database packages or recodes them, and every rule hidden in triggers and .pll libraries has to be found and coded again.
If you're offered an Oracle Forms to Java conversion tool, ask the converter questions above, plus one: what the generated code will look like to the team that maintains it for the next ten years. Generated Java that nobody on your team can read is a new legacy system.
| Route | What stays | What gets rebuilt | Fits when | Main risk |
|---|---|---|---|---|
| Upgrade to Forms 14.1.x | Everything | Nothing; same application on newer middleware | It works and the business wants to keep it | The debt moves across with it |
| Rebuild in APEX | Schema and database packages | Every screen, plus logic moved out of the forms | Your team knows PL/SQL and the data stays in Oracle | Trigger logic rebuilt slightly differently |
| Rewrite in Java | Data, and possibly the packages | Screens, logic, often data access | Leaving Oracle tooling, or changing the process | Every hidden rule must be found and recoded |
Whichever route you take, read the code before you rewrite.
Before you choose APEX or Java: the 30-day assessment
Know where the logic lives before you commit. The 30-day assessment is fixed in scope, at a price agreed before we start. Over 30 days we go through the Forms modules, .pll libraries, menus, Reports and the database packages behind them, and trace where each business rule actually lives: in a trigger, a library, a package, or several at once. We map how the application fits with the database and the systems around it, find the hidden architectural debt, such as rules copied between forms, and flag the security and compliance gaps.
The report says in plain language what is broken, what it would take to fix it, and what an APEX rebuild or a Java rewrite would involve for your application. Your own team can act on it, or we can do the migration as a separate project with its own scope and price. Either way, the report stands on its own. If a count of triggers and libraries would answer your question, we'll say so.
Send one sentence about your Forms application: what it does, which Forms version it runs, and whether you're leaning toward APEX or Java.