Oracle Forms has run government and banking back offices since the 1990s, usually with the real business logic sitting in PL/SQL underneath. We read the Forms definitions and the PL/SQL together, model them, and generate a modern web application from the result.
This is for teams running Forms and Reports where the application still does the work, but the deployment model and the skills have both become a problem.
Forms still ships. The things around it are what moved on.
Forms applications were delivered to the desktop through a Java applet. Browsers removed plugin support, which forced the move to Java Web Start and a desktop Java runtime. It works, but client-side Java is now something most security teams would rather remove than maintain.
Some of the business rules live in form triggers and program units, and some live in PL/SQL packages in the database. Modernizing either one alone leaves half the behavior behind, which is why Forms projects so often stall at the analysis stage.
Oracle has been pointing customers toward APEX and Java for years, and the developer market followed. Forms and PL/SQL experience is concentrated in people who have been doing it a long time.
Teams planning a move off Oracle, usually to PostgreSQL, find the application and the database code too entwined to separate. The PL/SQL has to be dealt with either way, so it is worth dealing with it once.
A hand rewrite works your business rules out again from documentation and memory, which is where undocumented behavior gets lost. We carry them across from the real source instead.
Code Analyzer reads every line of the Oracle Forms source: every form, block, trigger, program unit and PL/SQL package it depends on, along with the data access and the business rules buried inside them. From that we build a model of how the application actually behaves. Gaps are surfaced, not guessed.
Code Transformer maps the model onto a modern architecture and generates a modern web application, 90%+ automated. Generating from the model gives you an application built the way someone would build it today, instead of old workarounds in a new language. Our engineers handle the custom pieces no automated conversion can reach, with AI assistance, and check the result against your original system.
Side-by-side testing runs the new system and the old one on the same inputs and compares what comes out. The business rules held in the model give a second, separate check that does not rely on the tests alone. Automated test coverage is built alongside the transformation.
A public-sector cloud migration required converting a large volume of Oracle PL/SQL stored procedures. Rewriting them by hand would not have fit the project timeline.
Code Transformer converted the stored procedures to PostgreSQL-compatible code with 95% of the work automated. Manual effort was cut dramatically and the cloud migration stayed on schedule.
TypeScript and React by default, or Vue and similar frameworks where your standards call for it. Readable by any web developer you hire.
It runs in the browser, which removes the Java Web Start and desktop Java runtime dependency that security teams keep asking about.
Database logic is converted alongside the application rather than left as a second project, including Oracle to PostgreSQL where that is part of the plan.
You can host it, maintain it, and extend it yourselves, with no dependency on us to keep it running.
A track record across major enterprises
Yes, and that is usually the point. The Forms definitions and the PL/SQL are read into one model, because the business rules are spread across both. We also convert PL/SQL in its own right, including Oracle to PostgreSQL migrations.
Yes. We have converted a public-sector Oracle PL/SQL codebase to PostgreSQL with 95% of the conversion automated. Whether to do it in the same phase as the application or separately is a sequencing question the assessment answers.
APEX keeps you inside the Oracle stack, which suits some applications well. Conversion produces a standard web application in conventional code, with no dependency on a particular vendor’s platform and a much larger pool of developers who can maintain it.
Reports are part of the analysis along with the forms, since they usually carry business logic of their own. How they are handled depends on what the reporting is for, which is one of the things the assessment settles before any work starts.
Business rules move across through a model built from your real code, rather than being re-typed by hand. We then check the result two ways: side-by-side testing on the same inputs, and the business rules held in the model as a separate check.
Usually with the free assessment: a complete dependency map across the forms and the PL/SQL, risk scoring, an effort model and a costed migration plan, produced from your own source code.
The assessment is free and built from your own source code. If you would rather see output first, we can run a paid proof of concept on a representative slice of the application.