A very good question. We are more or less in the same situation, if we treat our Product Development as a kind of ISV. We export small pieces of the APEX application with the classical APEX export functionality into our version control system. From their we set up a nightly build in different Databases, with different versions on different operating systems and run a couple of test on top. Our architecture is set up in a kind, that we have a couple of small APEX application with common components and the same database backend functionalities. 

Yes! One of our product (Database Replacer Kit) comes along with a pure microservice architecture and allow a headless use of our application cube.
It’s even a good way to extract possible PL/SQL code out of the Forms, move them into database and provide them via WebServices over ORDS.

Yes, and I like to add two arguments. One is from Oracle itself. Larry Ellison decide to implementll COVID relevant applications for the citizen of US with APEX. Press Release for COVID App on ZDNet. On the other hand – the most traffic of the APEX application is inside the database. The ORDS in front is only handling the requests. So if you Oracle database cover the load for the existing Forms-Application, it’s ready to go for the same in APEX. 

Perhaps you could not validate the complexity of the remaining work, but to understand the benefit of the preparation phase, the possibilities of the process analysis and the potential of APEX in UX for your application, it’s worth participate the workshop. We recommend to have APEX know how, before you start thinking about the future architecture, development pattern, cross functionality and team structure. 

We advise to use the latest 20.2 Version of APEX to benefit most from the feature set of APEX. If necessary, we could go back until APEX 5 – but that doesn’t make sense. 

Our data cube loads only in the last year, round about 20.000 different Forms modules and we saw different style on implementation pattern inside the Forms Modules. For the migration APEX the rate depends on the Object Type, eg. we could generate near to 95% of the Blocks, 80% of the Items, but we ignore Alerts and Editors. With this an overall calculation of rate is capable of being misunderstood.  In my point, the springboard of generated artifacts are only one part of the story of benefits. 

You could create a function which return a SQL Statement which is the base for the interactive report. 

It’s not as easy as migrate from Forms 11g to 12c, but it’s easier than starting on a green field. The main purpose of our Product is to simplify complexity, save time and ensure quality on the way from Oracle Forms to Oracle APX.

Use PL/SQL-Packages!

The number and complexity of the Forms Modules is not relevant for the additional load in the database. It’s more or less the number of concurrent users, the Efficiency of the SQL-Statements and the amount of PL/SQL-Code, which is creating the load. In that case, the number of user and the SQL-Statements creates the greatest amount of load – but this is equal to the load of the Forms application. Usually in our assessment we run a small recording to analyse the number of user, and the amount of UI Interactions per Intervall to estimate the additonal workload through APEX page refresh. 

Once you migrate your Forms Application to APEX you could benefit immediately from the low code benefits. Extending the application, changing requirements and even finalise the migration is much more faster than in any other technology.

In general we support two different ways to treat the PL/SQL Code from Oracle Forms. On one hand we could move the PL/SQL Code to the database. This is helpful, if the code consist of any CRUD statement or consist of a relevant amount of LOC. In this case, any context information, like block-item-name, global variables, system variable, which are used inside the code, is transformed into a procedure parameter and with this we decouple the information from any naming convention which exist before. 

On the other hand we even generate the Elements in APEX out of the existing elements in Forms. So we could consider this mapping also in the adjustments of the code. 

Use the Import/Export Functionality of APEX to extract the definition of the application into a SQL-File. This will be the base for any kind of update and version control systems. Please avoid using simple merge-statements to solve conflicts. 

In our opinion a workshop on your sources would be the best starting point. With minimal effort from your side, you’ll get the most outcome for any kind of decision, budgeting, and project calculations

Most of the issues during the migration are created by the traditional user behaviour to use Function keys, and other „Hot-Keys“. It could be covered, but in my point of view „it hurts in the heart of a real APEX developer“.

For all obstacles, the APEX development from Oracle provides a solution, which may result in the end to a slightly different architecture or more work in the fine tuning phase.