Replace Oracle Forms without rewriting the application.
The Forms 6i, 10g and 11g estates that still drive enterprise operations — with their PL/SQL backends, Forms triggers and decades of accumulated business rules — migrated to a metadata-driven runtime without abandoning the Oracle database tier. The PL/SQL stays. The Forms client tier becomes metadata.
Keep Oracle if you want to
The Oracle database tier — schema, PL/SQL, packages, sequences, jobs — is imported and continues to do the work. Migration is the application tier above it, not the engine underneath.
PL/SQL is preserved
Packages, procedures, functions, triggers, database jobs — imported as-is. Modernised in place. The decades of accumulated PL/SQL that encodes the business is preserved as a native asset, not translated into Java imperative code.
Forms become metadata
Form blocks, items, triggers (WHEN-BUTTON-PRESSED, POST-CHANGE, WHEN-VALIDATE-ITEM), menus and reports are read and reified as rows in the Dictionary database. The runtime materialises the application surface from those rows.
No Forms Server
The Forms client tier — and the Forms Server or Application Server that hosts it — is replaced by the platform's supervised JVM-class runtime. Browser-side rendering on Vue / Vuetify; server-side execution on GraalVM Polyglot; no Forms-specific runtime to license or maintain.
The five-layer methodology, applied to Oracle Forms
From the database outward. Each layer is independently deliverable. Cut-over is incremental.
1 · Schema
Oracle tables, indexes, sequences, constraints, materialised views and partitions — imported into the dictionary's table-object catalogue. Type mappings applied automatically. Foreign keys, defaults, check constraints become rows the platform can recompile.
2 · PL/SQL and triggers
Packages, procedures, functions, triggers, database jobs imported and modernised in place. Cross-package dependencies, ref cursors and PL/SQL collections are handled natively. The PL/SQL that encodes the business stays where the business expects it.
3 · Forms become metadata
Form modules — blocks, items, lists of values, triggers, menus, libraries — are read and reified as Dictionary rows. WHEN-BUTTON-PRESSED triggers become server-side JavaScript handlers; POST-CHANGE and WHEN-VALIDATE-ITEM become field-level validators in the metadata. The Reports modules port similarly.
4 · Batch and middle tier
Server-side JavaScript on the platform handles what concurrent managers, database jobs and shell-scripted batch programs once handled — scheduled execution, integration, file handling, document generation, AI orchestration.
5 · UI
Generated from the metadata, on Vue 3.5 / Vuetify 4. The Forms screens — character-mode, applet-based or web-deployed — become responsive browser UI. Mobile delivery, role-aware rendering and accessibility are properties of the runtime.
What changes for the operator
The Oracle database tier keeps doing what it does — schema, packages, triggers, the named business rules and the named jobs. What changes is the application tier above it: the Forms Server and its administrative overhead are replaced by the platform's runtime, the Forms client becomes metadata-generated browser UI, and integration becomes a first-class concern handled by the platform's microservice mesh.
The team that delivers this is a database engineer who knows the PL/SQL estate and a business analyst who knows what the business expects of it. A full-stack developer is not on the critical path; the platform generates what would have been written.
A typical Oracle Forms migration vs an Airtool migration
| A typical migration | An Airtool migration | |
|---|---|---|
| Database choice | Forced — APEX, custom Java, or a new vendor's ERP | ✓ Open. Oracle stays if you want it; PostgreSQL or another target if the workload calls for it. |
| PL/SQL strategy | Re-written into APEX or translated into Java | ✓ Preserved in the database, modernised in place |
| Forms triggers | Re-implemented per screen in the target framework | ✓ Imported into metadata; runtime executes them |
| Reports modules | Re-built in a new reporting tool | ✓ Imported into the OLAP / reporting layer of the platform |
| Customer-side team | Oracle Forms experts, Java developers, project managers | ✓ Database engineer + business analyst + our team |
| Cut-over | Big-bang or fragile parallel run | ✓ Incremental, parallel-run, business runs through migration |
| Vendor lock-in | Often swapped for a new vendor's lock-in | ✓ Standards-based runtime; portable across seven OLTP engines plus three OLAP |
Why Forms estates are hard, and what makes them tractable
Oracle Forms is one of the most successful enterprise development platforms in history, and one of the hardest to leave. The business logic is distributed between PL/SQL and Forms triggers. The user-interface assumptions are baked into form modules. The Reports modules carry decades of report definitions that the business depends on. Most modernisation attempts try to rebuild all of it at once, with predictable results.
The migration becomes tractable when the layers are separated: PL/SQL stays in the database where it was always supposed to live; Forms triggers are imported into metadata where they can be refactored; Reports are imported into the platform's reporting layer. The application tier moves; the data tier and the rule tier stay. The business runs through the migration.