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 Metadata Repository. 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 metadata repository'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 metadata-repository 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.
What Forms shops ask before they engage.
Does the migration force us off Oracle?
No. The Oracle database tier — schema, PL/SQL, packages, sequences, jobs — stays in place and continues to do the work. The application tier above the database is what changes : the Forms Server, the Forms client and the administrative overhead they carry are replaced by the platform's runtime. Oracle is not the constraint ; the Forms tier is.
What happens to PL/SQL packages, procedures and triggers?
They are imported as-is and modernised in place. Cross-package dependencies, ref cursors and PL/SQL collections are handled natively. The decades of accumulated PL/SQL that encodes the business is preserved as a database-tier asset, not translated into Java imperative code where institutional knowledge dies.
How do Forms triggers (WHEN-BUTTON-PRESSED, POST-CHANGE, WHEN-VALIDATE-ITEM) port?
They are read from the Form modules and reified as metadata-repository rows. WHEN-BUTTON-PRESSED triggers become server-side JavaScript handlers ; POST-CHANGE and WHEN-VALIDATE-ITEM become field-level validators in the metadata. The runtime executes them in the same order the Forms client did — same semantics, modern execution.
What happens to Oracle Reports modules?
Reports modules are imported into the platform's OLAP and reporting layer. Decades of accumulated report definitions become repository metadata that the platform renders via PDF, Excel or browser-grid output. Concurrent-manager scheduling moves onto the platform's batch surface.
Do we still need a Forms Server or Application Server licence?
No. The Forms client tier and the Forms Server / Application Server that hosts it are replaced by the platform's supervised runtime — browser-side rendering on Vue / Vuetify, server-side execution on GraalVM Polyglot. There is no Forms-specific runtime to license, deploy or maintain after cut-over.
Can we scale reads onto Oracle Data Guard / Active Data Guard standbys without changing application code?
Yes. The platform's data-access layer classifies every query as read or write at compile time and routes read traffic to the configured Active Data Guard standbys — or Real Application Clusters read instances where the topology calls for them — automatically and transparently. Routing is a system-configuration choice declared once in the platform's connection topology ; the application does not change a line of code. Adding a standby to the read pool is a configuration step, not a migration. The same capability applies to PostgreSQL streaming replicas and Informix HDR / SDS — read-scaling is a runtime property of the platform, not an application discipline the customer's engineers have to remember.
Are we just swapping Oracle Forms lock-in for Airtool lock-in?
No. The metadata model is portable across seven supported OLTP engines and three OLAP engines ; the same metadata-repository rows recompile against a different target if a future re-platform makes sense. The PL/SQL stays in standard form. The runtime is operated on standards — Vue / Vuetify on the browser, JavaScript on a JVM-class server. The customer chooses when, and whether, to move.
If we wanted to leave Oracle in the future, what would the natural target be?
PostgreSQL. It is the platform's default modern OLTP target, the closest semantic match for Oracle estates after PL/SQL is preserved by the platform's database-tier methodology, and the natural move for customers planning their forward path away from Oracle licensing exposure. The same repository metadata recompiles against PostgreSQL without re-authoring the application surface ; the modernisation that ships on Oracle this year can lift onto PostgreSQL next year without touching the application tier. Other supported engines remain available where a customer's commercial landscape requires a specific target — but PostgreSQL is the recommendation for Oracle shops planning their forward path.
What about reporting — what do we get versus Oracle Reports or BI Publisher?
An enterprise reporting and analytics surface far beyond what Oracle Reports was designed to deliver, with material overlap on the high-end Oracle BI / OBIEE positioning at a different licensing posture. The platform integrates three columnar analytical engines (Vertica, ClickHouse, BigQuery) with native SQL generation rather than generic dialect translation. Interactive dashboards carry drill-down, drill-across and cross-filtering. Cubes, dimensions and measures live as repository metadata ; reports compose in the same authoring tool that produces operational screens. PDF, Excel, browser-grid and printable layouts render through the platform's document-processing microservice — including FOP-based XSL-FO output for the regulatory-grade layouts that Oracle Reports historically owned. Row-level and column-level security applies to every report by construction. PowerBI, Tableau and Looker are the realistic comparators on the interactive-BI dimension — Oracle Reports is the layer the modernisation replaces.
Related modernisation stacks
The five-layer methodology is the same across source stacks. The port-mapping detail is what differs.
From Informix 4GL & Genero
Schema imports as-is, SPL stays in the database tier, 4GL forms and menus reify as repository metadata. Informix stays as the OLTP target — or lifts to PostgreSQL when the workload calls for it.
From Delphi
VCL forms and DataModules become repository metadata, Pascal business logic moves to stored procedures and triggers, the thick-client install-and-maintain model disappears at cut-over.
From PowerBuilder
DataWindows preserved as metadata, PowerScript moves to the database tier and to server-side JavaScript on the platform runtime, EAServer and two-tier deployment removed.
From custom J2EE
Bespoke Spring / EJB / Struts / JSF frameworks replaced by the metadata-driven runtime. Hand-written SQL, integration contracts and audit history are preserved.
From IBM i (AS/400)
DB2 for i schema imports through native DB2 connectivity, RPG and DDS reify as repository metadata, the 5250 green-screen surface becomes a browser. Stays on DB2 for i — or lifts to PostgreSQL.