The are number of kep steps in assuring the success of your Forms modernisation project.

1. Properly aligh the modernisation project.

2. Establish a strong multidisciplinary team.

3. Analyse the existing forms.

4. Consider a hybrid approach by not moving everything over to APEX just yet.

5. Design, design, and then design some more.

7. Start small and be guided by your successes.

8. Transition training for your Forms application users is essential.

More and more organisations are wanting to migrate their legacy Forms applications to Oracle Application Express (APEX). But it is not always easy to know how best to approach the project. Since many organisations have undertaken this kind of project, there are a number of key steps that come up over and over again. Benefiting from the lessons that others have learned, will help you to better approach the project.


The 10 key steps presented here cannot be specific to your needs, but they will serve as some of the fundamental processes that must be followed if your project is to be successful. 


1.  Properly Align Your Project

Don't think of your project as a "migration" but rather as a "modernisation". Oracle Forms is a client server technology while APEX is a web technology. They are not the same and don't work in the same way. To try and simply create an APEX page that looks and functions exactly as the particular Form, will never succeed. The very reason you have opted to use APEX is to give your application a more modern look and a better user experience. A web application is built using entirely different components than a Forms application.

It is important that right from the start, you move away from a "migration" approach. You need to ensure that your client understands that you will be creating a new application that is web based and that is organised and presented in a different and better way than their existing Forms application. Getting buy-in on this concept will ensure that your approach is correctly aligned to the technology and its functionality.

Simply put, "migration" projects are destined for failure. "Modernisation" projects can have outstanding success and can meet the client's requirements and then some.


 2. Establish A Stron Multidisciplinary Team

The required size of your project team will depend very much on the size of the Oracle Forms application you are trying to move to an APEX application. This aside, your project will have far greater success if you bring together individuals from a number of different disciplines. For our purposes here, we will only consider the technical roles that should make up a solid team.

Database Administrator (DBA)

Since you are moving away from a data structure that supported your Forms application, it is very likely if not certain that you will need new data structures and perhaps schemas. It is also possible that you may build web services to interact with the database. As of APEX 18.2, you can make effective use of external data sources within your application. 

A DBA can make the data model decisions for the project and ensure that proper standards are followed and that nothing is done to interfere with backward compatibility in the event that you need to run the systems in parallel for a period of time.

If you can, it is a really good idea to have the same DBA(s) who supported the original Forms application.

Forms  / PL/SQL Developers

It is unlikely that at this point your APEX developers will have previously been Forms developers. While APEX does have a very good way of identifying the specific logic on a Form, it cannot properly assess how the Forms all fit together and how things like user access were handled. By having Forms developers on your team that are familiar with the current Forms application will be invaluable. 

Once the project is well underway it is certainly ideal to help the Forms developers move over to APEX development. This will enhance your active development and will help the Forms developers to have a stake in the modernisation effort.

APEX Solutions Architect

Building a good web application demands good design from the start. You need someone who has had a lot of experience with APEX and ideally with modernisation projects. If APEX is a new technology within your organisation, or even if it has already been used for building other applicatios, you really do need an architect that understands the best approach to building a robust and scalable APEX application.

If you don't have this kind of resource internally, you may want to consider engaging an external APEX consultant that can fulfill this role at least for a period of time. Don't assume that your existing Solution Architect can just step into this role. Get the foundation right, and the APEX build will go mucj smoother.

 APEX Developers

The number of APEX developers you will need very much depends on the size of your project. Again, if you don't have internal APEX resources you may want to seek the help of external resources. There are also many companies that offer APEX training to help upskill your current development team. And, has stated earlier, you can upskill some of your Forms developers to assist in the APEX development.You may want to consider starting with a smaller team at the beginning until the project level of effort is properly defined and until the APEX development strategy is determined.

Javascript / CSS / Jason Developer

Most seasoned APEX developers will be well versed in Javascript, CSS,  JSON, REST and more. But having team members that are highly skilled in these areas can be quite helpful. If you work in a linear way, javascript and CSS libraries can be maintained by this

resource or resources and ensure that reusability is maximised.


3. Analyse The Existing Forms

This is a really important and significant time must be allocated to it.

Don't assume that everything in the existing Forms application need to be moved over to your APEX application.

Lots of Forms applications have been built over a long period of time. New functionality has been developed, while some elements of the application may have been depricated. You need to determine what screens are currently be used as often many screens may not really be a part of the current business logic and business processes. A Forms developer or a BA that has worked on the application for some time may be able to properly analyse the fuctionality that needs to be a part of the APEX application.

Understand that an APEX web based application simply does not work in the same way as a client server application developed in Oracle Forms.

A creen build in Oracle Forms will have much of the business logic on the form itself. It will make use of triggers, program units, validations and other components that do not work in the same way in an APEX page. In fact, some Forms components won't even be necessary in your APEX application.

The APEX framework has an excellent tool that will identify all of the components on a Form so that you can assess them and decide which components ought to be a part of your APEX screen(s). The tool allows you to provide notes and to assign components developers.

To use the APEX migration tool, you need to export the form as xml and there is a utility to assist with this as part of the developer suite.

To access the APEX migration tool, simply make use of the new spotlight search to locate it. Click CONTRL + ' to open the spotlight search. Type 'migration ' into the search field and you will see the migration tool listed in the results.

If you are not familiar with the new Spotlight Search, check out our detailed article on how to use the Sspotlight Search.

The APEX migration tool wil identify every componet of the uploaded Form and will even allow you to drill into the code used on the form.

For some guidance on how to convert an Oracle Forms application to an APEX application you may want to take a quick look on another one of our articles that addresses many of the necessary considerations.

Spend as much time as you possibly can on to analyse the existing Forms application. By doing so, you will avoid unnecessary development and will begin to move toward a solid design of your APEX application.

4. Consider A Hybrid Aproach By Not Moving Everything to APEX

Despite what you may think, Oracle Forms is not going anywhere very soon. It does not mean that you should not modernise your application by moving it over to APEX,but it may not be an all or nothing issue.

Some screens built in your Forms application may be perfect for what they are intended to accomplish. While this may be somewhat contraversial, I do believe that an Forms screen can offer something quite powerful that are perhaps more difficult in an APEX application. For example, I think a form built properly with Oracle Forms can be best suited for rapid data entry. Your application power users may be so familiar with a specific form that they have mastered the quick entry of rows of data.

This is not at all to suggest that this functionality ought not to be eventually moved over to APEX. But perhaps you might leave this for a later stage and keep the back office data entry just as it is for the time being.

There are components such as the Interactive Grid in APEX that can be used for quick data entry, and at some point later in your development, you will be wise to have all business processes facilitated through your APEX application. For now, let the power users in Forms keep doing what they do very well in the Forms application.

Some APEX evangelist  may smack me for what I have said here, but I think it is worth considering as a practical approach.


5. Design, Design And Then Design Some More

Don't be so anxious as to dive into things right away.

Because Oracle Forms and Oracle Application Express (APEX) are very different frameworks and work in an entirely different way, you must never assume that a single screen in your Forms application will become a single screen in your APEX application. It like won't.

The application navagation in the APEX application will most likely be quite different than it was in the Forms application. Likelise  tthe way users are authenicated and assigned roles is most assuredly to be different.

An APEX application that is not properly designed form the ground up, will be disjointed and perhaps may not present a modernisation at all.


6. Stick With The APEX Framework

It has been my experience in working with clients, that they want to retain some features of the Forms application when they move it over to APEX. This sometimes drives them to trying to customise some of the components in APEX to work they way they want them to function.

Stop doing this!

You need to understand that the APEX framework and its components are highly tuned for the APEX engine. The native components are designed to render pages quickly. They are designed to be highly accessible for user's with disabilities. In all instances, the pages and components are designed to be fully responsive to various screen sizes. If you stjart to mess with this, you will likely interfere with the real strenth of the APEX framework.

Components in APEX are declarative and handle the necessary background code to make them work. This is also true with Dynamic Actions. If a DA can do what you want to do, and likely it can, don't load up your page with necessary Javascript that executes in the browser and is not always supported in the next version of the browser.

You should be using APEX plugins as opposed to any library build in js for instance. Plugins that have been developed by the APEX community are usually aligned with the APEX framework and have been well tested by very talented APEX developers.

If you spend tine customising aPEX templates that are part of the Universal Theme, you may have great difficulty in upgrade ng to a new version of APEX.


6. Involve The Client Or Business Users Along The Way

There are some important reasons to work very closely with the client from the very start of the project. Even more closely then you might do for other development projects.

An APEX application looks and feels intirely different than a Forms application. While they are committed to modernising their application, they sometimes fail to understand the big paradyme shift involved.

Further, the way in which a user intexracts with a web application must and should be different from a Forms appicBy working very closely with the client throughout the development process, you will begin to prepare them and excite them by the UI opprotunities present d  by the APEX framework.

Part of the process of modernising the Forms application to APEX Is to not only move the functionality over to aPEX but to enhance it and to do things in a better way. The client needs to be a part of this process as they begin to enbrace the power of a web application.


7. Start Small And Be Guided By Your Successes

If htis your first Forms modernisation project, it is wise to start small. Take a few of the more straight forward forms and develop them in APEX. 

The notion here is that you will both affirm your design and learn how to extract elements of the form and present them with n APEX context. You will discover what works and what doesn't in terms of enabling the same functionality that was presented on the form.

Developing within the APEX Framework is not rocket science, but transitioning an application from one technology to another just may be.

An agile approach to development works really well here. Dthe screens you have built to the client and understand early on that you are devloping in a way that will truly meet their needs and expectations.

Dedicate more time and effort to the early stages of development so as to speed up exponentially further in the project. 



8. Transition Training For The Forms Users Is Essential

Itr is sometimes the case that your users that have been interacting with screens developed in Forms find the transition to a new web based application difficult. They may struggle to find the part of the application that they need to use, or to know exactly how to process their transactions. This is somewhat surprising given that they work with web applications every day.

Transition training is very important to help your users make the move from Forms to APEX.

A good transition trainer, will be able to align some of the Forms components with the fAPEX components. He or she tcan help users to navigate the application and make use of the various functional areas.

Properly provided transition training will help users to know how to accomplish their tasks in a better and richer way than Forms could have ever offered.

The users that find the transition most difficult is the power users of the Forms applications. They know all of the keyboard shortcusts on a Forms screen and they can work with the ccreen and its functionality very quickly. Transition training that focuses on the needs of these users is critical.

Standard APEX training just won't work here. Demonstrating how to generally use an APEX Application will serve no real purpose to your users. They need to know how to do what they used to do in the Forms application.



Hopefully the key steps presented in this article will help you get on the right track with your modernisation project. There are many other considerations that could have been discussed, but these will have served as a starting point.

The success of your modernisation project will depend bery much on the work you do upfront. Analysing the Forms application, designing the APEX APPLICATION and essembling the right team anot to be overlooked at the start of the project.

Modernising a Forms application through the APEX framework is not just about moving it across, but is about doing things in a new and better way. After all you are build ng a business application, not the replication of already exists.
















Pin It

Contact Us

Please let us know your name.
Please let us know your email address.
Invalid Input
Please write a subject for your message.
Please let us know your message.
Invalid Input

Contact Us

Our Address

AppLinks (Pty) Limited
20 Wildebees Street
Alberton, South Africa
+27 (0) 11 902 3688
+27 (0) 83 276 3315