Skip to content
Focus area

Oracle Forms modernisation: ways out of the legacy application

Your Forms application has run for 20 years and does its job. But browser support is crumbling, the know-how is retiring, and Oracle keeps pricing the infrastructure around it. We show you which path fits your application.

Forms applications are not a problem, until they are

We started with Oracle Forms and Designer in 1998 and moved to Oracle APEX in 2005. Since then we have analysed, extended and replaced Forms applications for insurers, utilities and public authorities. Many of them were functionally excellent, only their technology was from 2002.

Typical triggers that bring clients to us:

  • The Forms client needs Java in the browser or a detour via Citrix, and IT no longer wants to support that.
  • The developer who knew the application has left. Nobody dares to touch the triggers.
  • Forms server, WebLogic and the Oracle database cost more every year, and the business still gets no new features.
  • A new interface, mobile access or a modern UI is required, and Forms cannot deliver it.

Three routes, and which one fits you

Upgrade and stabilisation. Bring Forms to a supported version, slim down the infrastructure, document the application. The right route when the application is functionally stable and will be replaced in a few years anyway.

Migration to Oracle APEX. Database and PL/SQL logic stay, the user interface is rebuilt in APEX. This is the shortest path to a browser application without client installation. We took this route from 2005 for our own applications and those of our clients. More on Oracle APEX development.

Replacement with an open stack. PostgreSQL as the database, a Go back end with a REST API, Vue.js or Flutter as the user interface. No more Oracle licences, no dependency on a single vendor, and the application is entirely yours. With EasyFlow Business we migrated a mature Oracle application exactly this way, including AI-assisted document processing that was unthinkable before.

How we proceed

  1. Inventory. We catalogue modules, triggers, libraries, reports and interfaces and measure how much logic sits in Forms and how much in the database. The result is a decision paper with an effort range per route.
  2. Pilot module. One representative module is implemented on the target stack. It shows you the UI, response times and our way of working before you commission the whole project.
  3. Step-by-step migration. Old and new application run in parallel on the same database. Departments switch module by module, operations continue.
  4. Handover. Documentation, tests and, if you wish, operation on European servers by us.

Why oxalis

We are small enough that you talk to the developers who read your Forms modules, and experienced enough that a PL/SQL package from 2003 does not scare us. AI tools speed up our analysis and the translation of logic considerably; the decisions are made by people who have known Forms since 1998.

Frequently asked questions

Do I have to replace Oracle Forms at all?

Not necessarily. Oracle still maintains Forms, and a stable application can run for years. The need to act usually comes from three directions: the business needs features that are expensive in Forms; the people who know Forms and the application are retiring; or licence and infrastructure costs for Forms server and WebLogic should go. We check which of these apply to you before recommending a direction.

Migrate to APEX or leave Oracle altogether?

If the database stays and the PL/SQL logic is sound, APEX is the shortest route: same database, same logic, new user interface. If you want to get rid of Oracle licence costs or become more independent, the move to PostgreSQL with a Go back end and Vue.js or Flutter is worth it. We have delivered both routes several times and will tell you openly which one makes sense for your application.

Are there automatic converters from Forms to APEX?

There are tools that analyse Forms modules and transfer parts of them to APEX. They are useful for the inventory. They do not produce a finished, maintainable application, because Forms trigger logic and APEX page logic work differently. We use tools where they save time and design the new application so that it lasts the next 15 years.

How long does a Forms migration take?

It depends on the number of modules, the amount of trigger logic and the interfaces. That is why we always start with an inventory that makes these quantities measurable. You then receive a plan with phases in which the old and the new application can run in parallel.

What happens to the PL/SQL logic in the database?

Good PL/SQL packages are carried over unchanged in a migration to APEX. When moving to PostgreSQL we translate them to PL/pgSQL or move them into a Go back end, depending on where the logic belongs long term. Logic buried in Forms triggers is extracted in any case and made testable.

More focus areas

Oracle APEX

New development, extension and support of APEX applications. PL/SQL in the back end, in use since 2005.

PostgreSQL & Oracle migration

Schema and PL/SQL migration to PostgreSQL, Go back ends, PostGIS. We know both databases and tell you when the switch pays off.

AI-assisted development

What AI tools actually do in our projects, what they do not do, and why experienced developers matter more because of them.

Hosting & operations

Operation of your application on European servers: monitoring, backups, updates, a named contact. Without dependency on cloud giants.

Let's talk

Tell us about your project.

Discuss your project